Is XVID still used? [Archive]

FranceBB

20th June 2021, 00:03

It's not uncommon for a subbing group to do double or triple releases - the same content both as HD x264 and as SD xvid, for example.

True, I've seen fansubbers do that a lot...

Xvid may not be better in visual quality but it does have its forte. It's lightweight, tried and tested, player-side is always ready. Have you ever tried for example x264 with output color space 422 or 444 or even RGB? I don't think player-side is always ready yet if you use not-so-common options.

Well, long time ago if you were using something like --ref 16, --me esa --subme 11 --preset placebo and reverse upscale to 1280x720 with 4:4:4 10bit, it was really hard to play 'cause it would have been CPU only with no GPU hardware acceleration and pretty heavy for the CPUs we had at the time, but nowadays we no longer live in an era in which 4c/8th Intel i7 were priced as gold, they could barely bear the load and AMD CPUs were not really usable... I mean, we've come a long way since then...
Still, I understand the "legacy" thing and the fact that most groups have been doing SD releases in Xvid since... well... forever and they're still doing it, so... fair enough. :)

Of course that does not mean newer codecs are bad - they're good and loved. But do we have to disrespect xvid just because we use newer codecs? Like, MP3 is still popular, even though there are Vorbis, AAC, Opus.

MP3 is a different thing: it's so bad that even MPEG actually begged users to please stop using it a few years ago. I mean, it was ok for primitive devices, portable MP3 players I used to use when I was a young lad and I was going to school (https://images.says.com/uploads/story_source/source_image/543949/9630.jpg), listening with crappy old earphones, but I mean, nowadays AAC is widely supported everywhere: smartphones, cars, stereos etc. It's so supported that it's the de facto standard for DAB and DAB+, so I would very much like AAC to be adopted by everyone and I would love to see MP3 die once and for all. It's a crappy codec with a crappy psychoacustic model based on the filterbank polyphase that just has to die and has no meaningful use case in the modern world...

Liisachan

21st June 2021, 00:21

Okay, MP3 may not be a great example here. (However, although people say MP3 is bad and that is true in some sense, when double-blind-tested, maybe 99% of them can't ABX Lossless vs. MP3 @ 160, even @ 128. At least I can't...) Anyway, back when DivX was rather common, and coming with a bunch of unwanted bloatware, Xvid devs were stoically providing free (as in freedom), clean codec, even though there were potential legal/patent complications too. At least that's how I remember it. Newer codecs are great, yes, but we don't need to be disrespectful, especially given that Xvid is still useful in some limited areas...

Katie Boundary

21st June 2021, 02:19

Compatibility > efficiency

Every time.

Every. Goddamn. Time.

hello_hello

21st June 2021, 13:52

MP3 is a different thing: it's so bad that even MPEG actually begged users to please stop using it a few years ago. I mean, it was ok for primitive devices, portable MP3 players I used to use when I was a young lad and I was going to school (https://images.says.com/uploads/story_source/source_image/543949/9630.jpg), listening with crappy old earphones, but I mean, nowadays AAC is widely supported everywhere: smartphones, cars, stereos etc. It's so supported that it's the de facto standard for DAB and DAB+, so I would very much like AAC to be adopted by everyone and I would love to see MP3 die once and for all. It's a crappy codec with a crappy psychoacustic model based on the filterbank polyphase that just has to die and has no meaningful use case in the modern world...

Today's youth.... no idea how good they have it. ;)
When I was young and going to school, my portable music player looked very much like this:

https://i.postimg.cc/KkpQhmqZ/maxresdefault.jpg (https://postimg.cc/KkpQhmqZ)

Mind you that's way more fancy than the one I owned because FM radio didn't exist and the Cue function was, if I remember correctly, a manually implemented feature involving holding the play button half way down while fast-forwarding and hoping it wouldn't end in tears. The only psychoacoustic model I was aware of when I went to school involved a portable player's lack of Dolby B to make pre-recorded cassettes sound brighter.
Ahhh... how I fondly remember performing regular maintenance on my player's storage medium with a hexadecimal pencil.

https://i.postimg.cc/gXwDqfsr/3b1f3b462b.jpg (https://postimg.cc/gXwDqfsr)

Seriously though....
The folks at hydrogen audio are confident the LAME MP3 encoder is transparent using the default VBR mode, despite MP3's limitations,
https://wiki.hydrogenaud.io/index.php?title=LAME#Recommended_encoder_settings
which makes me happy because my current MP3 player doesn't support AAC and a quick google indicates Cowon's latest players still don't support it. I assume they've decided to save themselves the licence fee.

You've inspired me to start a new thread on portable players though, as I'm considering the possibility of contemplating upgrading mine, but rather than sidetrack this thread any further I'll start a new one in the General forum.

StainlessS

21st June 2021, 17:49

because FM radio didn't exist
Wow, you must be ancient :)
When I was a kid, my mother had [in the kitchen] a 5 band radio that had FM, and could pick up airplanes, taxi's, police, and even TV audio.

EDIT:
FM broadcasting is a method of radio broadcasting using frequency modulation (FM). Invented in 1933 by American engineer Edwin Armstrong
FM broadcasting[wikipedia]:- https://en.m.wikipedia.org/wiki/FM_broadcasting

EDIT: When I was about 12, my little brother turned a joke into a pretend competition letter [in a kids comic],
star letter prize was a nifty leather cased, 3 band transistor radio. [long/short/medium wave, no FM]
He said his little borther [Ie, me, his big brother] had come home from his first day at school crying, when asked why he [I] said
that he was told he was gonna get free school dinners, but he only got one. [free <-> three - he won, I shoulda had half ownership I think]

EDIT: Some years later, the same brother ended up fixing TV's and Radios for a company which did servicng for a big well known
corporation [was owned by same corp]. The major share of repairs was on radios, and they charged £18.00 + parts as standard charge.
The vast majoirty of problems was dud battery, so he spent a lot of the day just inserting new batteries and charging £18.00 + the
price of the batteries. Easy money. [quite a sum about 1975]

EDIT: Also, you could use a BIC biro pen instead of a hexagonal pencil to swizzle a cassette.

EDIT: And the first mobile phone call was about 75 years ago [demo'ed June 17 1946, first hand held in 1973]:- https://metro.co.uk/2021/06/21/mobile-calls-for-75-years-how-tech-goes-from-breakthrough-to-big-time-14790880/

EDIT: One guy I went camping with when about 14YO, had a battery operated record player, never seen one like it before nor since.
EDIT: Not sure, I think the record player worked kinda like a bread toaster [just for singles, not LP's].

GMJCZP

21st June 2021, 19:07

I still use Fhg MP3 with BeHappy and Adobe Audition. Because? because at 128 kbps CBR is preferable to Lame, but I admit that the latter should be more efficient according to what hello_hello says. My preference for CBR is from the times of VirtualDubMod and muxing avi video with mp3 audio, this program recommends not using MP3 VBR but MP3 CBR to prevent a desynchronization, but I recently took an mp4 video and converted it into avi xvid and the audio with lame converted it to three audios: CBR, ABR and VBR. These three equal XVID videos I tested on my LG DVK-9713N and curiously I noticed that the videos with ABR and VBR audio did not get out of sync, which made me think that if I had encoded in VBR in a series that I edited a while ago in XVID the audio would have been better, since, imagine, it was 56 kbps CBR, anyway it was an extreme compression test, it is a series of 56 chapters to 28 chapters per 4.7 GB DVD.

Edit: that radio photo reminded me of my defunct Silver Crown recorder, those 80's...

Blue_MiSfit

21st June 2021, 21:20

Compatibility > efficiency

Every time.

Every. Goddamn. Time.

Agreed! But H.264 hardware decode is utterly commonplace on any device shipped in the last decade.

I know there's a pool of legacy devices (especially outside of the biggest / wealthiest countries), but this will continue to dwindle down.

SeeMoreDigital

21st June 2021, 22:15

but I mean, nowadays AAC is widely supported everywhere: smartphones, cars, stereos etc. It's so supported that it's the de facto standard for DAB and DAB+, so I would very much like AAC to be adopted by everyone...
Here in the UK all BBC radio stations and many major commercial radio stations still use basic DAB (MPEG-1 Layer 2)!

The adoption of DAB+ (HE-AAC) has been very slow and sloppy here, primarily due to the quantity of early DAB radio adoptees who's devices don't support DAB+...

hello_hello

22nd June 2021, 10:37

Wow, you must be ancient :)
When I was a kid, my mother had [in the kitchen] a 5 band radio that had FM, and could pick up airplanes, taxi's, police, and even TV audio.

EDIT:

FM broadcasting[wikipedia]:- https://en.m.wikipedia.org/wiki/FM_broadcasting

It would have been more accurate to say nobody was broadcasting.
I don't think my portable player had an FM receiver, but the first... cough... Hi Fi system I owned did. Remember when a Hi Fi system was made up of individual components? You bought an amplifier, a tuner, a turntable, a cassette player etc, but at some stage manufactures started combining them into "3-in-1" units. They eased us into it though by putting everything in a single box and designing it so it still looked like individual components, but wasn't. My first Hi Fi system was one of those. It did have an FM receiver but for the first year or so there weren't any FM stations broadcasting.

Apparently EON FM launched sometime during the year I turned 16. I would have said it was a couple of years later, but Wikipedia says it wasn't.
https://en.wikipedia.org/wiki/Timeline_of_Australian_radio#1980-1989

FranceBB

22nd June 2021, 12:53

Here in the UK all BBC radio stations and many major commercial radio stations still use basic DAB (MPEG-1 Layer 2)!

OMG! MP2?! Really?

The adoption of DAB+ (HE-AAC) has been very slow and sloppy here, primarily due to the quantity of early DAB radio adoptees who's devices don't support DAB+...

I see...

Today's youth.... no idea how good they have it. ;)
When I was young and going to school, my portable music player looked very much like this:

https://i.postimg.cc/KkpQhmqZ/maxresdefault.jpg (https://postimg.cc/KkpQhmqZ)

LOL "portable" xD

Mind you that's way more fancy than the one I owned because FM radio didn't exist and the Cue function was, if I remember correctly, a manually implemented feature involving holding the play button half way down while fast-forwarding and hoping it wouldn't end in tears.

FM didn't exist? (O_O)
Wow... I think about FM as something that has always been there... You guys must have been amazed by the sound quality when you moved from LW and MW to AM and FM ehehehehehehe

H.264 hardware decode is utterly commonplace on any device shipped in the last decade.

Exactly, which is why I find very odd the fact that some devices still don't have it...

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...

StainlessS

22nd June 2021, 13:45

FranceBB,
You guys must have been amazed by the sound quality when you moved from LW and MW to AM and FM ehehehehehehe
LW and MW (& SW) are AM (Amplitude Modulated).

HH,
Apparently EON FM launched sometime during the year I turned 16.
Switch on here in UK was in 1955:- https://en.m.wikipedia.org/wiki/FM_broadcasting_in_the_UK
I guess in Australa, take up was delayed as FM is more suited to short range, and Australia being Australia, would find longer range more useful.

Legal commercial broadcasting began in the United Kingdom in 1973, with the launch of LBC
although there were 'Pirate" radio stations before that.

EDIT: Radio Caroline and Radio Luxemburg being two, I think.
Caroline:- https://en.m.wikipedia.org/wiki/Radio_Caroline
Luxemburg:- https://en.m.wikipedia.org/wiki/Radio_Luxembourg
Pirate Radio:- https://en.m.wikipedia.org/wiki/Pirate_radio

FranceBB

22nd June 2021, 16:42

I didn't know LBC was so old!
I've been listening to Nick Ferrari for politics every now and then and also to Mr James O' Bryan Mystery Hour to which I also participated once in 2015 to say "It's a question, James" xD

hello_hello

22nd June 2021, 17:14

HH,

Switch on here in UK was in 1955:- https://en.m.wikipedia.org/wiki/FM_broadcasting_in_the_UK
I guess in Australa, take up was delayed as FM is more suited to short range, and Australia being Australia, would find longer range more useful.

I did unintentionally lie to you. When I said EON FM was our first FM station, I should have said "our first commercial FM station".
I don't actually remember the ABC having an FM station earlier than the 80's, but apparently ABC Classic FM began broadcasting to a non-existent audience in 1974.

I have a vague memory the government body responsible for broadcasting at the time made a decision on FM frequency usage that triggered a government enquiry, and I think a new broadcasting body was formed, or something....
No doubt FM radio also had to wait for TV to get out of the way. Channel 0 moved to 10 in Melbourne, but I'm sure it broadcast on both frequencies for a fair while. Around that time Murdock bought Channel 0, which triggered a government enquiry into media ownership.

After the commercial Channel 0 moved to 10 the new multicultural TV station SBS was given Channel 0 to use for a year or three. SBS broadcast simultaneously on Channels 0 and 28 initially, so anyone interested in watching the soccer would have plenty of time to buy a TV with a UHF tuner, assuming their current set lacked one.

I'm sure there was also some fuss over a country TV station having to make way for SBS because they were close to Melbourne and already broadcasting on Channel 28. Aside from all that though, I don't think the general public really had much interest in FM back then. Possibly because the majority of cars still had AM-only radios. Remember the "push button" tuning?

SeeMoreDigital

22nd June 2021, 17:18

Here in the UK all BBC radio stations and many major commercial radio stations still use basic DAB (MPEG-1 Layer 2)!OMG! MP2?! Really?

Actually... all 'first generation' DAB is MP2 :eek:

StainlessS

22nd June 2021, 17:58

Just be happy that it aint MP1 [layer 1].

SeeMoreDigital

22nd June 2021, 18:27

Just be happy that it aint MP1 [layer 1].Indeed...

That being said, back in the day I had an Technics DCC (Digital Compact Cassette) player/recorder, which I used to copy audio CD's to MP1 (Mpeg-1 layer 1).... They sounded pretty good.

But I preferred the greater flexibility and size of MiniDisc.

GAP

23rd June 2021, 16:41

I knew of MP3s but not MP1s. I am not that old as I was a kid in the nineties.

StainlessS

23rd June 2021, 19:10

Not sure but think maybe it used extender something like, mpa1, mpa2, mpa3 or [mp3],
for mpeg 1 layers 1, 2 and 3.
I'm also a kid, just a bit older than you. [when you get as ancient as me,you dont know that you are
ancient, except for comments from young fellas that seem to think that it aint ever gonna happen to them]
[in a few eye blinks, but it does and will].

mobile:

EDIT: Make the most of it, there are no "re-does".

FranceBB

23rd June 2021, 22:22

when you get as ancient as me,you dont know that you are ancient, except for comments from young fellas

Guilty :P

that seem to think that it aint ever gonna happen to them, but it does and will. Make the most of it, there are no "re-does".

Oh... :'(
https://memegenerator.net/img/instances/49481986/right-in-the-feels.jpg

Liisachan

24th June 2021, 12:08

For those who are curious, here's an actual sample clip [ xvid+mp1234.mkv (http://faireal.net/aaa/xvid+mp1234.mkv) ], using xvid 1.1 (!) from about 15 years ago + the same audio in 4 formats (MP1/MP2/MP3/AAC). The default Audio is Apple AAC, created today via qaac. The other tracks are ancient. There may be a small click noise at the start of the MP1 track.

http://faireal.net/aaa/mp1234.jpg

rwill

24th June 2021, 14:46

I have no clue about audio compression but to me Mpeg Audio Layer 2 sounds more "complete" to me than MP3 and AAC. I read something on Wikipedia about some difference between MP2 and MP3 with frequency bands but don't know if thats the root cause.

StainlessS

25th June 2021, 02:37

I think that MPA2 was/is legal in DVD VOB, but think MP3 not legal. [???]

Think i remember that MPA1 could be pretty awful recording rain or shower, could sound like broken glass fragments raining from sky.

SeeMoreDigital

25th June 2021, 09:45

I think that MPA2 was/is legal in DVD VOB, but think MP3 not legal. [???]Yep

Think i remember that MPA1 could be pretty awful recording rain or shower, could sound like broken glass fragents raining from sky.I noticed some weirdness when generating a few recordings. The only thing I could put it down to, was that the MP1 audio encoder had become overloaded. As the, "turn it off and on again" trick would resolve such issues...

Katie Boundary

26th June 2021, 21:17

But H.264 hardware decode...

There is a world beyond hardware decoding.

j7n

28th June 2021, 17:17

Since the complexity of x264 is scalable with options such as CAVLC, I don't see a point in using Xvid. Although nobody seems to produce fastdecode H264 files. x264 is much easier to use from command line in single pass compared to Virtual Dub.

In the 1990s I had only a medium/long wave radio powered by AA batteries in a paper tube. There were two modern pop stations, one local, and one from Ireland. It was receivable at night along with several others that didn't interest me at the time. FM certainly did exist, but I could not own a receiver.

Mediumwave radio used to be better. a) The bandwidth was not cut off at 5 kHz. Channels could overlap. b) There were no switching mode power supplies. I lived in a wooden house and reception was always clear. Now it is a hell inside reinforced walls when the power is on, especially in daytime. Every piece of electronic, digital garbage radiates through wires and walls up to around 8 MHz. Curiously, when power gets cut for repairs, the building does not impede reception. Orientation of the antenna for best reception matches outdoors. I am surprised that broadcasters still exist if people in cities can't hear them. c) There were not single frequency networks where distant transmitters interfere with one another. d) transmitters had more power, a megawatt was common.

My memory of reception quality has certainly faded. My ears were better then and expectations lower. But I remember the sound quite sharp and clear. I wonder if it was practical for a government back in the 1980s to broadcast interference through building walls to disrupt foreign broadcasts, as effectively as it happens now.

Later I got a big old radio with vacuum tubes that could receive FM, but the reception faded as the device heated up. It also had a different frequency range. But due to a malfunction could also receive the "western" band overlapped. VHF TV channels had a very strong mono signal compared to audio only.

MP3 from online sources often is encoded with poor settings and sounds bad than the AAC alternative. For downloadable content and physical media enough bitrate can be used that MP3 is completely fine.

StainlessS

28th June 2021, 18:16

On radio reception, here part quote from some time ago in another thread

So basically 'Heat Haze'. [I'de never heard the term Fata Morgana, looked Heat Haze up and it got me to Wikipedia Mirage:- https://en.wikipedia.org/wiki/Mirage].
I would not have any idea how to simulate heat haze.

Regarding the wikipedia Mirage link, Fata Morgana paragraph, "atmospheric duct" hilited popup, I think I once experienced that myself.
Back in 1981, I was stayng at a guest house in Bedfordshire countryside, about 5 of us were watching an Italian movie on analogue TV.
Due to weird atmosperic conditions, we could not pick up UK TV, only a single Italian TV station (maybe due to 'atmospheric ducting' which
probably acts similar to microwave WaveGuide used in Radar and microwave communications). the Italian movie of course had no subtitles
(as it was broadcast for Italians, not Brits), so we asked the Swiss girl with us to translate (she spoke Swiss German, Italian, French and English),
and we all sat there transfixed as she translated for a good 10 minutes, at which point she realised that nobody was watching the movie,
we were all fixed upon her. I said something like, "Enough of the French, how about giving it to us in English".
Some additional quite strange linguistic ducting had occurred.

Woz well weird. [EDIT: We normally (never) could not pick up any foreign TV stations at all]

kurkosdr

11th August 2022, 16:13

Apparently so,
quite often, in this [where this is posted, ie MPEG-4 ASP] forum, there are way - way more forum visitors than anywhere else on the D9,
so yes, ASP/XVID/DIVX is still quite popular, but I cannot say nor understand why.
Lots of car DVD players and lots of small TVs with integrated DVD players out there which support MPEG4 ASP but without support for H.264, and which still serve their owners faithfully. So, most people in this situation will download the H.264 version (usually MP4 or MKV) for their big screen TVs and the AVI file for those other devices. With a 30Mbit connection, downloading the AVI file takes like 3 minutes (disclaimer: I am talking about legal downloads yadda yadda).

kurkosdr

11th August 2022, 16:35

That's odd... but hey, apparently there are still people using it for... compatibility purposes?
I don't know...
Besides, I thought MPEG-2 was far more common than Xvid, not just for DVDs that are still being produced for some odd reason, but also for all the SD 480i or 576i TV channels out there that are still on air and also HD/FULL HD standards like XDCAM which just don't wanna die...
It feels weird to talk about these things in 2021, but hey, they're still a thing... :(
MPEG-2 is still big in the world of broadcasting due to all those SD receivers out there (and the reluctance of governments to tell the owners of such receivers it's time to move on). For example, in the UK there is a grand total of 8 HD channels, a couple of H.264 SD channels, and several dozen MPEG-2 SD channels that are broadcast at a very low bitrate and with lots of artifacts. I am talking about major channels that people actually watch that are only broadcast in crappy MPEG-2 SD.

However, MPEG-2 was never big on the internet, due to the fact it can only do widescreen at 720x480/576 resolution in its most common form (DVD-Video), which in turn forces high bitrates (together with the usual inefficiency of MPEG-2). And let's be real, nobody wants a file with mediocre SD video that weighs 4 frickin' gigabytes at minimum. So, MPEG4 ASP in AVI (aka Divx/Xvid) is the lowest common denominator on the internet. Sure it looks bad, but at least it's small and it plays even on most non-H.264 standalone players. Of course, it's always a good idea to also provide an H.264 version of the content.

kurkosdr

11th August 2022, 16:48

rwill

12th August 2022, 19:48

However, MPEG-2 was never big on the internet, due to the fact it can only do widescreen at 720x480/576 resolution in its most common form (DVD-Video), which in turn forces high bitrates (together with the usual inefficiency of MPEG-2). And let's be real, nobody wants a file with mediocre SD video that weighs 4 frickin' gigabytes at minimum. So, MPEG4 ASP in AVI (aka Divx/Xvid) is the lowest common denominator on the internet. Sure it looks bad, but at least it's small and it plays even on most non-H.264 standalone players. Of course, it's always a good idea to also provide an H.264 version of the content.

1. Necro
2. Mpeg-2 and Mpeg-4 ASP are not far apart in regards to compression efficiency if both encoder employ the same strategies. Mpeg-4 having the edge obviously.

kurkosdr

13th August 2022, 13:44

1. Necro
2. Mpeg-2 and Mpeg-4 ASP are not far apart in regards to compression efficiency if both encoder employ the same strategies. Mpeg-4 having the edge obviously.
1. Don't care.
2. As previously said, the problem with MPEG-2 is that, in its most common form (DVD-Video), it forces you to use 720x756/480 resolution if you want widescreen. This means you are looking at a 4GB file at minimum for an ordinary movie.

SeeMoreDigital

13th August 2022, 18:48

2. As previously said, the problem with MPEG-2 is that, in its most common form (DVD-Video), it forces you to use 720x756/480 resolution if you want widescreen. This means you are looking at a 4GB file at minimum for an ordinary movie.Actually you are wrong.

In the case of MPEG-2 DVD or DTV the 720x756/480 or 'D1' pixel frame size is always encoded along with either 4:3 or 16:9 DAR (ie: aspect ratio signalling). It is never distributed at 1:1...

rwill

13th August 2022, 21:27

1. Don't care.
2. As previously said, the problem with MPEG-2 is that, in its most common form (DVD-Video), it forces you to use 720x756/480 resolution if you want widescreen. This means you are looking at a 4GB file at minimum for an ordinary movie.

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.

kurkosdr

14th August 2022, 01:47

Actually you are wrong.

In the case of MPEG-2 DVD or DTV the 720x756/480 or 'D1' pixel frame size is always encoded along with either 4:3 or 16:9 DAR (ie: aspect ratio signalling). It is never distributed at 1:1...
Yes, 720x756/480 is always anamorphic (either for 16:9 or for 4:3), I never questioned that.

The real issue is that, according to the DVD-Video specs, only the 720x756/480 resolution can have the 16:9 flag, everything else (for example 352x288/240) can only be flagged as 4:3. Which is the real problem. If your content is 16:9, you have to use the 720x756/480 resolution (if you use the DVD-Video format), which means you have to use higher bitrates, which means you have to use at least 4GB for a half-decent picture.

So, where was I wrong? As I said in my previous post, DVD-Video forces you to use the 720x756/480 resolution if you want widescreen (16:9).

"Sure it looks bad, but at least it's small". Mpeg-2 video could have done this as well, SVCD being one popular standard.
No, it couldn't. And it's not for lack of trying by various people in the past.

First of all, SVCD doesn't do 16:9 anamorphic. Not reliably at least, aka with the players capable of signaling it properly (for 16:9 TVs) or putting black bars (for 4:3 TVs). So, you have to letterbox during authoring and manually crop/zoom in the TV's widescreen settings when viewing on a widescreen TV. DVD-Video only does widescreen at 720x756/480, which requires high bitrates (for the standards of the day, at least). And that's before we take into account the fact MPEG2 degrades much worse than MPEG4 ASP.

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.

Now, why is MPEG4 ASP used today? The answer is it's pretty small (700MB or 1400MB) and plays on pre-H.264 players. Nobody will download a 4GB (or 4.38GB) MPEG2 file for their car DVD player or for their non-HD TV-DVD combo in the kitchen. At least that's what I get by looking at the availability online. And for their big screen TVs, they will download the H.264 version :)

j7n

14th August 2022, 02:53

None of the existing MPEG-2 encoders that I'm aware of would encode to long GOPs, and would enforce a strict pattern of P/B frames that sometimes didn't even respect a scene change, leading to low quality. For playback on a computer you could always encode to square pixels, same as XviD, no?

rwill

14th August 2022, 07:11

...

Damn.

First the necro and then the borderline insane way to present random fact snippets as if they support your argument... and being dense.

Are you Ballings Twin ?

FranceBB

14th August 2022, 13:49

So, where was I wrong?

Here:

DVD-Video forces you to use the 720x756/480 resolution

720x576 is PAL anamorphic
720x480 is NTSC anamorphic
both can be flagged either 4:3 or 16:9 and it's gonna be the player that will re-scale them on the fly.

Now, why is MPEG4 ASP used today?

'cause people don't wanna throw away their 2002-era players and that's just sad...

None of the existing MPEG-2 encoders that I'm aware of would encode to long GOPs, and would enforce a strict pattern of P/B frames that sometimes didn't even respect a scene change, leading to low quality.

The state of open source MPEG-2 encoders is just sad...

The MPEG-2 Libavcodec encoder allows you to set an arbitrary GOP, however by default it assigns waaaaaaaay too many bits to the Intra, thus bit-starving P and B and the result is just... very poor.

x262 doesn't support all interlaced chroma sampling modes as it was a work-in-progress encoder and unfortunately it stayed that way 'cause it has been abandoned eons ago, so... nope (and I know 'cause I begged the creator to keep going back then).

kurkosdr

14th August 2022, 17:09

Here:
720x576 is PAL anamorphic
720x480 is NTSC anamorphic
both can be flagged either 4:3 or 16:9 and it's gonna be the player that will re-scale them on the fly.
I mean 576, sorry. Typo that got copied pasted all over. My point stays the same. DVD-Video forces you to use full D1 resolution if you want anamorphic 16:9, which, together with the fact MPEG-2 degrades much worse than MPEG4 ASP, means you are looking at a 4GB file minimum, which is more than what people are willing to download for SD.

'cause people don't wanna throw away their 2002-era players and that's just sad...

Yeah, but nothing you or me can do about it, right? Also, things like car DVD players can't be easily upgraded.

FranceBB

14th August 2022, 20:54

things like car DVD players can't be easily upgraded.

As a broke person trying to save money, wishing to get on the property ladder and become a home owner one day, I drive a poor-people car, so a 2009 Nissan Micra where everything is analog and I had to buy a bluetooth to jack adapter to even use my phone... eheheheheh

Anyway, my father's car, a Mitsubishi, does indeed have a DVD player which reads MPEG-2 with either MP2 or AC3 audio, but my parents have never ever used it 'cause due to silly Italian laws they're not allowed to use it while driving as it might distract the driver (even if he's not looking at it at all). The Italian firmware made it so that if you're driving, it won't play and it will tell you that the playback will resume once the car stops, thus making it completely useless, 'cause let's face it, who in the world would sit in his car, in a car park, to watch a movie on a small screen? xD

DVD-Video forces you to use full D1 resolution if you want anamorphic 16:9

Uhm... it's actually the other way round: DVD Forces you to use full resolution if you want anamorphic 4:3.

DVD 720x480 flagged as 4:3 will be rescaled to 640x480
DVD 720x480 flagged as 16:9 will be rescaled to 848x480

with those being MPEG-2.
Now, if you re-encode in xvid, you can toss away the ugly anamorphic thing and re-encode to a proper 1.77 (so 16:9) or 1.33 (so 4:3) and your argument stands, but for 4:3 'cause 640x480 4:3 1.33 is smaller than 720x480 anamorphic flagged 4:3, so you save space, but it doesn't apply for 16:9 'cause 848x480 16:9 1.77 is larger than 720x480 anamorphic :P

(I don't wanna be pedantic, I got what you're trying to say, but you know this forum is read by thousands of people every day, so I like to clarify things for people who will read it in the future :) ).

MPEG-2 degrades much worse than MPEG4 ASP

True, in general, if you compare apples with apples.
In the case of DVDs, though, you have MPEG-2 25i or 30i which are generally deinterlaced before being re-encoded to xvid. Even though xvid is better than MPEG-2, we should note that encoding an interlaced source takes less bitrate than encoding a progressive source, if the same codec is used. In other words, if I were to use MPEG-2 to encode the same source, but one time progressive and one time interlaced, the latter would take less bitrate.
Still, given that xvid is better than MPEG-2, it will still be able to yield an advantage even if it's progressive.

you are looking at a 4GB file minimum, which is more than what people are willing to download for SD.

"De Gustibus"
(I think it's widely used across the world, but if you don't know it's an ancient latin sentence used during the Roman Empire and you can find the meaning on Wikipedia (https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum))

kurkosdr

15th August 2022, 13:52

Nobody encodes Divx avi in 848x480 and most pre-H.264 devices out there won't even play it (because it's beyond the maximum resolution allowed by the "Divx Home Theater" profile, which is what those devices implement). Most widescreen Divx AVI files are 640x360, which is substantially less pixels than the 720x480 minimum resolution that DVD-Video mandates if you want to have anamorphic widescreen. Coupled with the fact MPEG4 ASP degrades less bad than MPEG2, it allows for substantial bitrate savings (for example, an entire movie on 1400MB or 700MB), without the sea of artifacts you would encounter if you targeted such filesizes on DVD-Video.

BTW, don't get me wrong, I wish more stuff was made available as 4GB, 4.38GB, or even 7.96GB DVD-video for people with old devices, but that's not what I am seeing around. Most stuff out here is either Divx avi (700MB or 1400MB) or H.264 (MKV/MP4).

rwill

15th August 2022, 17:27

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.

FranceBB

17th August 2022, 21:30

Nobody encodes Divx avi in 848x480 and most pre-H.264 devices out there won't even play it (because it's beyond the maximum resolution allowed by the "Divx Home Theater" profile, which is what those devices implement).

Right! I see! I forgot!
I took a look and yeah, I saw old ancient SD 4:3 encodes as 640x480 and my oooooooooooold SD 16:9 xvid encodes as 704x396 so that they were gonna stay within the profile constraint. To be fair, I should have remembered it given that I was one of the people who encoded in 640x480 and 704x396 in 2006-2007 for the Italian """branch""" of ADC-Elites (which then turned into OPF-Italia), but I forgot... it's been ages ago...

kurkosdr

30th August 2022, 19:03

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

30th August 2022, 19:53

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

18th September 2022, 19:09

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

18th October 2022, 11:18

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

18th October 2022, 21:09

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

benwaggoner

18th October 2022, 22:23

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

18th October 2022, 23:32

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

20th October 2022, 10:59

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

26th October 2022, 16:39

excellentswordfight

7th November 2022, 13:29

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

8th November 2022, 22:25

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

9th November 2022, 04:54

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

9th November 2022, 12:57

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

10th November 2022, 02:16

For consumer electronics backwards compatibility

No one is talking about consumer electronics.

rwill

10th November 2022, 06:07

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

11th November 2022, 03:21

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

11th November 2022, 19:57

.......
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

1st January 2023, 17:35

"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

11th January 2023, 18:18

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

26th January 2023, 16:30

Compatibility > efficiency

Every time.

Every. Goddamn. Time.

For consumer electronics backwards compatibility...

No one is talking about consumer electronics.

What am I missing?

rwill

26th January 2023, 22:42

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

27th January 2023, 19:49

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

10th February 2023, 22:28

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

11th February 2023, 11:28

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

kurkosdr

13th February 2023, 13:22

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

13th February 2023, 22:22

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

14th February 2023, 20:04

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

14th February 2023, 22:36

"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

16th February 2023, 12:12

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

16th February 2023, 17:28

"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

16th February 2023, 17:42

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

16th February 2023, 20:00

"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

16th February 2023, 20:58

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

16th February 2023, 21:46

" 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

16th February 2023, 21:55

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

16th February 2023, 22:36

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

16th February 2023, 22:47

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

16th February 2023, 23:15

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

16th February 2023, 23:18

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

16th February 2023, 23:39

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

17th February 2023, 13:37

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

17th February 2023, 16:06

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

8th March 2023, 10:05

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

8th March 2023, 10:35

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

8th March 2023, 13:08

probably a tv vs pc scale or color matrix issue.

102030

8th March 2023, 13:34

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

8th March 2023, 16:41

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

9th March 2023, 09:56

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

14th March 2023, 15:11

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

16th March 2023, 05:28

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.

benwaggoner

16th March 2023, 05:38

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.
You can always lower or turn off the in-loop deblocking filter in H.264; Gary Sullivan once told me that his biggest regret in H.264 was that the default loop filter strength was a little too high; -1,-1 is a better default. Even without it, High Profile will still outperform Xvid a lot due to better entropy coding, better adaptive quant signaling, multiple reference frames, hierarchical b-frames, and so on.

H.264 is definitely the first "after" codec in the before/after of codec evolution, with MPEG-4 pt 2 and VC-1 the last gasp of the classic 8x8 intra block IPB single forward reference no in-loop deblocking non-arithmetic entropy coding era. It was a huge break from from everything before, and HEVC and VVC are refinements and extensions of the H.264 model, based on fundamentally the same core.

Plus x264 is simply a much more psychovisually refined encoder than xvid, and it was more broadly used, both by hobbyists and for commercial use by companies who paid for improvements in it.

DTL

16th March 2023, 10:44

"I could make HDR MPEG-2 "

HDR depend on camera (and display device) and not on MPEG codec in the chain. Transfer function for compression of dynamic range may be quantized to either 8 or 10 or more bits with simply different level of quantization noise. But if camera not provide required physical dynamic range - no real HDR after camera. From good broadcast-graded cameras with 600%+ range we really watch HDR for decades but it only was not standartized like HLG transfer. So yes - MPEG-2 HDR already worked many years. And yes - with HLG metadata marking it is possible to run 8bit HLG HDR in MPEG-2. It only one of infinity modes of HDR in 8bit MPEG-2. Display device have a right to expand transfer curve of near white and overwhites as it like (and as user like).

Any SDR-decoder display device like 8bit MPEG1 if feed by professionally designed 8bit content may have simple AI-driven or even simple LUT-based user control option like
Simulate HDR-expand mode 1
Simulate HDR-expand mode 2
...
Simulate HDR-expand mode N
Simulate HDR-expand mode HLG-8bit

Because good designed 8bit SDR content already have some HDR compressed range in near whites and superwhites. It is legal from begining of Rec.601 in 1982. Close to half a century now in 2023.

"and display supports 10-bit HEVC decode. "

My poor people's 4K display form China-Philips too frequently refuses to decode 10bit HEVC (though it is possible to create playable file with x265 and mp4box for it). So I do not like to download HEVC 10bit release from torrents and pay per GBs and finally found it is not playable at display. Typically all xvid and AVC releases run OK.

" I can't imagine why anyone would practically benefit from using a sub-HEVC codec for HDR."

8bit is endusers standard for display and decoder devices for about 1/3 of a century now. So I expect 'in a good still not perfect world' we can have slow motion from 8bit to 10bit at endusers homes (and may be from MPEG-4ASP/AVC to HEVC) at about 1/2 of a century. And for this good intermediate period of a 1/2..1 of a century users may use good old 8bit workflow with simple some additional metadata enhancement for highlights expanding (transfer) curve.

"H.264 is definitely the first "after" codec in the before/after of codec evolution, with MPEG-4 pt 2 and VC-1 the last gasp of the classic 8x8 intra block IPB single forward reference no in-loop deblocking non-arithmetic entropy coding era. It was a huge break from from everything before, and HEVC and VVC are refinements and extensions of the H.264 model, based on fundamentally the same core."

So h.264 may be selected as last great product of current civilization for video compression and we can use it to the end. The end of civilization may be much quicker even 1/2 of a century. So few reasons to switch versions of 264+(++, +++,...) every several years for a very few of enhancement and very large performance penalty and new hardware to purchase.

Addition: Also it is remarkable how quickly died hype around WCG. It is typically missed that 10bit enduser systems are not only about HDR but also with WCG. So +2bits to standard 8 really divided between new WCG feature and HDR feature. If we finally skip the not very useful WCG feature we may found the 8+1=9 bits may also cover HDR not very bad.

WCG looks like died not only because it is hard to find natural scene with any benefit from WCG, but also the scene setup group (colour artist, lighting/shading artist, cameraman) must be able to create visually pleasing scene with WCG. It may be even more harder to find.

benwaggoner

16th March 2023, 17:48

"I could make HDR MPEG-2 "

HDR depend on camera (and display device) and not on MPEG codec in the chain. Transfer function for compression of dynamic range may be quantized to either 8 or 10 or more bits with simply different level of quantization noise. But if camera not provide required physical dynamic range - no real HDR after camera. From good broadcast-graded cameras with 600%+ range we really watch HDR for decades but it only was not standartized like HLG transfer. So yes - MPEG-2 HDR already worked many years. And yes - with HLG metadata marking it is possible to run 8bit HLG HDR in MPEG-2. It only one of infinity modes of HDR in 8bit MPEG-2. Display device have a right to expand transfer curve of near white and overwhites as it like (and as user like).
I don't think anyone has ever done MPEG-2 HDR. I can squint and imagine how I could kind of get it to work, but it'd still be a regression in quality, bitrate (like 4x!), and compatibility. I was also presuming 10-bit MPEG-2 encoding to PQ.

Any SDR-decoder display device like 8bit MPEG1 if feed by professionally designed 8bit content may have simple AI-driven or even simple LUT-based user control option like
Simulate HDR-expand mode 1
Simulate HDR-expand mode 2
...
Simulate HDR-expand mode N
Simulate HDR-expand mode HLG-8bit
What device supports user or metadata defined LUTs but not HEVC? Let alone real-time AI like that?

My poor people's 4K display from China-Philips too frequently refuses to decode 10bit HEVC (though it is possible to create playable file with x265 and mp4box for it). So I do not like to download HEVC 10bit release from torrents and pay per GBs and finally found it is not playable at display. Typically all xvid and AVC releases run OK.
Does 8-bit HEVC work? If it is a Smart TV, can it play back HDR from streaming services?

8bit is endusers standard for display and decoder devices for about 1/3 of a century now.[/QUOTE]
Display and video depth are quite different things; RGB 8-bit full range can have more visual information than a limited range 4:2:0. And a panel's "native" EOTF is far from the CRT-emulating Rec709 gamma. Lots of good HDR has been viewed on 8+2 panels.

So I expect 'in a good still not perfect world' we can have slow motion from 8bit to 10bit at endusers homes (and may be from MPEG-4ASP/AVC to HEVC) at about 1/2 of a century. And for this good intermediate period of a 1/2..1 of a century users may use good old 8bit workflow with simple some additional metadata enhancement for highlights expanding (transfer) curve.
Premium content is already exclusively 10-bit for HDR, and lots is 10-bit for SDR as well. We'll see >50% of global eyeball hours be in 10-bit within a few years.

So h.264 may be selected as last great product of current civilization for video compression and we can use it to the end. The end of civilization may be much quicker even 1/2 of a century. So few reasons to switch versions of 264+(++, +++,...) every several years for a very few of enhancement and very large performance penalty and new hardware to purchase.
I think MPEG has done well in keeping decoder performance increases per generation quite proportionate to compression efficiency gain. A HEVC decoder block costs WAY less than a MPEG-2 decoder back when DVD launched.

That said, I have no reason to think the H.264++ era will last tremendously longer than the H.261++ era it replaced. Peering into the future, I can see half-float linear light frequency-domain prediction codecs that use ACES mezzanines next decade.

Addition: Also it is remarkable how quickly died hype around WCG. It is typically missed that 10bit enduser systems are not only about HDR but also with WCG. So +2bits to standard 8 really divided between new WCG feature and HDR feature. If we finally skip the not very useful WCG feature we may found the 8+1=9 bits may also cover HDR not very bad.

WCG looks like died not only because it is hard to find natural scene with any benefit from WCG, but also the scene setup group (colour artist, lighting/shading artist, cameraman) must be able to create visually pleasing scene with WCG. It may be even more harder to find.
WGC is alive and well. It's just that WGC and PQ are almost always implemented together, which is HDR-10 and Dolby Vision as used in HDR streaming and UHD Blu-ray. It turned out that adding HDR on top of WGC was pretty small incremental complexity, so there were very few WGC-only displays ever shipped.

FranceBB

16th March 2023, 21:33

"I could make HDR MPEG-2 "

In theory, yes, but it would be tonemapped BT709 SDR content from a real logarithmic source (or even something like BT709 800% etc).

In terms of "real" HDR, well... as long as you can "live" with 8bit banding, specifying BT2020nc and arib-std-b67 (i.e HLG) while encoding an HLG content did indeed work... beyond any of my expectations as I really thought it was gonna fail...

I don't think anyone has ever done MPEG-2 HDR.

Yet...
Look what you made me do, the atrocity... the blasphemy... an MPEG-2 XDCAM-50 in BT2020 HDR HLG :eek:

General
Complete name : /home/FranceBB/Share Windows Linux/temp/test.mxf
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 62.0 MiB
Duration : 10 s 80 ms
Overall bit rate : 51.6 Mb/s

Video
ID : 2
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 10 s 80 ms
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
GOP, Open/Closed : Closed
Stream size : 60.1 MiB (97%)
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Delay_SDTI : 36000000

Audio #1
ID : 3-1
Format : Dolby E
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Muxing mode : SMPTE ST 337
Codec ID : 0D01030102060300
Duration : 10 s 80 ms
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Delay relative to video : -9 h 59 min
Stream size : 1.55 MiB (3%)
Title : ITADE-fatto_Prog0
Delay_SDTI : 36000000
Locked : Yes

Audio #2
ID : 3-2
Format : Dolby E
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Muxing mode : SMPTE ST 337
Codec ID : 0D01030102060300
Duration : 10 s 80 ms
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Delay relative to video : -9 h 59 min
Stream size : 621 KiB (1%)
Title : ITADE-fatto_Prog1
Locked : Yes

Other #1
ID : 1-Material
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:00:10:01
Time code settings : Material Package
Time code, stripped : Yes

Other #2
ID : 1-Source
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code of last frame : 10:00:10:01
Time code settings : Source Package
Time code, stripped : Yes

Other #3
Type : Time code
Format : SMPTE TC
Muxing mode : SDTI
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00

Well... it worked...
MPV is also reading it correctly...

https://i.imgur.com/p26Dz63.jpg

Also the end result isn't that terrible, but that's only 'cause it's HLG, if I used a PQ source and encoded as PQ it would have been waaaaaay worse and full of banding as PQ is a truly logarithmic curve and it would be pretty hard to keep. Besides, the lack of logarithmic curves aware compression tools in x262 would make it destroy what's left of the image. I know 'cause a while back I've seen some pretty bad results with Slog3 and Clog3 footages (which are truly logarithmic curves) where blacks were starting very high and the MPEG-2 compression totally destroyed them and of course skies were full of banding as well.

Speaking of which, for anyone reading, PLEASE DO NOT make this a standard. Just because you CAN do it, doesn't mean you SHOULD do it. We should be moving forward not backwards.
H.264 being used for UHD HDR in common broadcast mezzanine formats like Sony's XAVC and Panasonic's AVC Ultra is already half-a-blasphemy as it blocked the adoption of H.265 as a mezzanine format and encoders like x265 which actually have HDR-aware coding tools (so much so that generally it's H.264 at high bitrate re-encoded to consumer-tier bitrate H.265 only for distribution), but at the very least they are 10bit and 50p, so please people, don't make MPEG-2 25i HDR a thing or I might very well suicide.
Honestly, if any improvement was to be done in x262 and in libavcodec's MPEG-2 encoder, it should NOT be about HDR-aware coding, but rather really making the existing coding tools multithread and use proper intrinsics that are not stuck in the past.

WGC is alive and well. It's just that WGC and PQ are almost always implemented together, which is HDR-10 and Dolby Vision as used in HDR streaming and UHD Blu-ray.

Absolutely correct. And it's not just PQ, it's also HLG.
Let's not forget that from 2015 to 2017 the broadcasting companies who actually made the switch to UHD were airing in BT2020 SDR, but then, when HDR arrived, switched to HLG thus keeping the benefit of WCG in place thanks to the BT2020 AND summing them to a hybrid transfer function which allowed much more headroom for highlights.

DTL

17th March 2023, 10:50

specifying BT2020nc
Color primaries : BT.2020
Matrix coefficients : BT.2020 non-constant

I see the WCG hype is dead but WCG still continue to decrease quality at user side at some (many) use cases. Users got one more way to make good visual content to look worse.

Unless your (typically unnatural synthetic) content is absolutely require WCG and only benefit from being produced from (typically unnatural) WCG scene it is really require to use BT.2020 colour gamut at 8bit system. It is only about lossless if you use float samples system with about unlimited precision and very low quantization noise.

In all other standard use cases typical natural scenes do not have out-of-standard (narrow/small) gamut colours so attempt to compress natural gamut into BT.2020 colour gamut in low-bits integer samples system only cause significant increase of quantization noise and loss of fine natural colours difference reproduction.

So correct 8bit HDR-legalized system must use standard (professional of 20 century, narrow/small) colour gamut of rec.709. So if your mezzanine source is bt.2020 colour gamut encoded - you need to extract natural (small) colour gamut from input bt.2020 content and encode it into bt.709 our lovely 8bit system.

So in AVS z_ConvertFormat it is something like:
=>709:std_b67:709:l

and simply put
ConvertBits(8) or better ConvertBits(8, dither=1) to better benefit with MPEG-friendly dithering.

And mark this any MPEG encoded 8bit content as having HLG HDR transfer. This will be our awaited 8bit MPEG HDR system with now legal and standartized to displaying HDR transfer. It also can be MPEG-1 encoded and put to VideoCD and make handwritten note on the CD surface about HLG transfer used. So user will not forgot to click HLG transfer decoder at the playback.

DTL

17th March 2023, 12:53

I don't think anyone has ever done MPEG-2 HDR. I can squint and imagine how I could kind of get it to work, but it'd still be a regression in quality, bitrate (like 4x!),

Because our lovely professional quality visual systems are 8bit so we can make MPEG 8bit HDR and it will be about equal in bitrate to 'classic' 8bit release titles.

Really most of digital video titles released in about 1/3 of a century now do have HDR inside but in non-standartized transfer as was already noted.
Even classic bt.601/709 'SDR' broadcast-graded video camera is only 'SDR-on-output' or targeted to SDR transfer decoder in display as 'reference'. But its linear scene light can not be completely restored using inverse-OETF of SDR in single way because old SDR standards do not cover possible HDR to SDR compression of highlights before applying SDR OETF. So all old good MPEG2 8bit broadcasts already had HDR inside but in non-standartized form. No additional bits of MPEG required. The HLG only put normative on one possible transfer curve of HDR to system bits range compression.

"What device supports user or metadata defined LUTs but not HEVC? Let alone real-time AI like that?"

Possibly many high-graded digital-image-processing enduser TV-sets from before-HEVC years with 'digital image (improving) processing'. The analog TV-sets unlikely have such advanced processing. The manufacturers of TV-sets already know about functions of broadcast SDR video cameras and film-based content production and can offer some HDR-expanding to user with addition to product price.

"Does 8-bit HEVC work? If it is a Smart TV, can it play back HDR from streaming services?"

Yes - some 8bit HEVC files also work. And yes - it is Android-based 'smart TV' and possibly can use network streaming services but I never tried it. I live in my own self-build home far away from large city and it is too expensive to make wired or optical broadband internet connection here to watch network broadcasts. The affordable 3G and 4G wireless network providers already cut-away unlimited traffic options here. And internet start to work worse and worse last days. The digital civilization quickly dying here. Also I many years only watch downloaded content when I have time.
The device specifications lists for formats and codecs:
https://www.download.p4c.philips.com/files/4/40put6400_12/40put6400_12_dfu_eng.pdf
Multimedia
Connections
• USB 2.0
Playback formats
• Containers : 3GP, AVCHD, AVI, MPEG-PS, MPEG-TS,
MPEG-4, Matroska (MKV), Quicktime (MOV, M4V,
M4A), Windows Media (ASF/WMV/WMA)
• Video Codecs : MPEG-1, MPEG-2, MPEG-4 Part 2,
MPEG-4 Part 10 AVC (H264), H.265 (HEVC), VC-1,
WMV9
– MPEG-4 AVC (H.264) is supported up to High
Profile @ L5.1.
– H.265 (HEVC) is supported upto Main / Main 10
Profile up to Level 5.1

It is 4K endusers TV-set of rec.709 colour gamut and rec.709 transfer only. Practically nice enough to watch FullHD with 2x upscaling to not see aliasing from display pixels grid.

"RGB 8-bit full range can have more visual information than a limited range 4:2:0."

8bit full is not really nice for high-end sinc-based workflows because it also cut undershoots below system black level. Yes - using over-whites for HDR compression is not 100% perfect idea but real superwhites are less common in compare with low levels near black.

"Premium content is already exclusively 10-bit for HDR,"

Industry manufacturers while adding easy to show at showrooms performance booths to old video systems (4K/8K/WCG/HDR/HFR) still not fix real old design bugs:
1. The 'better' quality over-SD systems still badly bugged with ugly old poor-past 4:2:0 2:1 compression with irreversible distortions at enduser display.
2. The 'better' quality digital visual systems still not have a standard on spatial image decoding from sampled form at all.
3. Also transfer-function compression also adds distortions (may be via quantizing noise too) to possible 'linear' sinc-based workflows at least in 1D+1D form (if we expect 2. to be solved as sinc-based upscaler).

So when I see 'premium' digital video content I think it must be internally based on linear float (lets half precision 16bit) RGB. Not on ugly old 4:2:0 many-distortive compressions (additionally extra bugged with extra-non-linear HDR range compression transfer). Even if it is wrapped in some modern-named MPEG and have +2 bits to old 8.

So in 21century the visual industry instead of saying:
"Hey - look - we finally solve all old bugs of old digital video systems and offer to buy a really high-quality system as clear as PCM audio". They start to build new booths (HD/4K/8K/WCG/HDR/HFR) over the old internally ugly and buggy and uncompletely documented basis from poor-past. That is fun to see as nowdays no one at this planet knows how to properly decode moving digital pictures content so still no 'reference' digital moving pictures display exist. So users still messed with tons of different ways of upscaling - see madvr renderer of todays for example. So I see no 'premium' digital moving pictures content still exist even if something is 10bit and HEVC.

I can expect nowdays 'real premium' digital video system is digital cinema released as a sequence of files-frames of 4:4:4 and in better case linear float32 RGB form. But not something for TV-broadcast or IP-streaming in some poor 4:2:0 MPEG form.

FranceBB

17th March 2023, 17:47

So when I see 'premium' digital video content I think it must be internally based on linear float (lets half precision 16bit) RGB. Not on ugly old 4:2:0 many-distortive compressions (additionally extra bugged with extra-non-linear HDR range compression transfer). Even if it is wrapped in some modern-named MPEG and have +2 bits to old 8.

Eh, I think the 4:4:4 time will eventually come one day.
I mean, sure, we're still using 4:2:0 and sure enough when you watch a "modern" UHD content it will still be 4:2:0 with the chroma upscaled from 1920x1080 to 3840x2160 to match the luma, but think about it this way (and I'm talking about linear broadcasting around the world):

- at least we're no longer using 8bit and we moved to 10bit
- at least we're no longer using 25i and 29,970i but rather 50p and 60p

going forward, there will be 8K and H.266 VVC with the same specs, so still 10bit and 50p / 60p as standard (although some people were calling for the standard to be bumped to 12bit).

Sure, considering that we're still using 4:2:0 chroma subsampling is a bit of a pain, but in the long distant future I don't really see the world (content producers & broadcasters included) going any further than 16K.
By then, we will probably have 12bit as a standard at 50p/60p.

At that point, raising resolution further wouldn't make much sense for a consumer TV watched from the couch inside an apartment, so they will probably bump the standard to 100p/120p ('cause there are some contents that would benefit from it like sports). At that point, it would be hard to find benefits on raising from 12bit to something more like 14bit or 16bit (forget 32bit float), so probably we'll move to either 4:2:2 or 4:4:4.

So, my forecast for the distant future is:

16K 100p 4:4:4 HDR PQ BT2020 12bit H.268 for PAL
16K 120p 4:4:4 HDR PQ BT2020 12bit H.268 for NTSC

(Yes, H.268 and not H.267 probably 'cause H.266 VVC will be used for 8K, while 267 will be used for the first implementation of 16K which will probably still be 50p/60p, while 268 will probably be used for the second high frame rate 4:4:4 implementation of 16K).

Of course there's absolutely nothing official and those are just wild guesses / speculations from my side.

I could be terribly wrong and I have been in the past, so who knows... I guess we'll have to wait and see what the future holds for us. :)

DTL

17th March 2023, 19:04

"going forward, there will be 8K"

It is fun to see how people going to go to completely invisible in typical household viewing conditions 4K and 8K and even 16K with 4x, 16x and 64x more initial datarate (from the 'base' FullHD) but still can not fix old design error with simple 2x datarate from ugly 4:2:0 to good 4:4:4. And if really going to live in nice future with legal standard HDR finally going from 10bit transfer-distorted domain HDR into HDR-enough system 16bit half-float linear domain with only 16/10=1.6x datarate increasing.

So all that required for nice bug-less and finally high-end really visible FullHD is 2x increase from 420 to 444 and 1.6x increase from going into transfer-distorted to linear domain. It is 2*1.6=3.2x only increase in datarate. It is lower than motion from FullHD to invisible 4K. But it is not provided to endusers.

It looks like severily degraded civilization.

The really reasonable good visual system of 'high-end' class to may be the soon enough end of this current civilization is:
- 1920x1080,
- 50p, * <--- we are here *
- linear RGB in 16bit half-precision floats (yes it can cover both BT.2020 colour space and some HDR, for 'full' HDR - 32bit standard precision floats highly recommended),
- finally defined in all-planet-regions (ITU) standard reference image restoration algorithm from sampled form to allow to create reference master grading monitors to production studios and displays for endusers,
- some not very complex MPEG codec to use with average title (or 1 hour runtime) channel datarate of about 10 (5..20) Mbit/s.

And yes - to create hi-end graded 1920x1080 sample array for distribution (aliasing free (max allowed residual aliasing for test conditions X is below Y% of full datarange), noise free (max noise level below ___ % of full datarange), >8bit non-distorted quality of residual distoritions) the 4K, 8K or even 16K shooting equipment is highly recommended. So it not mean only live with 'poor' FullHD cameras.

FranceBB

17th March 2023, 21:02

I'll tell you a secret (well, I guess it won't be a secret any longer xD).
My parents bought a Samsung LED TV in 2009, FULL HD, BT709.
My father is retired and still lives in his home town in Leghorn, Italy, several miles away from where I live, while my mum is from Florence, Italy, but she has been living with my dad in Leghorn ever since they met.
Being from an "old generation", they don't really want to / feel the need to throw away perfectly working hardware.
I'm a Sky employee, so I have the right to free subscription and boxes, but I didn't want them to experience FULL HD 25i yv12 given that we've been consistently airing in UHD for a while now.
What I've done, then, is give my parents a Sky Q box hooked up to the satellite grabbing the UHD 50p 4:2:0 10bit BT2020 HLG signal (which the box converts to BT709 8bit from the settings I picked).
Then, it goes through an hardware downscaler I bought that downscales the luma from 3840x2160 to 1920x1080 while leaving the chroma as it is at 1920x1080, thus creating a fabulous FULL HD 50p 4:4:4 BT709 8bit signal carried through HDMI which goes straight into the 2009 Samsung LED TV.
Needless to say, it brought the TV back to life.

DTL

17th March 2023, 21:09

"Samsung LED TV in 2009, FULL HD, BT709."

To better (more correctly, with less aliasing) display FullHD content we need at least 4K screen or better 8K to have 2x or 4x (typically SincResize, still not put to ITU standard) upscale. Because we typically no more have analog displays even with horizontal analog lines scanning. So it is sorry for old FullHD screens.

The end-users laser projector TVs (really covering full BT.2020 saturated colours) with possibility of analog output after good DAC at least horizontally are not go mainstream and died in North America. Even not reach 4K output.

So the MPEG compressor for 4K and more pixels screen may be simple xvid with 1920x1080 system frame.

FranceBB

17th March 2023, 21:11

Trust me, if I could buy an hardware downscaler which uses SinPowResizeMT() I would, but I can't xD

DTL

17th March 2023, 22:08

" if I could buy an hardware downscaler which uses SinPowResizeMT() I would, but I can't"

It only part of a solution but not full solution. And also the UserDefined2 kernel expected to be better. If you need to realtime live AVS processing I think it is possible with simple windows-box running some not very old windows with directshow and SDI in/out board (for single home use the HDMI may be used) capable of directshow interfaces (good board running in and out at once - some may only in or out).

And after windows load install ffdshow and AVS - open graphedit and construct graph of hardware input source - ffdshow in RAW processing mode and hardware out - put avisynth script in ffdshow and click run graph. I thinking of making some like this for our broadcast company to run mvtools degrain before main broadcast MPEG encoder so help MPEG coder with lower noised content. But current dying civilization do not have interest in quality broadcast and we have no one complain on quality.

So if the in/out SDI (or IP-in/out for IP-based network) board and its driver would be nice (may be AJA and not cheap Blackmagic ?) and not hang or crash after several hours/days of runtime you can make some part of this planet more happy with both mvtools denoise and/or UserDefined2 (or SinPow) downscale of 16K/8K/4K source to better FullHD in live broadcast. Though I think some hardware vendors already uses the kernel like in SinPow or UserDefined2 resize - I see some like this adjustment in some good video camera setup instruction and it was called 'peaking adjustment'.

My tests with AVS and very old Decklink cards with SD-SDI input and ffdshow (for input only and running sort of dual input colour analyser for many cameras colour tone grading/alignment) result in lowering framerate update after about 2..3 hours of runtime. So it is not applicable for airing to the part of the planet for many days without restart. May be better cards or better directshow version or patched ffdshow required.

FranceBB

18th March 2023, 12:17

I'm totally with you on this.
Although it could be done for home use, when they asked me to experiment with it at work in summer last year I said: absolutely no!
The reason is exactly what you highlighted above, I said "there's no way I'll ever certify something like this" mostly 'cause I'm pretty damn sure that even if I used real-time filters in Avisynth getting the incoming stream from the sat decoders from our MCR via SDI:

1) It could crash at any moment
2) There's no way it would be able to sustain days of workload without rebooting etc

And of course one could make all the arguments of the case like putting a DFS in front of it and using AJA cards instead of Blackmagic decklinks for input/output, but the benefit vs risk still wouldn't cut it.
I mean, I would rather have no filtering and a crappy hardware downscale with gibbs ringing and what not than to have perfect quality until Avisynth crashes in the middle of a game and it takes forever to bring the frameserver back up, people at home complain (and I'm blamed for it).

By the way, it's funny how we tested the same things 'cause I made the same tests myself and with the very same technology :) (and with pretty much the same results... :( )

DTL

18th March 2023, 12:51

"16K 100p 4:4:4 HDR PQ BT2020 12bit H.268 for PAL"

Some more longread about >FullHD frame sizes:

Yes - 4K is not totally invisible. 4K and more samples per frame may be used for higer-quality digital visual systems but in the following way:

1. Digital imaging systems have very important internal design param of samples per degree of view. The 'classic industry' SD/FHD/4K/8K/(16K) form family of system-60spd. They designed to the close to critical spatial samples density around 60 samples per degree. Below 60spd the visual resolution quickly degrade, above 60spd visual resolution very slowly increases. Only 8K start to move some higher to about system-80 or more.
With FHD at system-60 we already reach limit of 'normal' angle of view of about 30 degree horizontal. It is even a bit more to normal (about 16 degrees) so left some side space.
Higher family members of system-60 like 4K/8K/16K are completely unusable for general broadcasting and require special wide-angle production (and displaying).

But system-60 also require very high quality engineering of samples usage in both compression (creating low sample count buffer) and decompression (restoring image from sampled form) stages. As today it looks we still not have perfect 2D linear upsampler mathematics (the 1D+1D sinc is not perfect for 2D and some 2D-oriented resizers like Jinc/EWA-Lz and others are really not perfect also - the elementary dot is not perfectly round at all sizes). So nothing really mathematically perfect once for ages to suggest to ITU to be accepted as industry standard upsampler for moving pictures digital imaging at this planet. May be even rectangular sampling grid is not completely perfect for 2D imaging and need replacement to other type of 2D sampling grid.

But requirements for upsampler significantly relaxed if we not try to reach peak possible sharpness of digital imaging (limited by Nyquist and Gibbs) and use some more samples to describe same detailed image. And to restore display visual sharpness we simply increase design samples density per degree of view above 60. Lets to 120.

So frame sizes above FHD may be used for different systems:
1. 4K system-60 - wide angle, standard per degree quality system.
2. 4K system-120 - normal angle of view, increased quality per degree of view system.
Same with 8K and more - like 8K may be 'normal viewing angle' or 'full viewing angle' (as from initial FHD) system-240 with close to no special requirements for upsampler (simple bilinear can be used or direct samples to screen pixels mapping).

It also connected with settings of UserDefined2Resize with adjustable s-param: For system-60 targets it is benefitically to keep some non-linearity and use low s-value around 2 to make 'halo/over/under shoots' thinner but it still leave some residual non-linear distortions. But allow to use higher-compressed low initial sample count 1920x1080 frame and more simple MPEG codec for same average bitrate and filesize.

For higher-quality system-120 and more it may be recommended to use 'unlimited' kernel size (s > 3..5 and more) and output 'full' width 'halo/over/under shoots' and got less residual ringing and other possible distortions. The visual sharpness of 'oversampled' system-120 and more is enough high so no thicker over/under shoots will degrade it.

But the not very nice side of 4K and more systems is much higher requirement for MPEG codec like 4x and 16..64 more initial datarate to compress. So the usage of 4K system-120 may be as 'bruteforce' solution of better quality for poorly engineered 'initial sampling compression' frame.

It looks close to audio systems from 44.1 kHz for very perfectly and precisely engineered old systems for all parts - from ADC with very nice LPF, very complex processing and high oversampling DAC with good knowledge in sinc() and modern 192 kHz system running well on very simple LPF and poor DAC still very fine. Just because 192 kHz workflow is very cheap now.

So for good old MPEG codecs the good engineered digital visual workflows with low frame sizes may be used for 'classic' system-60. It require additional efforts in design good sample-compressor to low samples frame size and complementary decompressor for displaying (upscaler). The higher samples per frame count systems like system-120 and system-240 may use very simple bilinear resize or direct samples to pixel mapping with also good image but require much larger frame size to operate.

"There's no way it would be able to sustain days of workload without rebooting etc"

It is not really badly nature of Windows and DirectShow - I have experience on broadcast running some handmade DirectShow file player with controlled image overlay via sample-designed DS filter in between file decoder and renderer running for weeks/months or may be years without reboot. And got no complaints on its stability over many years running until it was replaced by other more featured solution. So the DirectShow core in Win7 is not very bad even for broadcast-graded stability. But other parts like ffdshow or AVS are subject to test. Though to run AVS as DirectShow intermeduate RAW processing component may be much easier in compare with ffdshow design but require once again some new DS filter design (or extract from ffdshow).

orion44

8th April 2023, 06:50

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.

Me too.

I never liked the look that x264 produced, no matter which settings I tried,
I just couldn't watch it. Especially when it was used to encode DVDs.

DTL

10th April 2023, 09:50

" if I could buy an hardware downscaler which uses SinPowResizeMT() I would, but I can't"

You can e-mail to any local or global planet hardware manufacturer about same looking kernel. It may be several minutes of engineer work to patch FPGA chip firmware and you will got either downloadable firmware upgrade for module or mail of new unit or installable board of scaler in the chassis. The math of the kernel in the AVS and JPSDR github opensource. I can ask local SDI hardware manufacturers but they may be not widely available at European market. For IP-based solutions it mostly simple patch of firmware.

Some more sad note about HDR from natural scenes: The HDR-capability or typical shot optics is limited to about 8 F-stops for 'high-key' scenes. Because of light scattering in glass itself and flare/glare on surfaces (surface finish/coatings/residual dust). And only for low-key scenes may be significantly larger. The 'standard' scenes is something inbetween. Unfortunately after the hype around HDR was started - close to no lens manufacturers announce any better HDR-lens series. So for general multi-lens zooms the HDR is the worst quality and for some low-lens cine primes (specially produced in clean low-dust environment, special coatings, special low-internal light scattering glass types, may be even reflective no-glass or hybrid mirror+glass optics) the high-key HDR may reach 10..12+ F-stops. Mirror-only optics typically is sort of fixed-focal prime of very large size. But extreme HDR optics expected to be glass-less (mirrors-based). Though it is really still in 8bit SDR range. So really the all possible in real hardware HDR is limited to some limited highlights non-clipping. Not about really nice colour expanding in shadows at high-DR scenes.

blob2500

8th April 2024, 11:42

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.

Very true.
I often convert my HDTV capture in Xvid HD 720, too.
In addition to the content, in my country (Italy) many TV channels of DTT or TvSat, use just enough HD1080i/H.264 (too many compression artefacts and/or badly set encoder), and I found that it is sufficient to use Xvid: the benefit in coding speed is greater than the higher quality of x264. I know I could use x264 "reduced" to Xvid features, but Virtualdub(editing) -> Xvid vfw is much more practical for me, and I have had experience using the codec for almost 20 years.
I convert HD1080i capture-tv to 1280x720p(in fact, 512...544... depending on cropping) with Xvid HD 720p profile ("DivX HD 720p" compatible), 1 pass, constant Quantizer or CBR (but playing with qmin, qmax, trying to do something similar to the CRF of x264) and B quantizer-ratio/offset. With a small compression test I can fairly predict the final file size in a single pass; a test I still do even when using x264(CRF mode)... but with Xvid the encoding of the final file takes half the time, and it's good for my PC which isn't very efficient. ;)