UCyborg Posted June 24, 2023 Share Posted June 24, 2023 On 2/4/2023 at 2:45 AM, Art7220 said: Watching anything on hulu.com On 2/4/2023 at 3:07 AM, VistaLover said: HULU (a US-only service, BTW) uses DRM exclusively for all of its streams... Unlike Netflix, where a fallback to using the Silverlight NPAPI plugin for "legacy" browsers is in place (correct me if wrong , at least that's my recollection of things on Netflix ), HULU demands the WidevineCDM (owned by Google ) to properly function... WidevineCDM is currently incompatible with the Windows XP/Vista OSes (and in the far past was only compatible under XP with the Google Chrome web browser); if on Win7+, you must use one of the latest Chromium variants and/or latest Firefox to watch HULU ... BTW, NM28 does not support DRM on any OS, while St52 supports DRM on Vista+; however, the version of WidevineCDM it ships with (and supports), v1.4.9.1088, has been deprecated by Google, i.e. it can't acquire decryption keys from the dedicated Widevine lic servers ... @Art7220 : Got an Android phone? If yes, download their app and watch HULU's DRM streams there ... As you can see, Google not only control which webpages you can successfully load in your (non-Chrome) browser, they also control which rich content is available there, too (and also demand you update your OS to watch it) ... A true dictatorship, if you ask me... Digging an old post, I know, but for informative reasons, TVs these days tend to be able handle such streaming services, eg. HULU specifically supports SAMSUNG TVs from 2016 and later. https://help.hulu.com/s/article/supported-samsung https://help.hulu.com/s/article/supported-devices Should be much better than watching on the phone... Link to comment Share on other sites More sharing options...
Mathwiz Posted June 25, 2023 Share Posted June 25, 2023 (edited) 18 hours ago, RamonUn said: Very cool, this is a significant plus for me, even if the web does not use the format there are times where I encounter such a file and it is always good to have more options to open jxl files. Yep - same goes for me. Just as a reminder, the "web" doesn't use JPEG XL because Chrome pulled support for it, and no Web designer is going to use anything Chrome doesn't support. And Chrome pulled support for it because Google has their own alternative they want the Web to use instead. It's the "not-invented-here" syndrome. Edited June 25, 2023 by Mathwiz 4 Link to comment Share on other sites More sharing options...
roytam1 Posted June 25, 2023 Author Share Posted June 25, 2023 5 minutes ago, Mathwiz said: Yep - same goes for me. Just as a reminder, the "web" doesn't use JPEG XL because Chrome pulled support for it, and no Web designer is going to use anything Chrome doesn't support. And Chrome pulled support for it because Google has their own alternative they want the Web to use instead. It's the "not-invented-here" syndrome. but now it is funny that safari decided to support JPEG-XL after chrome removed it! 6 Link to comment Share on other sites More sharing options...
RamonUn Posted June 25, 2023 Share Posted June 25, 2023 5 hours ago, Mathwiz said: Just as a reminder, the "web" doesn't use JPEG XL because Chrome pulled support for it, and no Web designer is going to use anything Chrome doesn't support. And Chrome pulled support for it because Google has their own alternative they want the Web to use instead. It's the "not-invented-here" syndrome. I remember the fuzz when chrome decided to remove the JPEG XL support that was an experimental flag. I know some big companies including facebook really wanted the new format, because it would help significantly with bandwidth and without loss of quality because JPEG-XL has a way to compress classic JPEGs with out any loss, so It is a dream for anyone with a huge image base that are 99% JPEGs and can be re-compressed losslessly, by 20% (more or less). Also for newer images an even higher visual quality per bit can be achieved, so again any photo-store is interested by any ounce of better image compression. Safari adopting JPEG-XP might be enough to make some big website start using it (it should pay for itself in bandwidth saving over time). Of course content is negotiated and classic JPEGs would be given to unaware clients. 3 Link to comment Share on other sites More sharing options...
VistaLover Posted June 25, 2023 Share Posted June 25, 2023 8 hours ago, Mathwiz said: Chrome pulled support for it, and no Web designer is going to use anything Chrome doesn't support. And Chrome pulled support for it because Google has their own alternative they want the Web to use instead ... And quite recently, Microsoft themselves adopted Google's webp image format on their "own" webpages/services ... I have https://www.bing.com/ as one of my pinned tabs, and on that the background image changed format from ".jpg" (classic JPEG compression) to ".webp"; UXP-based browsers have no issue with webp, fortunately, but the old Firefox ESR 52.9.1 doesn't support the format: For the time being, MS still serve JPEG to their deprecated IE browsers, so changing the UA to, e.g., an IE9-based one will get the Bing background image back (on a slightly different GUI, tailored for IE): general.useragent.override.bing.com;Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0) NB: FxESR 52 doesn't support SSUAO natively, only via extension(s), however I had restored SSUAO support in it via a method made public years ago (search the forums here, if interested ) ... 2 Link to comment Share on other sites More sharing options...
RamonUn Posted June 25, 2023 Share Posted June 25, 2023 (edited) Google's webp and avif are not bad image formats by themselves but they are inferior to JPEG-XL and lack the lossless JPEG re-compression. This is not strange I mean, the JPEG team has lot more expertise when it come to image compression algorithms than google. It is a shame that bing.com is using user-agent for content type negotiation, it is extremely bad practice. There is already an HTTP protocol for content negotiation specifically for this reason at least since HTTP1.1 HTTP1.0. There never has been any excuse to use UA sniffing to decide which image format should be delivered to a client. Edit it was introduced in HTTP1.0 (1996) and is not present on HTTP0.9 (1991) ref: https://www.w3.org/DesignIssues/Conneg Edited June 25, 2023 by RamonUn 1 Link to comment Share on other sites More sharing options...
mina7601 Posted June 25, 2023 Share Posted June 25, 2023 57 minutes ago, VistaLover said: NB: FxESR 52 doesn't support SSUAO natively, only via extension(s), however I had restored SSUAO support in it via a method made public years ago (search the forums here, if interested ) ... Found it: 2 Link to comment Share on other sites More sharing options...
UCyborg Posted June 25, 2023 Share Posted June 25, 2023 (edited) @RamonUn I'm no web dev. so can't comment whether server-side or client-side approach is better, but there's also this way: https://jpegxl.io/tutorials/css/ --- I noticed yesterday that even current Ant Video Downloader for vanilla Firefox doesn't download videos properly off YouTube anymore, same issue with the old patched XUL version to handle the difference in request type, manually running FFmprg to merge the streams downloaded with either extension variant results in an error regarding the video stream: Invalid data found when processing input. Certain Invidious instances can still be used, though. Oh well, guess my days of casually downloading stuff off YouTube via browser extension have come to an end. Edited June 25, 2023 by UCyborg 2 Link to comment Share on other sites More sharing options...
mina7601 Posted June 25, 2023 Share Posted June 25, 2023 (edited) On 6/24/2023 at 1:34 AM, DanR20 said: what is v141, is this a Mozilla browser? No, it's not a Mozilla browser, but rather a platform toolset in Visual Studio 2017, which is used to build apps for Windows Vista and later. Not to be confused with v141_xp, a platform toolset, which is used to build apps for Windows XP and later. For reference, here is a link to each Visual Studio version and their platform toolsets versions. Edited June 25, 2023 by mina7601 2 Link to comment Share on other sites More sharing options...
Mathwiz Posted June 26, 2023 Share Posted June 26, 2023 12 hours ago, RamonUn said: It is a shame that bing.com is using user-agent for content type negotiation, it is extremely bad practice. It probably works for the very specific case of Bing on IE, because Microsoft wrote IE and knows what will (and won't) work with it. As for FF 52, by default it just sends Accept: */* for images, which just tells the Web page to send whatever it thinks is best, so Bing sends WebP which doesn't work. There's a pref in FF-based browsers to control what image formats it tells the Web page to use: image.http.accept. Perhaps changing the pref from */* to something like image/png,image/jpeg,image/*;q=0.3,*/*;q=0.1 would get Bing to send FF 52 the correct format. In the latest Serpent 55, that pref defaults to image/webp,image/jxr,image/png,image/*;q=0.1,*/*;q=0.1 (Note that image/jxr is JPEG extended range, not a typo for JXL.) So if @roytam1 adds JPEG XL support to Serpent, he should probably add image/jxl to the front of that default value string. Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values#values_for_an_image Link to comment Share on other sites More sharing options...
nicolaasjan Posted June 26, 2023 Share Posted June 26, 2023 9 hours ago, UCyborg said: I noticed yesterday that even current Ant Video Downloader for vanilla Firefox doesn't download videos properly off YouTube anymore, same issue with the old patched XUL version to handle the difference in request type, manually running FFmprg to merge the streams downloaded with either extension variant results in an error regarding the video stream: Invalid data found when processing input. (offtopic) Possibly due to recent changes in YouTube's site code? Maybe try with the latest versions of youtube-dl or yt-dlp, optionally with the help of the legacy "Open With" extension. Direct link to legacy XUL version: https://ca-archive.us.to/storage/11/11097/open_with-6.8.6-fx+sm+tb.xpi Screenshot. 2 Link to comment Share on other sites More sharing options...
VistaLover Posted June 26, 2023 Share Posted June 26, 2023 (edited) 12 hours ago, Mathwiz said: It probably works for the very specific case of Bing on IE, because Microsoft wrote IE and knows what will (and won't) work with it. As I wrote in my previous post, MS serve IE a somewhat different version of their Bing Search (home)page, compared to Fx-based browsers: IE9: NM28: So, they're not using UA-sniffing just to determine what image format to serve, rather which page flavour to serve ; it just so happens (and, as you said, this is no coincidence ) that the flavour targeting IE is being served JPEG instead of WebP... 12 hours ago, Mathwiz said: As for FF 52, by default it just sends Accept: */* for images, which just tells the Web page to send whatever it thinks is best, so Bing sends WebP, which doesn't work. There's a pref in FF-based browsers to control what image formats it tells the Web page to use: image.http.accept. Perhaps changing the pref from */* to something like image/png,image/jpeg,image/*;q=0.3,*/*;q=0.1 would get Bing to send FF 52 the correct format. Actually, that was the first thing I tried before I ended up using a SSUAO "trick" for Bing Search homepage, and I can tell you it just doesn't work there ... FWIW, it doesn't even work in St52 if: a. You disable the native WebP decoder, by toggling "image.webp.enabled" b. Modify "image.http.accept" in the way you suggested... Best regards ... Edited June 26, 2023 by VistaLover IE9 image was AWAL (?) 2 Link to comment Share on other sites More sharing options...
roytam1 Posted June 26, 2023 Author Share Posted June 26, 2023 alright rebuilt UXP-based builds and ported latest commits to moebius. and JPEG-XL even works in IA32 build! 7 Link to comment Share on other sites More sharing options...
mina7601 Posted June 26, 2023 Share Posted June 26, 2023 8 minutes ago, roytam1 said: alright rebuilt UXP-based builds and ported latest commits to moebius. and JPEG-XL even works in IA32 build! This is so good! 2 Link to comment Share on other sites More sharing options...
AstroSkipper Posted June 26, 2023 Share Posted June 26, 2023 11 minutes ago, roytam1 said: alright rebuilt UXP-based builds and ported latest commits to moebius. and JPEG-XL even works in IA32 build! Unbelievable! Very good job! All I can say is, applause, applause! 3 Link to comment Share on other sites More sharing options...
Recommended Posts