Is XVID still used?

[kurkosdr]

Here are some Tears of Steel 720x300 encodes:

https://drive.google.com/drive/folders/1T5NAecI5JF9n5v0_bDJrGTjin_RhnxUW?usp=sharing

Mpeg2 and Mpeg4 look pretty equal to me.

No mention of encoder and encoder settings used for each? All I can see is that the MPEG4 ASP one was done with the XviD encoder but nothing else.

Also, the MPEG4 ASP looks better to me, and there is no mention of PSNR and SSIM either (can't be bothered to track down an uncompressed copy of the clip to do it myself, sorry).

PS: It would seem weird to me that MPEG would go through all the effort of defining MPEG4 ASP and breaking compatibility with MPEG2 without at least some kind of significant improvement in the coding tools offered.

[rwill]

No mention of encoder and encoder settings used for each? All I can see is that the MPEG4 ASP one was done with the XviD encoder but nothing else.

Also, the MPEG4 ASP looks better to me, and there is no mention of PSNR and SSIM either (can't be bothered to track down an uncompressed copy of the clip to do it myself, sorry).

PS: It would seem weird to me that MPEG would go through all the effort of defining MPEG4 ASP and breaking compatibility with MPEG2 without at least some kind of significant improvement in the coding tools offered.

In case you wonder why it looks crap, it does not look that bad on a CRT. Going through my archive, things looked even worse back then in ~2002.

Encoder and configuration used, of course I used the best Mpeg2 and Mpeg4 encoder I had available with the best settings I could come up with.

That says it all I think.

...
...
...
...



Ok maybe not...

I used xvid_encraw which reports
xvidcore build version: xvid-1.3.7
Bitstream version: 1.3.7

And y262 in the 08/15/2022 git version.

Configuration was:

./xvid_encraw.exe -i tos_720x300_8b.yuv -type 0 -csp i420 -w 720 -h 300 -framerate 24.0 -bitrate 900 -pass1 -full1pass -max_key_interval 300 -quality 6 -vhqmode 4 -bvhq -masking 2
./xvid_encraw.exe -i tos_720x300_8b.yuv -type 0 -csp i420 -w 720 -h 300 -framerate 24.0 -bitrate 900 -pass2 -max_key_interval 300 -quality 6 -vhqmode 4 -bvhq -masking 2 -o mpeg4.m4v

./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 1 -mpout stats.p1 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 -nump 18 -numb 2 -flatmat -videoformat 709
./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 2 -mpin stats.p1 -mpout stats.p2 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 -nump 18 -numb 2 -flatmat -videoformat 709
./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 2 -mpin stats.p2 -mpout stats.p3 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 -nump 18 -numb 2 -flatmat -videoformat 709 -out mpeg2.m2v


The tos_720x300_8b.yuv was derived from the "Ben Waggoner HEVC encoding challenge" ToS source in the HEVC subforum.
Its scaling was done with some ffmpeg version with such a filter: "-filter:v scale=720x300".

*edit*
Its also telling that you make broad claims about the quality of 'Mpeg2' and 'Mpeg4' without mentioning encoder and configuration as well but complain about them missing when others disagree with your claims.

Oh and the Mpeg2 video looks better to me.

[Katie Boundary]

Basically, it all comes down to this: Have you tried squeezing a 2-hour movie on an SVCD? Or even on 2 SVCDs? It's unwatchable, even on a CRT television. You have to go to 4GB (DVD) at minimum, which was considered a huge filesize back then. Meanwhile, a 2-hour movie on 2CDs with MPEG4 ASP at 640x360 offered acceptable quality (for the standards of the day, at least), and even 1CD was considered watchable.

"Watchable"? 700 MB per 2-hour movie was the standard. Only as movies approached 2.5 hours did you start to see the 2-CD encodes become more common.

[outhud]

Isnt most Divx/Xvid content on the internet derived from DVD ? I remember it was in the year ~2000. That just came about with people starting to re-encoding DVDs with the hacked Divx 3.11 Alpha codec in resolutions like 640x360. People could have used some Mpeg-2 encoder too but there was no one available for free I guess. MP3 started off the same, with some hacked Fraunhofer encoder and Napster. Ah, piracy... "Sure it looks bad, but at least it's small". Mpeg-2 video could have done this as well, SVCD being one popular standard.

I remember a short lived one called 3ivX also for a while.

[benwaggoner]

I remember a short lived one called 3ivX also for a while.
IIRC, that was another MPEG-4 part 2 implementation.

[benwaggoner]

PS: It would seem weird to me that MPEG would go through all the effort of defining MPEG4 ASP and breaking compatibility with MPEG2 without at least some kind of significant improvement in the coding tools offered.
MPEG-4 part 2 was a disappointment. While it was better than MPEG-2, particularly for lower bitrates and resolutions, it wasn't so much better for 480i/576i that broadcasters were motivated to replace the millions of set top boxes to get a ~20% bitrate reduction. Plus there were IP ambiguities that made big bets by big companies seem unwise for the first few years.

Dark Shikari had a great insightful post about the design defects in p2 ASP somewhere I can't find. A couple issues I recall is that the requirement that adaptive quantization go up and down by even numbers relative to a previously determined frame QP was a challenge and annoying to optimize. And Global Motion Compensation could really only save something like 1 bit per frame. Hopefully someone else can dredge it up.

The broadcast market back then is what sold encoders, and therefore drove encoder development. MPEG imagined a big competitive ecosystem of vendors trying to squeeze out an extra 1% here and there to win contracts. That's what helped make MPEG-2 as good as it was, and later provided the many years of continuous improvement of H.264 and HEVC.

MPEG-4 Pt 2 never got that kind of love, both due to, and a cause of, its relatively small paying market.

Also, the streaming market back then was dominated by the proprietary QuickTime, Windows Media, and RealVideo. By the time they had had robust Pt 2 support, better codecs were available.

Lastly, as it was pretty obvious that Pt2 was in trouble, H.264 (MPEG-4 Pt 10) development was accelerated and arrived a lot sooner than the typical 10 year gap between major MPEG codecs, had obviously superior compression efficiency, and had a simple licensing regime. That's what broadcasters targeted, and what the encoder vendors all pivoted to competing on. The commercial market for H.264 encoders was quickly 100x bigger than the Pt 2 market ever was, which funded a lot of encoder developers. And then x264 happened with a remarkably brilliant set of developers and a big global audience competing on encoding fast and beautifully and providing a much broader base of feedback and fine tuning than any encoder before it ever got. It's weird to think that traditional codec development back then didn't even look at animation content!

[StainlessS]

Dark Shikari had a great insightful post about the design defects in p2 ASP somewhere
On D9 ?

Perhaps amongst this lot
Google

"Dark Shikari" NEAR ("ASP" AND ("p2" OR "part 2")) site:forum.doom9.org

https://www.google.co.uk/search?q=%22Dark+Shikari%22+NEAR+%28%22ASP%22+AND+%28%22p2%22+OR+%22part+2%22%29%29++site%3Aforum.doom9.org&ei=cTFPY7_3AsuI9u8PlsGcyAM&ved=0ahUKEwj_86yh8ur6AhVLhP0HHZYgBzkQ4dUDCA4&uact=5&oq=%22Dark+Shikari%22+NEAR+%28%22ASP%22+AND+%28%22p2%22+OR+%22part+2%22%29%29++site%3Aforum.doom9.org&gs_lcp=Cgdnd3Mtd2l6EANKBAhBGAFKBAhGGABQnxBYlZcBYN-yAWgBcAB4AIABf4gBhgySAQM2LjmYAQCgAQHAAQE&sclient=gws-wiz


amend if you remember better search stuff

EDIT: There is this post by bond (but not on defects), MPEG-4 ASP Information, What is MPEG-4?
https://forum.doom9.org/showthread.php?t=73022

[outhud]

MPEG-4 part 2 was a disappointment. While it was better than MPEG-2, particularly for lower bitrates and resolutions, it wasn't so much better for 480i/576i that broadcasters were motivated to replace the millions of set top boxes to get a ~20% bitrate reduction. Plus there were IP ambiguities that made big bets by big companies seem unwise for the first few years.

Dark Shikari had a great insightful post about the design defects in p2 ASP somewhere I can't find. A couple issues I recall is that the requirement that adaptive quantization go up and down by even numbers relative to a previously determined frame QP was a challenge and annoying to optimize. And Global Motion Compensation could really only save something like 1 bit per frame. Hopefully someone else can dredge it up.

The broadcast market back then is what sold encoders, and therefore drove encoder development. MPEG imagined a big competitive ecosystem of vendors trying to squeeze out an extra 1% here and there to win contracts. That's what helped make MPEG-2 as good as it was, and later provided the many years of continuous improvement of H.264 and HEVC.

MPEG-4 Pt 2 never got that kind of love, both due to, and a cause of, its relatively small paying market.

Also, the streaming market back then was dominated by the proprietary QuickTime, Windows Media, and RealVideo. By the time they had had robust Pt 2 support, better codecs were available.

Lastly, as it was pretty obvious that Pt2 was in trouble, H.264 (MPEG-4 Pt 10) development was accelerated and arrived a lot sooner than the typical 10 year gap between major MPEG codecs, had obviously superior compression efficiency, and had a simple licensing regime. That's what broadcasters targeted, and what the encoder vendors all pivoted to competing on. The commercial market for H.264 encoders was quickly 100x bigger than the Pt 2 market ever was, which funded a lot of encoder developers. And then x264 happened with a remarkably brilliant set of developers and a big global audience competing on encoding fast and beautifully and providing a much broader base of feedback and fine tuning than any encoder before it ever got. It's weird to think that traditional codec development back then didn't even look at animation content!

This is a great post on the history of it, thanks!

[FranceBB]

Great piece of history indeed by our Ben. :)
If there's someone I'd point my finger against (as an "antagonist") in history that would be Sony and their MPEG-2 pursuit 'till the bitter end.
If it wasn't for Sony, MPEG-2 would have been dead in the water, but after the bitter disappointment of MPEG-4 ASP (i.e XVID) in 2001, most broadcasters didn't gamble with MPEG-4 Part 10 (i.e H.264) in 2004 for SD contents (720x480 29,970i - 720x576 25i) and decided to stick with MPEG-2. Back then, formats like IMX50 based on MPEG-2 All Intra 50 Mbit/s 4:2:2 were popular for SD files.
In 2006, as little as 2 years after H.264 was introduced, the world moved to HD (and then FULL HD) and Sony made the XDCAM set of standard which is essentially MPEG-2 for both HD and FULL HD.
Guess what happened? Many companies wanted "stability" and adopted it instead of H.264, but that was a big, big mistake. As result, most broadcasters are still using MPEG-2 for FULL HD contents to this very day and are hog-tied to this ancient, no longer supported, unoptimized codec with banding problems and what not.
If Sony didn't do this, the world would have moved to H.264 for HD and FULL HD and MPEG-2 would have been dead by now.

[excellentswordfight]

Great piece of history indeed by our Ben. :)
If there's someone I'd point my finger against (as an "antagonist") in history that would be Sony and their MPEG-2 pursuit 'till the bitter end.
If it wasn't for Sony, MPEG-2 would have been dead in the water, but after the bitter disappointment of MPEG-4 ASP (i.e XVID) in 2001, most broadcasters didn't gamble with MPEG-4 Part 10 (i.e H.264) in 2004 for SD contents (720x480 29,970i - 720x576 25i) and decided to stick with MPEG-2. Back then, formats like IMX50 based on MPEG-2 All Intra 50 Mbit/s 4:2:2 were popular for SD files.
In 2006, as little as 2 years after H.264 was introduced, the world moved to HD (and then FULL HD) and Sony made the XDCAM set of standard which is essentially MPEG-2 for both HD and FULL HD.
Guess what happened? Many companies wanted "stability" and adopted it instead of H.264, but that was a big, big mistake. As result, most broadcasters are still using MPEG-2 for FULL HD contents to this very day and are hog-tied to this ancient, no longer supported, unoptimized codec with banding problems and what not.
If Sony didn't do this, the world would have moved to H.264 for HD and FULL HD and MPEG-2 would have been dead by now.
In XDCAM 50 defense, when it comes to well adopted standards with a broad compliance there is still no HD standard that that does 1080i at the same or lower bitrate that is viable as house format! AVC-I and XAVC-I is 100Mbps, and when re-compressed for contribution at limited bitrates it makes pretty much no difference for the end consumer. The GOP versions of AVC/HEVC is not universally supported in the same way as xdcam and the intra flavors of AVC.

I think its crazy that the "smallest" viable house format for UHD XAVC-I Class300 is 500Mbps (50fps mode for pal regions), thats a 10x increase from xdcam 50! Tbh thats absurd given that mpeg-2 is over two decades old, and we still cant "save" space in the broadcasting world. This makes transitions to things like 1080p and 2160p very expensive to migrate to, so most just stick to 1080i/XDCAM. I tried to explain this to management when calculating on on storage cost for UHD migration, cause they couldnt understand why UHD would take up more than 4x than our old XDCAM format.

It also doesnt help that that hw-decode and encode of 10bit 4:2:2 formats is abysmal. Like it would make so much sense for a AVC/HEVC mezz standard to also have good hw support in gpu-solutions, without the need for expensive purpose built acc-cards. If there were full out support in qsync/nvenc/VCE and implemented in a broad amount of applactions as NLEs etc for fast encode and decode I think it would accelerate adoption alot. It would also lower requirement for realtime ingest a lot.

[kurkosdr]

Configuration was:

./xvid_encraw.exe -i tos_720x300_8b.yuv -type 0 -csp i420 -w 720 -h 300 -framerate 24.0 -bitrate 900 -pass1 \
-full1pass -max_key_interval 300 -quality 6 -vhqmode 4 -bvhq -masking 2
./xvid_encraw.exe -i tos_720x300_8b.yuv -type 0 -csp i420 -w 720 -h 300 -framerate 24.0 -bitrate 900 -pass2 \
-max_key_interval 300 -quality 6 -vhqmode 4 -bvhq -masking 2 -o mpeg4.m4v

./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 1 \
-mpout stats.p1 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 -nump 18 -numb 2 \
-flatmat -videoformat 709
./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 2 \
-mpin stats.p1 -mpout stats.p2 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 \
-nump 18 -numb 2 -flatmat -videoformat 709
./y262.exe -in tos_720x300_8b.yuv -size 720 300 -threads 1 2 -profile main -level high -chromaf 420 -rcmode 2 \
-mpin stats.p2 -mpout stats.p3 -bitrate 900 -vbvrate 2000 -vbv 600 -quant 3 -quality 100 -frcode 2 -arinfo 1 \
-nump 18 -numb 2 -flatmat -videoformat 709 -out mpeg2.m2v

I was surprised by how good your MPEG-2 video looks for the bitrate, so I decided to analyse it, and I noticed that you used a 57-frame GOP on average. You can't do this on DVD-Video, DVD-Video uses a max GOP length of 18 for NTSC and 15 for PAL (https://forum.mediacoderhq.com/viewtopic.php?t=8599). This gave your encode a major efficiency boost that you won't get when encoding DVD-Video compliant MPEG-2.

So, to recap, the space-efficiency advantages of using Divx avi over DVD-Video are:
1. Ability to use widescreen at the low resolution of 640x360 (DVD-Video forces you to use a relatively high 720x576/480 resolution if you want widescreen)
2. Whatever efficiency gains MPEG4 ASP offers over MPEG2 due to the better coding tools
3. Further efficiency gains due to using a max I-frame distance of up to 240 (instead of 15 or 18 for DVD-Video)

Also, you can ship either an avi file or an ISO for Divx avi, with DVD-Video you must always ship an ISO (a pet-peeve of mine).

So, back to the original question: Is XVID still used? Answer: Yes, it is still used to make Divx avi files to upload to the internet, because most people don't want to download a 4GB file for SD content (when downloading video for their non-H264 devices).

I know, necroposting (don't care), but I was bored the other day at work and was browsing for car DVD players, and I noticed that they still sell car DVD players (https://www.amazon.co.uk/Philips-PD7032-Screen-Portable-Player/dp/B005HTZX60/) that don't support H.264 but do support Divx avi (https://www.download.p4c.philips.com/files/p/pd7032_12/pd7032_12_dfu_eng.pdf). Yes, in 2022!! And someone bought this player on 30 December 2021 according to Amazon reviews. So, the installed base of car DVD players that don't do H.264 but can do Divx avi is not diminishing but actually expanding! Why can't they support H.264? I guess H.264 needs a more powerful chip while MPEG4 ASP decoding is a standard feature on all DVD chips made for the past decade. Also, MPEG4 ASP royalties are lower or non-existent.

So, my point is, MPEG4 ASP in avi files is not going away. Good or evil, learn to love it. This means Xvid is not going away for quite a while either.

[rwill]

I was surprised by how good your MPEG-2 video looks for the bitrate, so I decided to analyse it, and I noticed that you used a 57-second GOP on average. You can't do this on DVD-Video, DVD-Video uses a max GOP length of 18 for NTSC and 15 for PAL (https://forum.mediacoderhq.com/viewtopic.php?t=8599). This gave your encode a major efficiency boost that you won't get when encoding DVD-Video compliant MPEG-2.

But no one is talking about DVD but you? This is like saying the default -keyint of 250 of x264 is not BD compliant? Keep it mind that the intent was a comparison between a a good Mpeg-2 and a good Mpeg-4 encoder and not between distribution standards.

And its 57 frames and not seconds. You might have also noticed while analyzing the stream that y262 is laking a scenecut detection and as such does not place keyframes on shot changes - giving XVID an advantage.

So, to recap, the space-efficiency advantages of using Divx avi over DVD-Video are:

And there you are talking about DVD again. No one talked about DVD compliance, we talked about video compression standards and their implementation.

This is it then. People here make less sense every day. I am taking a time out from Doom9.

[kurkosdr]

And its 57 frames and not seconds.

The 57-second thing was a typo (sorry, originally meant to express it in seconds). Fixed now.

But no one is talking about DVD but you? This is like saying the default -keyint of 250 of x264 is not BD compliant? Keep it mind that the intent was a comparison between a a good Mpeg-2 and a good Mpeg-4 encoder and not between distribution standards.

And there you are talking about DVD again. No one talked about DVD compliance, we talked about video compression standards and their implementation.
For consumer electronics backwards compatibility (which is the only reason you should use anything older than H.264), MPEG2 is DVD or SVCD, and both restrict max distance between I-frames:
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-vcd-dvd.html

So, for pre-H264 hardware, realisticaly it's either DVD, SVCD, or Divx Home Theater profile, and I answered why Divx Home Theater holds a space-efficiency advantage over DVD. SVCD doesn't do widescreen so I didn't even consider it, but points #2 and #3 in my previous post still apply. And point #2 applies to MPEG2 vs MPEG4 ASP in general.

I know the thread veered off a bit, that's why I realigned it with the original question ("Is XVID still used?") in my previous post. The answer is: XVID is still used to encode Divx Home Theater-compliant files. And Divx Home Theater is still used where small sizes are needed and compatibility with pre-H264 hardware is also needed, due to its space-efficiency advantage over DVD.

This is it then. People here make less sense every day. I am taking a time out from Doom9.
https://i.ibb.co/VwMBcqT/airport.gif

[Katie Boundary]

For consumer electronics backwards compatibility

No one is talking about consumer electronics.

[rwill]

Hey nice plane in the picture.

It is taking off like XVID compatible consumer electronics in underdeveloped countries in the year 2022 of our lord.

Speaking of airplanes, Mpeg-1/2 Video is still used in In-flight Entertainment Systems (IFEs). I even was approached in 2020 by people still doing Mpeg-1 Video encodings for IFEs because of my Mpeg-1/2 encoder as commercial solutions have been largely abandoned and the ffmpeg encoder is crappy and apparently not specification compliant.

In Really Modern IFEs Mpeg-4 ASP is used of course. Now you might think this is another use case for XVID. No. XVID like x264 kinda does violate profile limits unless very correctly configured. And then the picture does not look so good anymore. That's because XVID files are supposed to be decoded on a PC without hardware constraints.

Also nice story there with your car DVD player. I would not interpret much into it though, there are always greater retards. More current people have moved on though, to smartphones, tablets and Smart TVs.

[kurkosdr]

No one is talking about consumer electronics.
You defacto are when talking about anything older than H.264. Even broadcasters who are using MPEG2 are doing it to maintain compatibility with existing MPEG2 receivers. And so are DVD publishers using DVD-Video instead of something like AVCHD or BD9, they are doing it to maintain compatibility with existing consumer electronics DVD players. That's the vast majority of demand for encoders for pre-H264 standards right there.

And anyway, the original question was "Is XVID still used?", so I have to explain to OP that it's used mostly to target non-H264 consumer electronics devices nowadays and its relative merits over DVD-Video that those devices also support.

Also nice story there with your car DVD player. I would not interpret much into it though, there are always greater retards. More current people have moved on though, to smartphones, tablets and Smart TVs.
I am not in the market for one right now and not planning to be. It all started when browsing Philips' website for something else, and then out of curiosity I wanted to see what kind of media players their name is being plastered on nowadays (hint: not very good ones, it's budget DVD players and car DVD players). Then I veered off to Amazon to see if similar non-H264 players are sold by other brands (apparently they are, a lot). You can try to stop other people from buying these things and also try to convince other people to throw away any such players they already have, so that XVID disappears. I will be waiting. Until then, XVID will be with us for a long time. So, to answer the original question, XVID is still used and will be for a long time.

[filler56789]

.......
backwards compatibility (which is the only reason you should use anything older than H.264)

You are wrong.
Now and then I still do some DivX reencodes of hi-quality short (30 minutes maximum) AVC clips which are highly-compressible
(not too sharp and made of low-motion content).
I use a high-bitrate quantization matrix with constant quantizer = 3,
GOP-length = 5 seconds, no B-frames, and so I may get, for example, a 300 MB file (audio included) from a 2 GB AVC source whose GOP-length = 0.5 second.
My storage space is limited and running DivX @ 1920x1080 is faster and simpler than using HEVC, AVC or VC-1,
therefore I choose the easier way whenever I can.

[MaximRecoil]

"Watchable"? 700 MB per 2-hour movie was the standard. Only as movies approached 2.5 hours did you start to see the 2-CD encodes become more common.

700 MB Xvid encodes were the most common, but they weren't very good quality. The best case scenario for them, in terms of a Hollywood movie, was a short (around 90 minutes or so) 2.35:1 movie, which would typically be 640×272. A 2-pass encode with 128 kbps audio didn't have any major compression artifacts at least, but it didn't exactly preserve fine/complex detail like film grain.

Things got worse from there, i.e., a 1.85:1 movie was typically 624×336 (about 20% more pixels to encode), and a 1.33:1 movie was typically 640×480 (about 76% more pixels to encode).

"2-CD" encodes were a thing at least as far back as when I first got a PC / internet access (2001), they were just less common because internet speeds were a lot slower and hard drives were a lot smaller. It didn't usually have anything to do with the length of the movie, but rather with the preferences of the person / release group who encoded it. For example, I doubt that "aXXo" ever released a 2-CD encode, while there were people who always did 2-CD encodes regardless of the length and aspect ratio. 2-CD encodes usually had the untouched AC3 audio from the DVD, usually the 192 kbps 2-channel stream that many, if not most, DVDs included.

[Katie Boundary]

You defacto are when talking about anything older than H.264.

No. Piracy existed before h.264 and it had nothing to do with consumer electronics.

[hello_hello]

Compatibility > efficiency

Every time.

Every. Goddamn. Time.

For consumer electronics backwards compatibility...

No one is talking about consumer electronics.

What am I missing?

[rwill]

What am I missing?

You seem to be missing that Katie Boundary's reply was below something about MP3.

Unless music requires a surround format you can buy 44.1kHz Stereo albums for download in MP3 which sound just fine, given their ~250kbps VBR. 44.1kHz Stereo is still somewhat current.

I have not yet seen 2CD Xvid releases of full length movies in (U)HD though. (U)HD is somewhat of a current standard as well.

[kurkosdr]

You seem to be missing that Katie Boundary's reply was below something about MP3.

Unless music requires a surround format you can buy 44.1kHz Stereo albums for download in MP3 which sound just fine, given their ~250kbps VBR. 44.1kHz Stereo is still somewhat current.

I have not yet seen 2CD Xvid releases of full length movies in (U)HD though. (U)HD is somewhat of a current standard as well.
So? People will download a (U)HD copy for the living room and bedroom and also a Divx avi copy for the car DVD player or TV/DVD player in the kitchen (or other player that doesn't do H.264 or H.265) and have it both ways

Most people here can't understand that:
- Some people will tolerate bad video quality outside the living room and bedroom, because some people just don't care that much.
- DVD players that won't play any kind of H.264 are still being sold today (because H.264 requires better chips and extra royalty payments). You should expect the average DVD player to support DVD-Video and Divx avi and no H.264 (unless it specifically lists HD support, which most don't). See my posts above for an example.

So, to answer the original question: Xvid will still be used for as long as there is a demand for compatibility with non-H.264 hardware, which is still being manufactured and bought by some people even today (no matter how that makes you feel).

[DTL]

Yes - most of torrent-releases of any new title and broadcast recordings have now xvid-based version of SD resolution with very low bitrate. It is defacto hard standard of media files today. It is sort of natural public voting against zilions non-supported in old hardware players modern codecs with some % of better quality and with requirement to make payment for new hardware or look for software decoder in geeks boxes with updatable firmware/software. Most of real people are simple and like to have plug-and-play media workflow with once for decades purchased simple stable video playback hardware.

The era of computer geeks @home is gone in the past. Very fast in about 20 years - only about 1/5 of a century.


I mean, we're here talking about H.266 VVC getting ready soon-ish and there are people still encoding in XVID... It definitely makes you wonder...

In practice the residuals of this current dying civilization do not need new non-compatible video codes every 3..5 and even 10 years. The colour analog SDTV work for about half of a century and most users where happy. So may be one new digital codec every half or 1 century may be enough (if civilization do not die too fast and can keep itself stable at the level like 2000 at least a century).

The quality of video codecs reach its 'saturation for general public' at about transition from MPEG-4 ASP to AVC. The MPEG2 was yet about too simple and blocky.

Only moneymakers tried to take more money from general more and more poor public forcing it to move to 265 with 10bit and HD/UHD/HDR/WCG. And general public voting against it using 8bit SDR SD xvid of MPEG-4 ASP with build-it deblocking and a bit more advancing after MPEG-2.

Also a small group of geeks at this planet still tried to make extra/super/ultra/video codec (at some places numbered 266, 267..268+/++) with some more % or part of % of efficiency with 10..100..100000+x more compute resources to encode and _new_ hardware to decode.

Back then, formats like IMX50 based on MPEG-2 All Intra 50 Mbit/s 4:2:2 were popular for SD files.
In 2006, as little as 2 years after H.264 was introduced, the world moved to HD (and then FULL HD) and Sony made the XDCAM set of standard which is essentially MPEG-2 for both HD and FULL HD.
Guess what happened? Many companies wanted "stability" and adopted it instead of H.264, but that was a big, big mistake. As result, most broadcasters are still using MPEG-2 for FULL HD contents to this very day and are hog-tied to this ancient, no longer supported, unoptimized codec with banding problems and what not.


It is true - some broadcast company in poor country still finally move to HD to the end of 201x and take as standard for file exchange MPEG2 50Mbit/s 4:2:2 LongGOP MXF. Though when in come to broadcast it is downgraded to SD 2 Mbit 4:2:0 h.264.

[Katie Boundary]

I can't understand what the hell DTL is saying.

[kurkosdr]

I can't understand what the hell DTL is saying.
Looke like DTL just core dumped (http://catb.org/jargon/html/C/core-dump.html), don't try to make sense of it.

[FranceBB]

Yes - most of torrent-releases of any new title and broadcast recordings have now xvid-based version of SD resolution with very low bitrate. It is defacto hard standard of media files today.

Yeah...


Most of real people are simple and like to have plug-and-play media workflow with once for decades purchased simple stable video playback hardware.


That is true. Not so long ago (I think it was 2018), the wife of a colleague of mine showed me the playback support of the devices they use to playback stuff for their children in the car while they drive to keep them quiet (when for instance they go to the summer house with their car) and it still showed MPEG-2 and Xvid/DivX support only, so... yeah, there's that.
Of course their car isn't new (and wasn't "new" in 2018 either), but when someone buys a car he expects it to last for several years along with the players inside, so it makes sense.



The era of computer geeks @home is gone in the past. Very fast


That is sadly depressing... :(



The colour analog SDTV work for about half of a century and most users where happy.


Yeah... We might be happy to see lots of stops/nits being recorded in modern cameras without clipped out skies and no banding with 10bit and 12bit etc, but realistically, most consumers don't really care and would have easily been happy to keep watching SD BT601 8bit 100 nits stuff on their TV 'cause "it just works"...



The quality of video codecs reach its 'saturation for general public' at about transition from MPEG-4 ASP to AVC. The MPEG2 was yet about too simple and blocky.


Honestly, though, we're here discussing about Xvid still being around, but can you imagine how long H.264 will stick around? I mean, it was such a good codec in terms of patents and x264 was such a good encoder that it will probably stick around for years to come and the fact that broadcast companies adopted XAVC Intra Class 300 and 480 for UHD workflows will make it stick around even longer ehehehe.
But even in the consumer world, most of the stuff we see in VOD is still either in H.264 OR has an H.264 fallback stream for compatibility purposes.
I'm not saying that it's a bad thing, on the contrary, but I'm just noticing how long x264 will stick around for years to come. :P


Only moneymakers tried to take more money from general more and more poor public forcing it to move to 265 with 10bit and HD/UHD/HDR/WCG.


Well... I mean... it's not just money makers, though, isn't it?
I mean, even I don't care much about UHD per se, but there's one thing I'm particularly happy about: more stops in cameras and more nits in contents.
I mean, imagine recording someone with a direct light source and not having to worry about having the sky completely white and clipped out at 100 nits. Nowadays with Sony cameras you can easily record in HLG BT2020 and get your memories in stunning quality and then you can just play back the very same file on your TV etc showing the same amount of nits as the stops recorded by the camera.
Before this was a thing, you had to record in Slog3 and then apply a LUT to go to BT709 SDR 100 nits in the least painful way possible by preserving as much as you could, while if you shot directly in BT709 it would have almost definitely been clipped out.

In a nutshell: I don't think the biggest innovation of 2013 was UHD but rather HDR.

I can't understand what the hell DTL is saying.

Men and women are often incompatible xD
Just joking, Katie, he might go down a bit of a rabbit hole sometimes with lengthy posts, but so are mine, so we kinda understand each other.
Once you dive into his flow of thoughts, you'll see that he often has some valid points.
Like the recent x264 ASM discussion we had, he made some really valid points.

p.s I'll tell you a secret, he also works with signals through SDI cables, so I like to think that we're SDI buddies XD

Looke like DTL just core dumped, don't try to make sense of it.

Poor DTL hahahahahahahahaha

[benwaggoner]

In a nutshell: I don't think the biggest innovation of 2013 was UHD but rather HDR.
Absolutely correct. 1080p HDR is a way bigger upgrade than 2160p SDR.

The rapid adoption of HEVC for premium content was largely driven by support for HDR.

I expect in 10-20 years we'll be thinking of SDR the way we do SD today.

[DTL]

"keep watching SD BT601 8bit 100 nits stuff on their TV 'cause "it just works"..."

Only extra poor people watch SDR content at 100nits very poor displays (I also use such Philips-china 4K SDR model). Though poor people are most at this planet nowdays. Other can watch colour SDR movies at the daylight at sunlight-viewable displays with 2000..4000+ nits of max(nominal) white. Way better in compare with HDR-capable displays for poor people rated for limited time and limited part of frame peaked brightness to 1000..1500 nits. SDR really not limited to displaying setup of only 100nits and also viewing colour content at so low brightness you limit best colour viewable range to about 10:1 . Below 10nits human vision start to degrades colour saturation and below about 0.1..0.01 it decays to greys only. So to view about 1000:1 dynamic range of 8bit SDR in full colour having dark grey (about 17..18 code value at 8bit limited) at 10nits it is better to have DolbyVision-class 10000 nits fulltime fullframe unlimited display (not very cheap product and eating lots of power). And viewing conditions about mid-shaded daylight about 1000..5000+lux average room lighting (also only very poor people have very dim lighting about 1xx lux or lower at evening/night resting at home after all day hard work).
10000nits are really not any great brigthness - the about 0.7 diffuse reflective office paper at direct sunlight 100000lux have brightness about 20000nits and you still not have any headroom for highlights (natural sun highlights can go significantly higher 100000 nits - like in water objects and so on still non-metal mirrors).
So even still not present at poor people market possible HDR-10000 displays still not cover standard daylight diffuse only reflecting scenes with 'natural 1:1 physical brightness mapping'.

"but can you imagine how long H.264 will stick around? I mean, it was such a good codec in terms of patents and x264 was such a good encoder that it will probably stick around for years to come and the fact that broadcast companies adopted XAVC Intra Class 300 and 480 for UHD workflows will make it stick around even longer ehehehe."

In distribution and endusers it mostly probably till the end of current civilization (possibly less 1 century time left, or even much less). h.264 and x264 for AVC-Intra encoding is possibly very poor solution when you try to cosplay some better MJPEG coder with completely different target designed MPEG coder.
As you see todays it end with very poor performance when about somehow optimized by residuals of programmers frame analysis part in x264 run at about 10% of processing time. And may be 80 and more % of time for your I-frames coder cosplay from x264 you run with very non-optimized CAVLC not-video non-image oriented simple raw data compression engine. And more badly it is forced to keep about equal output bitrate with significantly different in complexity frames without permission to simply keep same quality level and fill bitstream with zero stuffing when frame is simple if your application forces you to have constant bitrate.

So it looks in AVC-intra I-frames CBR encoder cosplay the x264 program runs tons of iterative loops of different quantizer blocks encoding and after (slow and not optimized) CAVLC compression tried to see if it reach your target system bitrate any good. Not really nice solution. CAVLC data compressor is unlikely will be optimized because it is already replaced by better CABAC at general poor public usage and your old industry standards for AVC-Intra not allow to use CABAC - bad.
May be for professional industry exists some hardware ASICs for this AVC-Intra CBR encoding. General public unlikely need such slow and not optimal solution with varied quality over frames and slow encoding rate algorithmic solution. So general usage of x264 is crf-based IPB VBR.

" there's one thing I'm particularly happy about: more stops in cameras and more nits in contents."

1. About several decades already may be from begining of rec.601 digital the good quality broadcast-class video cameras had HDR internal processing - it required to have about 600% non-clipped dynamic range above nominal white (for 2/3 chips classic SD camera). Better product may have 1000% and more range above nominal white. At the 'before public HDR standards' time the camera control person may either hit AUTO KNEE option or manually play with KNEE POINT/ KNEE SLOPE adjustments per scene to have _non_standardized_ HDR compression of scene highlights into SDR valid codevalues range (8 or 10bits). So some 'non-standard-HDR' are really work non-advertized over many decades. With good broadcasters using not very cheap low dynamic range cameras. Only because of per-scene manual or auto-compression of dynamic range without signalling about it - the decoder display device can not fully decompress its range close to natural-scene linear. But it displays without hard clipping. The public-HLG HDR is only putting normatives to compression transfer curve of highlights above nominal (diffuse) scene white. So display device can perform better backward decompression of range above nominal white (and display more or less correctly depending on how much power of light do it have).
Also as cameras start move from SD to HD the noise-limited dynamic range become lower so we were need some years of advancing of incamera noise reduction so you again have about 60dB SNR at HD (and may be already in UHD) camera with still providing some headroom untill white clipping to have data for HDR compression.

2. Nits is completely not directly connected to the displaying of SDR or HDR video system. As described above. Nits only depends on how many money can put customer in display device to have none or time/area-limited or unlimited high-nits display. The xvid-coded 8bit SD/HD SDR content may be nicely displayed at good 2000+ nits full-time full-frame unlimited daylight vieweable open air home private person usage display device.
https://cdn.mos.cms.futurecdn.net/n5Vm2boAkvnnHWZzQfmUxk-970-80.jpg.webp (image from https://www.tomsguide.com/reference/how-to-buy-the-best-outdoor-tv , may not displayed in forum)
To not live in dim grey visible environment poorly and partly visually coloured and to see full saturated coloured range down to the very darks we need to live in good enough lit areas (or good enough lit indoors).
Sorry for users of HDR-like hardware of area+time limited poor 1000nits cheap displays for poor general public. No usage of AVC or 265,266 or more numbered by geeks codecs can help to display real physical power light and visible colour range if not enough money put to power of hardware light. So WCG+HDR with very dim 1000nits or less poor displays also really not fully correct stuff. The dangerous words 'colour volume' already passed to public market and only good enough powered displays can reach really good visible colour volume (not just encoded in zero-cost digital file of any codecs/bitdepth).

[FranceBB]

1. About several decades already may be from beginning of rec.601 digital the good quality broadcast-class video cameras had HDR internal processing - it required to have about 600% non-clipped dynamic range above nominal white (for 2/3 chips classic SD camera). Better product may have 1000% and more range above nominal white. At the 'before public HDR standards' time the camera control person may either hit AUTO KNEE option or manually play with KNEE POINT/ KNEE SLOPE adjustments per scene to have _non_standardized_ HDR compression of scene highlights into SDR valid codevalues range (8 or 10bits)

That is correct if it wasn't for the fact that cameras originally only had around 6 stops which leaves no headroom for highlights. Only after that, they improved beyond the 6 stops and nowadays they're doing what you described internally. But in SD days? No chance.
But even nowadays, some cameras don't really have many stops and therefore they don't have a large enough bracket to get all the frequencies.
This is just an example: look at the sunlight, the camera sensor had too little stops to be able to record the sky and therefore it's clipped out at 0.7V.

https://i.imgur.com/7K2vRFZ.jpg

This is a classic example and it's something my colleagues and I refer to with "the sheet is too short". With that expression, we mean that the camera has a bracket of x stops and no matter if you move it up or down, you'll always end up sacrificing something, be it the whites or the blacks of the image. In 99.9% of the cases, the person talking (i.e the presenter) is the most important subject, so that one is where the stops focus around and you'll be able to clearly see the face of the person talking, however the sky will be clipped out (in fact it's white). If you did the other way round, you would have preserved the sky, but the face of the presenter would have been completely averaged out in the dark region and you wouldn't be able to see it.

This, again, is all occurring in BT709 SDR 100 nits and it just shows the limits of SDR.
Sure, you could have a feed recorded by HDR cameras in a totally logarithmic curve like Slog3, Clog3, LogC etc and then perform the BT709 mapping, but realistically, for news, this ain't gonna happen.
One day, though, when everything will be HDR, the cameras will be able to record automatically in let's say HLG and then the same feed could be used live without additional mapping or conversions unlike Slog3, Clog3, LogC etc that would require mapping to PQ and you can bet anything that if today this technology was already widespread and implemented and everything was shot and recorded and aired in BT2020 HLG 1000 nits, the sky would have been there and it would have been blue ;)

[kurkosdr]

"keep watching SD BT601 8bit 100 nits stuff on their TV 'cause "it just works"..."

Only extra poor people watch SDR content at 100nits very poor displays (I also use such Philips-china 4K SDR model).
If not having an UHD TV is considered "extra poor", then I guess most people are "extra poor" according to that weird definition.

[kurkosdr]

Honestly, though, we're here discussing about Xvid still being around, but can you imagine how long H.264 will stick around?
Forever. It's the "lowest common denominator" video format for the web and hence an essential part of the web standards (at least defacto). I consider H.264 to be the video equivalent of GIF: it doesn't have the bit depth we want it to have, or the compression efficiency we want it to have, but everyone has implemented its "high" profile so it's the lowest common denominator.

If you want to use something newer than H.264, you have to encode in both VP9 and HEVC (and deal with the patent mess of HEVC) because Apple still plays hardball and doesn't support VP9 in Safari. Or, more realistically, encode in VP9 and give everyone else H.264 until they decide to use a browser that doesn't such as much as Safari or whatever.

I just hope everyone agrees to implement 10-bit H.264 with HDR support, so at least FullHD HDR is possible everywhere. But even if not, expect H.264 to be implemented for the rest of time in browsers like GIF.

[DTL]

"I consider H.264 to be the video equivalent of GIF: it doesn't have the bit depth we want it to have, or the compression efficiency we want it to have, but everyone has implemented its "high" profile so it's the lowest common denominator."

The 8bit SDR is really the high-visual art standard for decades in the great civilization of previous century. Its 1000:1 dynamic range is selected very close to nominal output dynamic range of reversible professional film for artists. It is not limitation of the reversible film type - the great old civilization capable of the flight to the moon can easily reach 1000000:1 display dynamic range simply combining 2 layers of 1000:1 for example but it looks the 1000:1 was good enough.

Also about input dynamic range for good art images - it is also very narrow like about 5 'stops' (also see Fuji Velvia datasheet for example or any Kodak reversal natural shooting film). It is because to make scene image pleasant to look it required complex enough expanding at middle and compression at the edges (so incoming about 5'stops' about 50:1 scene light range is expanded to about 1000:1 display light range by film processing for example). Also the real art transfer curve is not linear (and really curve - not straight line) and it is also not limitation of old century chemicals. If required 3.0D range linear transfer user can shoot linear duplication film for reversal film (so it have 3.0D input range and 3.0D output with linear transfer). But good visual artists already found in the previous century about linear scene shooting in the 'large range' for example 3.0D is about 10'stops' is not any good for viewers and not make good money in business.
It is applied to correctly designed by visual artists images - not to reatime 'live' broadcasts shot with some random non-prepared scene by very cheap personnel without special visual arts education.

But as we see at least some part of 8bit xvid encodings are for really good mastered (good DVD titles for example) content so it is perfectly enough. If we use xvid to compress poorly shot cheap TV shows - it is not issue of xvid or 8bit and only badly shot input content.

So when we have correctly mastered by enough good educated person and visual artist content we can freely use SDR 8bit and xvid to make perfectly good encodings.

"10-bit H.264 with HDR support"

We can assign some HDR decompression profile to standard 8bit encodings - it only may have more banding at highlights. The HDR itself not limited to any bitdepth - only limitation is more or less visible banding (if dithering is not applied) at some target physical display brightness levels. It is close to 'legal expanding' of over-whites (range of 236..254 code values of Y-channel in 8bit or even to 255 because we are not limited to system-service-reserved words like in SDI) into standartized-HDR like HLG. Older displays may already do it in customized vendor's solutions for 'image enchancements'.

HDR is not main part of good image design - it only a small additional way to a bit more impress user when all other underlying structure of tone and colours in image is perfectly mastered and most of important range is already fit in SDR (and standard colour gamut). If you can not view in HDR mode - you can easily skip HDR-addition to perfectly mastered SDR content and you will not lost significant part.

[FranceBB]

We can assign some HDR decompression profile to standard 8bit encodings - it only may have more banding at highlights. The HDR itself not limited to any bitdepth - only limitation is more or less visible banding (if dithering is not applied) at some target physical display brightness levels. It is close to 'legal expanding' of over-whites (range of 236..254 code values of Y-channel in 8bit or even to 255 because we are not limited to system-service-reserved words like in SDI) into standartized-HDR like HLG.

Correct.
Sony has been doing 8bit H.264 BT2020 HLG HDR in their old Sony A7 III cameras and they were using the expanded values of Full PC Range to take advantage of the extra headroom to make it fit better. I've seen plenty of footage shot like that. In most cases it was "good enough" (i.e it wasn't terrible, but it wasn't great either).


I just hope everyone agrees to implement 10-bit H.264 with HDR support

Sony is gonna be your best buddy, here, then, 'cause they actively support 10bit H.264 BT2020 HLG HDR in their cameras, both Intra and Long GOP (i.e I-P-B) in their XAVC flavor and of course x264 can encode those and add the right metadata. Unfortunately for you, though, no consumer hardware will play those, only professional hardware playout ports, so... it looks like it's not gonna be a thing at consumer level as such a stream is almost always re-encoded to H.265... but you know what? Never say never and most importantly if all you care about is software playback on computers, you can totally do it even today as support for HDR metadata was introduced in 2017 in x264.

[DTL]

" 8bit H.264 BT2020 HLG HDR "

Expanding frame size 2x linearly +dithering (2x2 samples dithered) may be about same as 10bit (8bit +2bit from 2x2 dithering) per sample with original frame size (in terms of banding). Only 2x frame size +dithering may cause more or less higher MPEG output bitrate.

So when wider compatibility with 8bit MPEG-4ASP/AVC decoders +HDR built-in is required it may be achieved with increasing frame size +dithering (or simply not downsize 8K..4K or FullHD too much).

Also WCG from BT.2020 is not very required in general public content so it is no need to shrink colour gamut of 'normal scenes' to 8bit system and risk to have additional colour banding.
The main point of 'artistic' image creation is not shrinking all-world-around data (luma range, chroma range and angle of view) to the single image frame but finding pleasant to view limited size scenes and expanding part of (luma and chroma) range for even better visibility of something pleasant to see (because viewer have limited ability to see small deviations in luma and chroma in natural scenes). So using of WCG in the bit-limited 8bit system is additional source of banding errors and lost of valuable low contrast colour details when operating with natural scenes.

So that attempt to use 8bit BT.2020 (+HDR) system was simple temporal marketing buff with attempt to sell the colour-details-shrinking system to artists. The sales possibly was not any good as well as shooting result.

So 8bit-dithered MPEG-4ASP/AVC bt.709 chroma +HLG range compression encoding (mapping) may be wide-used and backward compatible 'HDR for general public' format. It possibly will run a bit dimmer at SDR decoders if use 75% as nominal white point as in HLG. Sort of SDR+ 8bit widely compatible format. At the good enough users playback devices with 'HDR light power output' and good enough 'AI SDR to HDR' processing in display it will run closer to 'real 10-bit HDR'.

Though HLG HDR range mapping was already designed to very easily downconverting to SDR (for example with applying AUTO KNEE camera processing to decoded to linear scene light content).

The SDR digital motion pictures system was designed by the great designers of the nice great technical civilization of past so enough self-balanced. The only good addition (as well as defining finally 4:2:0 display UV filtering transfer curve at decoding to 4:4:4) is putting standard to usage of upper part of Y-code values for HDR-range expansion.
In old times CRT displays where very poor to run over 100..200 nit at home-sized TVs so the great old designers of the great old civilization are gone until the usage of upper codevalues of 230..254..255 of 8bit system for highlights compression up to 600..1000 nits become really usable at endusers displays.

[kurkosdr]

Sony is gonna be your best buddy, here, then, 'cause they actively support 10bit H.264 BT2020 HLG HDR in their cameras, both Intra and Long GOP (i.e I-P-B) in their XAVC flavor and of course x264 can encode those and add the right metadata. Unfortunately for you, though, no consumer hardware will play those, only professional hardware playout ports, so... it looks like it's not gonna be a thing at consumer level as such a stream is almost always re-encoded to H.265... but you know what? Never say never and most importantly if all you care about is software playback on computers, you can totally do it even today as support for HDR metadata was introduced in 2017 in x264.
Consumer HD hardware (aka consumer H.264 hardware, these two are mostly synonymous) will stay SDR-only. It can't do tone-mapping and even in the rare cases it can it's very rare that a manufacturer will send an update and risk losing sales of new hardware. What I am talking about is HLG HDR for H.264 in browsers. That way a common format (H.264) everyone implements and everyone accepts its royalty structure/patent situation can be used to provide HLG HDR (if only at FullHD due to the inferior compression efficiency compared to VP9 or HEVC). It's a missed opportunity, as it could instantly enable HLG HDR in almost all browsers. And the website can use Javascript to only serve that kind of content to browsers that understand it and can tone-map it. And if they allow 8-bit, they can even use existing hardware acceleration, which means that, assuming the CPU can take on the load of tone-mapping, there will be no missed frames.

[Balling]

If not having an UHD TV is considered "extra poor", then I guess most people are "extra poor" according to that weird definition.

No UHD TVs are 100 nits out of the box. So in fact you should be extra rich and clever to go buy Calman and X-rite and calibrate (though LG C2 has Filmmaker that is supposed to be 100 nits and LG C9 has 100 nits mode in Technicolor expert, right).

[DTL]

No UHD TVs are 100 nits out of the box. So in fact you should be extra rich and clever to go buy Calman and X-rite and calibrate (though LG C2 has Filmmaker that is supposed to be 100 nits and LG C9 has 100 nits mode in Technicolor expert, right).

If you buy some UHD-for poors like Philips 40PUT6400 you can find it 4K VA-panel and even can decode 10bit h.265 some profile but eating 100+ Watts it can only emit some inbetween 100 and 200 nits. Like poor old CRTs. Very poor LEDs in backlight mounted.

I really impressed how business-level sub $10000 display of LG (simple 8bit SDR for xvid playback) eat only 400 Watts peak and run at up to 4000 nits fullscreen all time. Having about 50 inches sized screen.
https://www.lg.com/uk/business/digital-signage/lg-49XS4F-B
Really nice LEDs installed in backlight. May be much higher 100 lm/W. Really right 8bit SDR display running dark blacks at about 4 nit and peak whites at 4000 nits - close to 'full visible colours down to the very deep darks'.

[benwaggoner]

Apple's HEVC HLG with Dolby Vision dynamic metadata is really a very clever solution as well. Certainly not the headroom possible with native Slog3 or PQ, but about as much as you're going to get while still having decent playback without tone mapping on existing SDR devices.

Getting back to xvid, yes, there are all kinds of ways to make stuff forward compatible. But any device that can handle the above will support at least H.264 High Profile.

I wonder if there are new devices shipping that have dropped MPEG-4 pt 2 decode. I saw one of last year's GPUs dropped HW VC-1 decode, for example. And VC-1 was somewhat more advanced that MPEG-4 ASP, with Overlap Transform and (lightweight) in-loop deblocking.

[benwaggoner]

Consumer HD hardware (aka consumer H.264 hardware, these two are mostly synonymous) will stay SDR-only. It can't do tone-mapping and even in the rare cases it can it's very rare that a manufacturer will send an update and risk losing sales of new hardware.
Well, it's inaccurate to say that there isn't any tonemapping. All flat panel technologies respond a lot differently than a Cathode Ray Tube would. Lots of tone mapping takes place in the panel controller to get it to respond to digital values like a CRT would to voltage. It's not like a LCD has intrinsic 2.2 or 2.4 gamma!

[kurkosdr]

Well, it's inaccurate to say that there isn't any tonemapping. All flat panel technologies respond a lot differently than a Cathode Ray Tube would. Lots of tone mapping takes place in the panel controller to get it to respond to digital values like a CRT would to voltage. It's not like a LCD has intrinsic 2.2 or 2.4 gamma!
They don't do tone-mapping for HDR though, it should be clear from the context that's what I meant.

[FranceBB]

What I am talking about is HLG HDR for H.264 in browsers.

Uhmmm, I'll tell you what, I think it could work even right now. H.264 can transport HDR info in SEI so it's very easy to create an 8bit BT2020 HLG file. Chrome also is able to recognize the desktop colorspace and the normal video stream info (chrome://gpu), so in theory it should be able to recognize an H.264 stream flagged as arib-std-b67 and bt2020-10 just like it's able to recognize it if it's an AV1. I mean, it should actually work already out of the box with the current technology without any further update, in theory, but no one is doing it.

[DTL]

Here is example of article why 8bit SDR xvid is always enough to encode correctly shot content - https://www.kenrockwell.com/tech/highlight-shadow.htm . The extra HDR is mostly way to bring to viewer 'RAW' shooting content so it need to create colour and tone grading by itself or suffer from non-graded cheap content. For live broadcasting without controllable scene light is may be some solution.

Short text extra is:
I was watching some old movies from the 1930s, and noticed how even back in those days that they had perfect shadow and highlight detail in every scene, be it daylight, back light, side light, indoors, moonlight, low light, candle light, or whatever.

Check out Mohawk Valley, shot in Technicolor in 1939, or The Plainsman, shot in black-and-white in 1937. These aren't even technical masterpieces; they just happened to be old Indian movies we were watching as I noticed this.

An indoor scene with a door open to the outside world? Perfect detail everywhere. The same thing, but moonlight outside reflecting off a river seen as through a window while the actors are indoors at night? Again, perfect!

No matter how tough the light, they always had perfect shadows and perfect highlights, be it in color or in black-and-white.

How can this be? There must be at least 15 stops of dynamic range needed, and film was primitive in those days.

Of course the movies have always had perfect highlights and shadows. How? Why? Because they are shot by real photographers, typically ASC members, who know how to light a scene.

When shooting a movie, you spend a couple of days lighting each set and each scene. You bring four generator trucks and eight trucks of lighting and grip equipment, and have at it. You'll scrim, gel, gobo and reflector everything until you go blind.

In the end, you get perfect results, even if it was the 1930s.

Photographers know how to get perfect highlight and shadow detail in every shot, regardless of the light — or lack thereof — while hobbyists freak out and start buying more equipment, like pro digital backs claiming "18 stops dynamic range," which has nothing to do with getting good highlight and shadow detail.

It is always the photographer who is responsible for highlights and shadows, not the Great Spirit inside a new camera.

[102030]

I still convert all movies with Xvid. I have the most experiences with this codec (13 years).
I really dislike h264 deblocking. The Xvid results are better for me than with x264.

But there is also one issue that bothers me. Xvid changes the naturally vivid colors. I think it converts yv12 to rgb.
Is there a way to prevent this problem? yv12 input --> yv12 output

[Emulgator]

YUV to RGB OOTB ?
I don't think so, implementing MPEG-4 ASP after all why would one sacrifice the efficiency of chroma subsampling.
mediainfo will tell.

[Selur]

probably a tv vs pc scale or color matrix issue.

[102030]

I have read that Xvid only work with a RGB32 input, and Divx only works with RGB24.
Therefore i guess, these codecs convert the colours while encoding. (i use only directshow, mostly graphedit)

[filler56789]

I have read that Xvid only work with a RGB32 input, and Divx only works with RGB24.
Therefore i guess, these codecs convert the colours while encoding. (i use only directshow, mostly graphedit)

If you use Avisynth with VirtualDub's fast-recompression-mode,
you can confirm that both DivX and Xvid accept YV12 inputs.

But if you want or have-to use DirectShow anyway, then
1) replace graphedit with GraphStudioNext, and
2) don't let the ""smartness"" of DirectShow add unnecessary colorspace conversions to the graph.

[102030]

If you use Avisynth with VirtualDub's fast-recompression-mode,
you can confirm that both DivX and Xvid accept YV12 inputs.

But if you want or have-to use DirectShow anyway, then
1) replace graphedit with GraphStudioNext, and
2) don't let the ""smartness"" of DirectShow add unnecessary colorspace conversions to the graph.

Thank you, i will try this possible Avisynth solution soon. I did no colorspace conversions in my graphs.
I did always deactivate the colorspace filter in the Windows registry.

[DTL]

MPEG-4 still not dead !

Some new idea in progress to make ASP/AVC releases looks better - https://forum.doom9.org/showthread.php?p=1984472#post1984472 . Sort of backporting some features from h.265/HEVC to lower numbered MPEGs. So wider compatibility moving pictures files my be created.

[benwaggoner]

Uhmmm, I'll tell you what, I think it could work even right now. H.264 can transport HDR info in SEI so it's very easy to create an 8bit BT2020 HLG file. Chrome also is able to recognize the desktop colorspace and the normal video stream info (chrome://gpu), so in theory it should be able to recognize an H.264 stream flagged as arib-std-b67 and bt2020-10 just like it's able to recognize it if it's an AV1. I mean, it should actually work already out of the box with the current technology without any further update, in theory, but no one is doing it.
HLG is HDR-lite, however. And nominally requires 10-bit. The only reason anyone ever uses HLG as the same bitstream can provide reasonably decent SDR and HDR. But bang-for-the-bit is always better doing native SDR or native PQ HDR if universal compatibility isn't required.

HEVC is the current standard for HDR because:

HDR typically comes with 4K, and HEVC is >2x as efficient as H.264 at 4K resolutions. These are big files, so the lower bitrate is really helpful.
Real (PQ) HDR needs some clever QP offset tuning for optimal results, which has only been well documented for HEVC. That's what x265's --hdr10opt implements.
All HDR capable CE devices support 10-bit HEVC decode, even though many of those only support H.264 up to 8-bit.


Sure, whacky things can be done with full range mapping and dithering and all that. Heck, I could make HDR MPEG-2 with sufficient motivation and time. But in the end it's a lot of work and a lot more bits for worse results, and no real reason to bother. Essentially everything with an HDR tone mapper and display supports 10-bit HEVC decode. We'll upgrade to better thing in the future, like VVC and/or AV1. But I can't imagine why anyone would practically benefit from using a sub-HEVC codec for HDR.