AviSynth+ thread Vol.2

[Balling]

Well, no, top-left is found in DV. See wikipedia. As for 4:2:2 is not there only 1 possible placement?

[Reel.Deel]

Originally Posted by FranceBB

and it makes sense, it shouldn't exist for 4:2:2, like, I've never ever seen it.
I mean, let's think this through logically.

I was under the impression that 4:2:2 has always had a "left" (type 0) chroma location. My understanding is that the "left" chroma location was introduced in MPEG2, before then it was only centered since that was the spec on MPEG1. I've had some digital cameras that output 4:2:2 JPEGs and on all of them the "YCbCrPositioning property" is set to co-sited, aka left. Also, it would not make much sense for 4:2:2 to be top left since the chroma has full vertical resolution. If that were to be the case it would mean shifting the chroma half a pixel down when converting to RGB, for no good reason. I have not tested but would be curious if x265 even allows the chroma location to be set to top left for 4:2:2 sources. I've never seen any illustration/articles that show/mention a different chroma placement for 4:2:2.

Some things I've found:

MPEG-2 FAQ

How are the subsampled chroma samples cited ?
A. It is moderately important to properly co-site chroma samples, otherwise a sort of chroma shifting effect (exhibited as a "halo") may result when the reconstructed video is displayed. In MPEG-1 video, the chroma samples are exactly centered between the 4 luminance samples (Fig 1.) To maintain compatibility with the CCIR 601 horizontal chroma locations and simplify implementation (eliminate need for phase shift), MPEG-2 chroma samples are arranged as per Fig.2.

[Mjpeg-users] chroma sample alignment

As you say in your web page, 4:2:2 always has co-sited chroma samples...

Originally Posted by FranceBB

Ok, guys, for the glory and my mental health, what's the REAL chroma location of this file: https://we.tl/t-MhjJWTj0lQ

and is the metadata just wrong or is it FFMpeg and the indexers that are not getting it right?

MediaInfo says it's Interlaced TFF .

Edit:

Originally Posted by Balling

Well, no, top-left is found in DV. See wikipedia. As for 4:2:2 is not there only 1 possible placement?

It's a different top-left. Read the following posts: https://forum.doom9.org/showthread.p...60#post1953360

[FranceBB]

Originally Posted by Reel.Deel

I was under the impression that 4:2:2 has always had a "left" (type 0) chroma location. My understanding is that the "left" chroma location was introduced in MPEG2, before then it was only centered since that was the spec on MPEG1.

I'm under this impression too, 4:2:2 has always had left, type 0, MPEG-2 chroma placement.

Originally Posted by Reel.Deel

it would not make much sense for 4:2:2 to be top left since the chroma has full vertical resolution.

Exactly!

Originally Posted by Reel.Deel

I've never seen any illustration/articles that show/mention a different chroma placement for 4:2:2.

Neither have I, in fact.

Originally Posted by Dogway

Yes, looks MPEG2 to me

Right! So an XDCAM-50 stream, namely an MPEG-2 stream at 50 Mbit/s 4:2:2 yv16 which is using the Type 0, left, MPEG2 chroma placement, as we all thought!
So FFProbe is getting it wrong, so are the indexers ffms2 and LSMASH.dll.

Also this


seems to confirm the fact that for 4:2:2 the chroma location is always Type 0, left, MPEG-2, especially for MPEG-2 streams like XDCAM-50, right?

So we all agree that FFProbe, LWLibavVideoSource and FFVideoSource all report the WRONG chroma location as it shouldn't be top left at all and that's a bug and needs to be fixed, right?
This is important 'cause I opened a bug here: https://trac.ffmpeg.org/ticket/9598#comment:5 and if it's fixed in FFProbe / FFMpeg, it will be consequently fixed in LSMASH and ffms2.

[VoodooFX]

How VS guys didn't noticed this bug?

No idea what Balling implies on https://trac.ffmpeg.org/ticket/9598#comment:4, in "Figure D.2" I see only one chroma placement, and it's not topleft.

[DTL]

4:2:2 simply rare for home users and possible difference between left and top-left signalling may be never cause any (visible) errors.

[StvG]

Originally Posted by VoodooFX

How VS guys didn't noticed this bug?

It could be because zimg does treat all three locations top_left, left, bottom_left for 4:2:2 the same way (left).

[FranceBB]

Originally Posted by VoodooFX

How VS guys didn't noticed this bug?

That's odd...
And not just the VapourSynth guys, but also the ffmpeg guys...

Originally Posted by VoodooFX

https://trac.ffmpeg.org/ticket/9598#comment:4, in "Figure D.2" I see only one chroma placement, and it's not topleft.

Precisely my point.

Originally Posted by DTL

4:2:2 simply rare for home users

Nah, just like Avisynth is used in professional settings (Crunchyroll, Viewster, Sky, RecordTV, NRK, CentrevilleTV, and plenty others across the world), I'm pretty sure VapourSynth is used somewhere too (although I can't name any 'cause I don't use it). Same goes for FFMpeg/FFProbe, which are both used in professional settings too by some companies. If we think about even just some of the user base here on Doom9, we have almost all the major streaming companies here eheheheheheheh (TL;DR Alex works at Hulu, Ben works at Amazon, Derek works at Disney, me and Livio work at Sky etc). Even you, DTL, I saw you discussing the resizing kernels topic, in particular SincPow2 and not only you had a deep insight about how thing worked and the math behind it and you could translate it into code that was able to run and be integrated into Jean Philippe's plugins, but you were testing the results and in particular aliasing on a professional waveform monitor by Tektronix, similar to the one I have sitting right next to me here at Sky, which is far too expensive for a home user, so... I'm pretty sure you work for some broadcasting company too ehehehehe
Now I'm curious, which one is it? :P

Originally Posted by StvG

It could be because zimg does treat all three locations top_left, left, bottom_left for 4:2:2 the same way (left).

This is much more likely.

[DTL]

" in professional settings too by some companies. "

It is a sad feature of the end of dying civilization - even in the 'pro companies' almost no one understand how the digital visual technologies working. Also the quality control if even exist in some very poor form mostly can not dig in such thing like 'chroma placement'. I see currently only a few fans in the nowdays dying internet network at this planet still trying to keep things in the old software for digital moving pictures processing in some logic and quality. The general idea of the companies: If it digital - it is just perfect and no more any pro-s required to support it. Company simply buy pro-cameras and pro-NLEs and it work without any service but cleaning cooling from dust for decades and changed to next generation of digital cams and NLEs and air servers/switches. Even the worker 'engineer' sitting near the still used 'multi-functional measuring equipment' (Tek/Leader/other) rasterizer mostly can only check max/white level at iris setup and mostly tune picture by image in simple control monitor by its taste - not by numbers at the analyzer. It looks the quality is not required nowdays and I do not see/hear any complain from end-users for poor quality of broadcasting (really sent to the broadcasting company - not just posed somewhere in the internet). So no complains and 'digital equipment' mean no more any engineers really required at production. So if even some broadcasting company will many years produce fulltime air with not left but top-left chroma it mostly no one will see. The actual datastream for nowdays endusers of air broadcasting is significantly degraded by the very low MPEG 4:2:0 bitrate so have many more severe distortions in addition with possible slight chroma-shift from left/top-left chroma treatment in XDCAM sources.
The main pro companies activity is about making money - not about making perfect digital moving images content.

"which one is it? "

Currently most of organizations require to sign some form of NDA with restriction to make public any data that may harm the company commertial activity. So if some possible harmful content is typed in some internet forum - it is no good to make additional signs where from it can be. Unfortunately the degradation in digital moving industry hits not only the small broadcasting companies.

Also the more 'perfect' you make the digital content production tools (even freeware ffmpeg) - the less engineers reqiuired and in a few years they physically disappear. Someday the broadcasting owners find that no one left to help with any new issue.

At old analog days with servicing broadcast equipment about dayly with real understanding engineers - this helps to production and support some broadcasting engineers pool with ability to understand how things working.

[FranceBB]

Originally Posted by DTL

"
It is a sad feature of the end of dying civilization - even in the 'pro companies' almost no one understand how the digital visual technologies working.

This is really sad, yet true...
I've witnessed this myself in some occasions...

Originally Posted by DTL

Also the quality control if even exist in some very poor form mostly can not dig in such thing like 'chroma placement'.

I guess...
Most of the things that are checked are luma and chroma levels, subtitles alignment for TTX muxed as OP47 in mxf and few other things over here too by some of my colleagues... Unfortunately, algia, (so Livio Aloja), the only other colleague who was lurking here on Doom9 retired and he's not working here any longer... I still miss him 'cause he was one of the few people who actually really cared...
There's still Fabio Sonnati here on Doom9 from Sky, but he works in the technology department (i.e they're the ones who get the already encoded and conformed, loudness corrected mezzanines I encode and re-encode them in H.264 or H.265 for the end users), so we don't really work together...

Originally Posted by DTL

Also the more 'perfect' you make the digital content production tools (even freeware ffmpeg) - the less engineers reqiuired and in a few years they physically disappear. Someday the broadcasting owners find that no one left to help with any new issue.

I've been talking about open source software with colleagues both here and from other TVs and we all seem to agree that the EBU should actually invest some of its budget in open source software, 'cause there are some features that otherwise will never be implemented. Take DolbyE indexing and decoding, it will never be properly addressed 'cause a tiny amount of user-base is interested in this. Of course, there are work-around and I've written lots of code to work around it and instruct FFMpeg into decoding it properly, but it needs Mediainfo (which is also at fault 'cause it reports like 2 tracks instead of 1 with 5.1+2.0) and some logic to instruct an ffmpeg decoder beforehand with what is going to receive, so there's nothing like an automatic detection and decoding, sadly.
If we had the EBU investing into things like indexers/decoders and also open source encoders, it would be a game changer.
Think about the XAVC intra class 300 and 480 inside x264. If it wasn't for ifb, Bug Master (Anton Mitrofanov), Jean Philippe and in a very little part me, it would have never been implemented, but it could have been implemented if the EBU funded it like it did for intra class 50, 100 and 200 (along with NRK). Speaking of which, if it wasn't for Steinar Apalnes, Kiearn Kunhya and NRK we wouldn't have had any implementation of the intra class at all in the first place. Another thing that is still not very reliable is the FFMpeg mxf muxer and I've been reporting issues which have later been fixed more than once. If it wasn't for the good heart of the BBC developers who made BMX Transwrap and raw2bmx open source and free, God knows what I would have done...
And yet, if the EBU funded it, we would have had a good compliant muxer in FFMpeg as well.

Originally Posted by DTL

At old analog days with servicing broadcast equipment about dayly with real understanding engineers - this helps to production and support some broadcasting engineers pool with ability to understand how things working.

Yeah... It seems weird, but I've seen plenty more screw-ups in digital contents than in analog ones...
It's almost a paradox, but it's just how things are...
I'm glad to have found Doom9 in 2006, I'm glad to have been lurking for years and I'm glad to have learned everything from the right place and the right people, 'cause university alone wouldn't have even remotely been enough.

[DTL]

"it could have been implemented if the EBU funded it."

You can try to join some 'video' groups of EBU (at least VS-all) or may be VS-EBU if your company is EBU member and post the ideas/questions/suggestions to mailing lists or individual projects in 'workspaces'. May it will helps somehow. Link is https://tech.ebu.ch/groups/video . Send e-mail request to Frans de Jong about joining available workgroups.

[FranceBB]

Ok, the FFMpeg guys replied and this is something interesting for us all:

If the chroma plane is both vertically and horizontally aligned with the Luma plane, which MPEG-2 4:2:2 is, then "topleft" actually seems like the correct value - because it indicates the position of the first chroma sample, as per the ffmpeg documentation of AVChromaLocation.
You could even argue that for 4:2:2 both "left" and "topleft" are supposed to be handled identically, due to the absence of vertical subsampling, so in practice it would make no difference. The only reason h264 would result in a different value is that the interpretation of different developers differed on what to call it, but neither mpeg2 or h264 even encode a chroma location value for 422, and always contain the same one.
The entire "type 0" and "type 2" thing only applies to 4:2:0, so its best to just not bring it into the discussion at all. 4:2:2 in reality only ever has one chroma position, and if you want to call that left or topleft, which for both would exist arguments, is rather irrelevant, because there should be no difference between them.
TL;DR
You might as well ignore chroma location for 4:2:2, since it never differs as per the specification of both mpeg2 and h264. Or at the very least instruct your code to handle left and topleft identically for 4:2:2, because they are. mpeg2, h264, and h265 for that matter, do not even encode the chroma location for 422 - therefor you cannot associate any "type X" with it, since no type number is even specified. Its just 422 chroma, no alternates are possible.

So, in a nutshell, 4:2:2 doesn't have a chroma location, it's literally always the same. x262, x264, x265 don't encode any value for the chroma location and what ffprobe does (as well as the indexers) is reporting left for H.264 encoded streams and top left for MPEG-2 encoded streams, but even though the name is different, they're actually exactly the same.

In other words, in "Avisynth terms", it's always "left", so I think we have two choices:


1) We change this behavior in indexers so that they're gonna report "unknown" (or "left" eventually) every time we get a 4:2:2 stream

2) We make the internal resizers handle 4:2:2 anyway assuming the old MPEG-2 chroma location every time, no matter what the indexer says instead of throwing an error


Ferenc, you're the boss here, the decision is yours.

[pinterf]

A boss knows when he is undereducated in a topic he can always rely on the opinion of quality consultants Verdict: let's treat top left the same way as left. (?)

[FranceBB]

Originally Posted by pinterf

Verdict: let's treat top left the same way as left. (?)

Sounds good to me. I'll wait others to confirm this too, though, then xD

[anton_foy]

Originally Posted by FranceBB

Sounds good to me. I'll wait others to confirm this too, though, then xD

Mob rule?
But to be blunt what does it mean if chroma is located faulty in this way? Chroma bleeding?

[FranceBB]

Originally Posted by anton_foy

what does it mean if chroma is located faulty in this way?

So if you handle let's say 4:2:0 Type 2 as Type 0?
Well, at high enough resolutions like UHD it will be hard to spot, but it will look blurrier and slightly out of the boundaries / shifted towards a side.

Originally Posted by anton_foy

Chroma bleeding?

Sort of, but the higher the resolution, the lower the shift, the less you'll notice.

This is a chroma shift happening in an SD material, however I exasperated the shift a bit by 3 points rather than 0.5 to show you the effect:




Let's now suppose to have a real life example in which we're wrongly assuming a chroma location and we're performing the 0.5 shift (when we shouldn't):



Can you see it? No? Well, you're not alone, it takes a 2000% zoom in to get a proper grasp to what it does:



you can see the color tone is different (wrong) on the left compared to the right, so as you can see a real life shift is so subtle that most people will never notice, however it's there and it's wrong.

[Reel.Deel]

The effect of correct and wrong chroma placement can be better seen with a synthetic example:



Here the RGB sample was converted to YUV420 using the "MPEG2" chroma placement. The it was converted back to RGB with the corresponding chroma placement, as shown in the image. Then PointResize 4X since it's easier to see.
As FranceBB said, it's hard to spot the wrong chroma placement, especially in live footage.

Here's the script I used to create the example:

Blankclip(width=48, height=16, pixel_type="RGB32", color=$FF0000, length=1) #red
AddBorders(0,0,0,16,$00FF00) # green
AddBorders(0,0,0,16,$0000FF) # blue
AddBorders(0,0,0,16,$00FFFF) # cyan
AddBorders(0,0,0,16,$FF00FF) # magenta
AddBorders(0,0,0,16,$FFFF00) # yellow
src = last

mask = src.ExtractR().mt_lutspa(mode="absolute", expr="x 32 % 16 < 0 1 ? y 32 % 16 < 0 1 ? + 1 == 0 255 ?")
mask2 = src.ExtractR().mt_lutspa(relative=false, expr="x 16 % 0 == y 16 % 0 == | 255 0 ?")

grid1 = Overlay(src, src.FlipVertical(), mask=mask)
grid2 = Overlay(src, src.FlipVertical(), mask=mask2)

StackHorizontal(grid1, grid2)
src2 = last.AddBorders(0,0,4,0)

ConvertToYV12(ChromaOutPlacement="mpeg2")

mpeg1 = last.ConvertToRGB32(ChromaInPlacement="mpeg1")
mpeg2 = last.ConvertToRGB32(ChromaInPlacement="mpeg2")
topleft = last.ConvertToRGB32(ChromaInPlacement="top_left")

Interleave(mpeg1, mpeg2, topleft)

StackHorizontal(src2, last)
PointResize(width*4, height*4)
AddBorders(0,16,0,0)

Text("RGB Source")
Text("MPEG1 CHROMA LOCATION (WRONG)", x=51*8, first_frame=0, last_frame=0)
Text("MPEG2 CHROMA LOCATION (CORRECT)", x=51*8, first_frame=1, last_frame=1)
Text("TOPLEFT CHROMA LOCATION (WRONG)", x=51*8, first_frame=2, last_frame=2)

AssumeFPS(1,2)

[anton_foy]

Thanks for the demonstrations. Probably this is happening to my UHD-footage when I import it into avs+ because it has got a slight color shift compared to the original file. Any suggestions on how to correct this? Maybe I need to upload a sample?

Edit: it is XAVC-S 8-bit 4:2:0 I think it is some mpeg4 format.

[DTL]

"how to correct this?"

Typically it is applying resample to YUV format with sub-sample UV (or Y is it give better result) shift to the required direction.

[FranceBB]

Originally Posted by anton_foy

it is XAVC-S 8-bit 4:2:0 I think it is some mpeg4 format.

XAVC should be interpreted as left type 0, but it's always nice to double check. Feel free to upload a sample. A landscape will do, although someone holding a colour palette would be better.

[anton_foy]

Originally Posted by FranceBB

XAVC should be interpreted as left type 0, but it's always nice to double check. Feel free to upload a sample. A landscape will do, although someone holding a colour palette would be better.

Thanks DTL and FranceBb
Yes I have somewhere a clip with an IT8 chart. Will locate and upload it asap.