AviSynth+ thread Vol.2

[StainlessS]

Oh, I forgot to post the R -> String(range) expanded whotsit,

"255 x 0 == " + String(range) + " 0 == | 1 x ? x 0 == " + String(range) + " 0 == | 1 " + string(range) + " ? / 2 ^ /"

so,
mt_lut(expr="255 x 0 == " + String(range) + " 0 == | 1 x ? x 0 == " + String(range) + " 0 == | 1 " + string(range) + " ? / 2 ^ /",u=1,v=1)

limit it to epsilon?
I was not getting any divide by zero with range == 0 anyway [I dont think, even though I should have], I'll retry.

limit it to epsilon?
Well testing in the BrainDeadFolly thingy, [may have to zoom it a bit - 1 dot in top left corner, and rest along the bottom]
https://i.postimg.cc/MHtSNzmD/Brain-Dead-Folly-00.jpg (https://postimages.org/)
So looks correct. [only even x values plotted - avoid stack exhaustion]

EDIT: I did originally think of Dogway fix too, but avoided it for some reason (cant remember why, and chose the verbose one).

[gispos]

Thank you StainlesSS, I just tried it and it works with no errors.
Does the mt_lut in the first line also have to be changed? (line 309)

GFmask = radius==1 ? input.mt_edge(mode="min/max",thY1=0,thY2=255,u=1,v=1).mt_lut(expr="255 x 1 "+string(range)+" / * 2 ^ /",u=1,v=1).removegrain(19,-1)
\ : mt_luts(input,input,mode="range",pixels=mt_square(radius),expr="y",u=1,v=1).
\ mt_lut(expr="255 x 0 == " + String(range) + " 0 == | 1 x ? x 0 == " + String(range) + " 0 == | 1 " + string(range) + " ? / 2 ^ /",u=1,v=1).removegrain(19,-1)

[gispos]

I would like to draw the avisynth developers attention to the problem with the frame properties and prefetch.
If the frame properties are read immediately after a get_frame, avisynth gets stuck when prefetch is used.

Sequences when initializing a new clip, for illustration only:

clip = env.invoke('Eval', args)
frame = clip.get_frame(nr)
re = env.props_get_matrix(frame)

That still worked up to 3.71 test 22 version, the 3.71 final 3593 stuck.
With the final version, a waiting time must be set after get_frame, which is 0.1 to 1.0 seconds, depending on the filters used. (Only with prefetch)

clip = env.invoke('Eval', args)
frame = clip.get_frame(nr)
time.sleep(1.0)
re = env.props_get_matrix(frame)

Furthermore there is the problem that the frame properties of the old clip are apparently still in the memory when a new clip is created and the same frame number is called and no frame properties are available because a filter has not passed them on.

Then it can happen that you get the properties from the previous clip.
This is not the case with version 3.71 test 22 and all older ones

It would also be desirable if one would test newer versions with AvsPmod. I think AvsPmod is used by some users and can be used as an indicator for the C interface:
1.) The C interface is used.
2.) Reads and displays the frame properties.

AvsPmod test version 1 second waiting (https://www.mediafire.com/file/e8iz3bb9u39sw0c/AvsPmod_v2.7.0.2.test_(Windows_x86-64).zip/file)

[StainlessS]

Does the mt_lut in the first line also have to be changed? (line 309)

Sorry, GP, I'll try get to it today.

[Emulgator]

gispos: I would like to draw the avisynth developers attention to the problem with the frame properties and prefetch.
Maybe you can PM Ferenc (pinterf) about that.

[gispos]

Maybe you can PM Ferenc (pinterf) about that.
For what reason?
The version isn't even from him, and if everyone would send him their problems with Avisynth he would be rightly annoyed.

[real.finder]

I think pinterf already seen the problem by now, but maybe he busy to answer

anyway, maybe it better to post it https://github.com/AviSynth/AviSynthPlus/issues to not be forgotten

[Dogway]

I found that certain pixel addressing combinations have a hit on performance, for example the following:
Expr("x[-1,1] x[1,-1] - dup * x[-1,-1] x[1,1] - dup * + sqrt ","") # 447

is about 2% slower than this:
Expr("x[-1,-1] x[1,1] - dup * x[-1,1] x[1,-1] - dup * + sqrt ","") # 455

[tormento]

I found that certain pixel addressing combinations have a hit on performance
Yesterday I did an encode on x264 with SMDegrain (last update of yours) and for the first time I saw the CPU to "idle", i.e. not going to 100% and that was reflected by core temperatures too, that were 4-5 °C lower than usual.

I don't know if you found some not optimized working path and that is correlated.

[Dogway]

After some suggestions I tested overlap with blksize/4 when refinemotion is used, this is more performant but I had to assess quality. I found that it retains more details akin to truemotion=true but not as much probably, similarly grain isn't recovered as much so in a balance I thought it was worth it. Maybe that was it? I plan to run zopti in a few months after I take some rest to further tune SMDegrain and FrameRateConverter.

[DTL]

It is good to add to wiki about RGB and YUV formats (http://avisynth.nl/index.php/Color_spaces ): the digital YUV colorspace is more limited in precision in compare with digital RGB colorspace. So for comparable quality it is about RGB 8bit and YUV 10bit. One consequence mean using YUV8 (YUV 4xx 8bit, typical storage) stage for converting to RGB8 (RGB24, typical display) cause more digital distortions (banding).

YUV cover 'wider' colour gamut in compare with RGB but this cause precision lost with 'natural' colour gamut with same storage integer bits per value. So the conversions RGB<->YUV with same bitdepth are not lossless even with YUV444. The error is about 1 LSB but it visible on smooth colour gradients with 8bit. At first I think it is an issue in Convert() functions.
May be it is already somewhere covered in AVS wiki ?

[LigH]

Your conclusion is not completely correct. The precision reduction has two possible reasons: "TV range" (but full range YUV exists too) and float arithmetics in the YCbCr conversion formulas (avoidable in the YCgCo model). If you don't need to convert between RGB and YUV, then full range YUV has the same precision of 8 bits per component as RGB. Thus, YUV is not generally worse; it is only worse for RGB based devices.

[DTL]

""TV range" (but full range YUV exists too)"

Here is the test: taking RGB $808080 something around mid-grey colour (no-colour grey) and slowly increase saturation of green

BlankClip(color=$FF808080)

ConvertToYUV444(matrix="PC.601")
ConvertToRGB32(matrix="PC.601")

ScriptClip ("""Subtitle (String (AverageR()) + " " + String (AverageG()) +" "+ String (AverageB()))""")


Input $FF808080 - out 128 128 128 = OK
Input $FF808180 - out 129 129 129 < ??? - luma raised, no green colour = error in colour tone and colour saturatrion
Input $FF808280 - out 128 130 127 < ??? - green colour + some minus-blue colour = error in colour tone
Input $FF808380 - out 129 131 128 < ??? - green colour + some plus-red colour = error in colour tone

The only known way to fix - use >8 bit processing of RGB->YUV->RGB:

BlankClip(color=$FF808080)

ConvertBits(16)

ConvertToYUV444(matrix="PC.601")
ConvertToRGB32(matrix="PC.601")

ConvertBits(8)

ScriptClip ("""Subtitle (String (AverageR()) + " " + String (AverageG()) +" "+ String (AverageB()))""")

Input $FF808080 - out 128 128 128 = OK
Input $FF808180 - out 128 129 128 = OK
Input $FF808280 - out 128 130 128 = OK
Input $FF808380 - out 128 131 128 = OK

[poisondeathray]

It is good to add to wiki about RGB and YUV formats (http://avisynth.nl/index.php/Color_spaces ): the digital YUV colorspace is more limited in precision in compare with digital RGB colorspace. So for comparable quality it is about RGB 8bit and YUV 10bit. One consequence mean using YUV8 (YUV 4xx 8bit, typical storage) stage for converting to RGB8 (RGB24, typical display) cause more digital distortions (banding).

YUV cover 'wider' colour gamut in compare with RGB but this cause precision lost with 'natural' colour gamut with same storage integer bits per value. So the conversions RGB<->YUV with same bitdepth are not lossless even with YUV444. The error is about 1 LSB but it visible on smooth colour gradients with 8bit. At first I think it is an issue in Convert() functions.
May be it is already somewhere covered in AVS wiki ?




That is the expected result for 8bit RGB=>YUV=>RGB round trip. +/- 3 value errors

Not just precision and 8bit rounding errors, but multiple 8bit YUV values can map to the same RGB value, which produces more "banding" instead of smooth gradient

In general, 10bit YUV or greater is required for lossless round trip from 8bit RGB => YUV => 8bit RGB, if implemented properly.


But you can demonstrate cases where 10bit is not sufficient with internal Convert(), yet 10bit is sufficient with AvsResize/zimg. ( 10bit also sufficient with other programs like NLE's) .

In this example, 12bit with internal convert is required , but 10bit with AvsResize/zimg or other programs works ok
https://forum.doom9.org/showthread.php?p=1897686#post1897686

This is pinterf's explanation for the difference using internal convert
https://forum.doom9.org/showthread.php?p=1902783#post1902783

[LigH]

(matrix="PC.601") ... please read: Wikipedia: YUV (https://en.wikipedia.org/wiki/YUV), specifically chapters 2.1: SDTV with BT.470 (oh, look, fractional matrix coefficients with 3 decimal places) and 3: Numerical approximations (okay, small integers here, but with rounding errors, and they cause most of the banding, especially because they need to be applied forth and back).

A YCoCg (https://en.wikipedia.org/wiki/YCoCg) matrix has much simpler coefficients, halves and quarters, nice to handle in binary form.

[DTL]

"3: Numerical approximations (okay, small integers here, but with rounding errors, and they cause most of the banding, especially because they need to be applied forth and back)."

May be good to copy to Avisynth wiki (and may be Convert() functions note). May be possible to develop some 'pre-distortions' for 8bit format conversions to minimize colour tone shift (that is more visible ?) ? Currently the distribution of rounding errors is equal for colour tone, luma and saturation errors ? I see typical solutions is add dithering. Unfortunately 8bit still widely used and in end-users displays it is the only supported with h.264 encoding. So using of h.265 with 10bit decreases number of possible users of encoded content.

[pinterf]

Avisynth 3.7.2 test 1
Avisynth+ 3.7.2 test 1 (20220113) (https://drive.google.com/uc?export=download&id=1A2Jb2OSYzGI0tBFEmvlT0RxxLwVoCiP_)

20220113 3.7.2-WIP
------------------
- Fix: Attempt to resolve deadlock when an Eval'd (Prefetch inside) Clip result is
used in Invoke which calls a filter with GetFrame in its constructor.
(AvsPMod use case which Invokes frame prop read / ConvertToRGB32 after having the AVS script evaluated)
Remark: problem emerged in 3.7.1test22 which is trying to read frame properties of the 0th frame in its constructor.
A similar deadlock situation was already fixed earlier in Neo branch and had been backported but it did not cover this use case.
- Fix: Histogram AudioLevels half character upshift (regression since v3.6)
- Bump Copyright year to 2022

[FranceBB]

Nice one, Ferenc!
But... it doesn't work. :(


Remark: problem emerged in 3.7.1test22 which is trying to read frame properties of the 0th frame in its constructor.

the problem is still there I'm afraid... :(


With 3.7.1 Stable:

https://i.imgur.com/hbWuDkI.png

And I had to get rid of frame properties to make it work:

https://i.imgur.com/vWyahcA.png


With 3.7.2 Test 1 it's the same thing:

https://i.imgur.com/WRND0xO.png

and once I get rid of frame properties...

https://i.imgur.com/A4BfjG3.png

Source:


General
Complete name : \\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf
Format : MXF
Commercial name : XDCAM HD422
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 5.50 GiB
Duration : 14 min 58 s
Overall bit rate : 52.6 Mb/s
Package name : Source Package
Encoded date : 2022-01-12 10:16:12.076
Writing application : Avid Technology, Inc. Avid MediaProcessor Plug-In 1.0.54.10052.1
Writing library : MXF::SDK (4.7.8) on Win64 4.7.8.10137.1

Video
ID : 512
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Format settings, picture structure : Frame
Format settings, wrapping mode : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 14 min 58 s
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
Standard : PAL
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
Stream size : 5.23 GiB (95%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 768
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Codec ID : 0D01030102060300-0402020101000000
Duration : 14 min 58 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 123 MiB (2%)
Locked : Yes

Audio #2
ID : 1024
Format : PCM
Format settings : Little
Format settings, wrapping mode : Frame (AES)
Codec ID : 0D01030102060300-0402020101000000
Duration : 14 min 58 s
Bit rate mode : Constant
Bit rate : 1 152 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 24 bits
Stream size : 123 MiB (2%)
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 settings : Material Package
Time code, striped : Yes
Title : Timecode

Other #2
ID : 0-Source
Type : Time code
Format : MXF TC
Frame rate : 25.000 FPS
Time code of first frame : 10:00:00:00
Time code settings : Source Package
Time code, striped : 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




Disabling "Read matrix from source or script" in AVSPmod fixes it, but still...

Using VirtualDub, it works, regardless of frame properties:

https://i.imgur.com/4rr1DmN.png

[pinterf]

This issue must be different, there is no Prefetch here.
EDIT:
Can you put a ConvertToRGB32() at end of the script?
(to check if it fails; AvsPMod (as far as I saw in the source) does two additional things after evaluating our original AVS script: reads frame properties and converts the clip to rgb32 in order to display it.


My fix was intended to heal only the "hang" issue.

[gispos]

As soon as FranceBB has it in his hands, he breaks it. :D

Try this version, no problems for me.

32bit:
https://www.mediafire.com/file/ar8qpzeln1ul6so/AvsPmod_v2.7.0.2.3_(Windows_x86-32).zip/file
64bit:
https://www.mediafire.com/file/uvtp8xjutll09sj/AvsPmod_v2.7.0.2.3_(Windows_x86-64).zip/file

[FranceBB]

Try this version, no problems for me.

32bit:
https://www.mediafire.com/file/ar8qpzeln1ul6so/AvsPmod_v2.7.0.2.3_(Windows_x86-32).zip/file
64bit:
https://www.mediafire.com/file/uvtp8xjutll09sj/AvsPmod_v2.7.0.2.3_(Windows_x86-64).zip/file

Nope. :(
Same error as before.
Please note that this happens only with XDCAM files muxed in .mxf
I can share a sample if you want, 'cause I've just tried with a ProRes file muxed in .mov and it works just fine.
Same goes for an H.264 file in .mp4.

As soon as FranceBB has it in his hands, he breaks it. :D

eheheheh nah, it's more like: "literally no one except FranceBB uses weird FULL HD yv16 50 Mbit/s 25i TFF MPEG-2 files muxed in mxf anymore, so no one ever checked" xD


Can you put a ConvertToRGB32() at end of the script?



Interesting error, it fails with this:

https://i.imgur.com/nW1r5LT.png

however this is a bit weird given that it's a simple yv16 with the standard MPEG-2 chroma placement (after all it IS an MPEG-2 eheheheh).

Adding propclearall() fixes it and allows me to use ConverttoRGB32():

video=LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf")
ch1=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf", stream_index=1)
ch2=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf", stream_index=2)
audio=MergeChannels(ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2)
AudioDub(video, audio)

propClearAll()

ConverttoRGB32()

speaking of which, let me see if I can just get rid of the chroma location property and try with this:

video=LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf")
ch1=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf", stream_index=1)
ch2=LWLibavAudioSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\UCN12982_GHOST_FRAME.mxf", stream_index=2)
audio=MergeChannels(ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2)
AudioDub(video, audio)

propDelete("_ChromaLocation")


Success!
Getting rid of the Chroma Location property makes it work! :eek:

https://i.imgur.com/rlraTGU.png


So now we know what happened!
Basically ConverttoRGB32() fails due to the Chroma Location frame property, therefore when I try to use AVSPmod, it tries to convert to RGB32 invoking such a function, but since such a function fails, it won't display anything and fail instead!!

[pinterf]

Thanks! Can you put a propShow() before the property delete, to see what the original _ChromaLocation was set to?

[gispos]

(to check if it fails; AvsPMod (as far as I saw in the source) does two additional things after evaluating our original AVS script: reads frame properties and converts the clip to rgb32 in order to display it.
The clip itself is not converted to RGB32. A DisplayClip is created which is converted to RGB32.
But the frame properties (matrix) are read from the original source clip.

[FranceBB]

Thanks! Can you put a propShow() before the property delete, to see what the original _ChromaLocation was set to?

Sure thing, there you go:

https://i.imgur.com/f736Nld.png

Looks like the indexer is reporting another kind of Chroma Location, 'cause it should be _ChromaLocation = 0 left (mpeg2) and not _ChromaLocation = 2 top_left... interesting...

This is another XDCAM file and it has the very same problem:

https://i.imgur.com/igT1odL.png

and ffprobe seems to agree with the indexers:

[STREAM]
index=0
codec_name=mpeg2video
codec_long_name=MPEG-2 video
profile=4:2:2
codec_type=video
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=1920
height=1080
coded_width=0
coded_height=0
closed_captions=0
film_grain=0
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv422p
level=2
color_range=tv
color_space=bt709
color_transfer=bt709
color_primaries=bt709
chroma_location=topleft

This is yet a different XDCAM file I received from A&E:

index=0
codec_name=mpeg2video
codec_long_name=MPEG-2 video
profile=4:2:2
codec_type=video
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=1920
height=1080
coded_width=0
coded_height=0
closed_captions=0
film_grain=0
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv422p
level=2
color_range=tv
color_space=unknown
color_transfer=bt709
color_primaries=unknown
chroma_location=topleft

and this is a movie I've got from Notorious Pictures and it says top left too:

[STREAM]
index=0
codec_name=mpeg2video
codec_long_name=MPEG-2 video
profile=4:2:2
codec_type=video
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
width=1920
height=1080
coded_width=0
coded_height=0
closed_captions=0
film_grain=0
has_b_frames=1
sample_aspect_ratio=1:1
display_aspect_ratio=16:9
pix_fmt=yuv422p
level=2
color_range=tv
color_space=unknown
color_transfer=bt709
color_primaries=unknown
chroma_location=topleft


Ok, either there's something fishy and totally broken here, or I've lost my certainties...

[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?

(link available for 7 days)

[pinterf]

Topleft is treated as invalid for 422, it's accepted only for 420

[FranceBB]

Topleft is treated as invalid for 422, it's accepted only for 420

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.

Top Left is Type 2, so the one generally found in H.265 UHD HDR PQ BD.

Now, those files are MPEG-2 50 Mbit/s BT709 SDR in FULL HD and 4:2:2 8bit planar.
Sony made the XDCAM standard in 2003 and the XDCAM-50 is from 2006 or something like that if I remember correctly.
Back then, Type 2 top left didn't even exist, did it?
Besides, I would find hard to believe that such a standard uses top left instead of left, given that it's an MPEG-2, right?

So we can assume that indexers and ffprobe are all wrong and that it's actually Type 0, left, MPEG-2, right?

If someone is willing to download the masterfile and check I would really appreciate it.
Also 'cause if it's actually Type 0 and indexers + FFMpeg say "Type 2", this is a BIG BIG PROBLEM and we need a fix soon.

[Dogway]

Same error trying to display the clip, I'm stable 3.7.1 and AvspMod 2.6.7.9 with "read from source script" disabled. propclearall() fixes it. I will try to check chroma placement, haven't seen an empirical method to find out so.

EDIT: Yes, looks MPEG2 to me

[takla]

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.

Top Left is Type 2, so the one generally found in H.265 UHD HDR PQ BD.

Now, those files are MPEG-2 50 Mbit/s BT709 SDR in FULL HD and 4:2:2 8bit planar.
Sony made the XDCAM standard in 2003 and the XDCAM-50 is from 2006 or something like that if I remember correctly.
Back then, Type 2 top left didn't even exist, did it?
Besides, I would find hard to believe that such a standard uses top left instead of left, given that it's an MPEG-2, right?

So we can assume that indexers and ffprobe are all wrong and that it's actually Type 0, left, MPEG-2, right?

If someone is willing to download the masterfile and check I would really appreciate it.
Also 'cause if it's actually Type 0 and indexers + FFMpeg say "Type 2", this is a BIG BIG PROBLEM and we need a fix soon.

Maybe get in touch with ffmpeg devs?
https://ffmpeg.org/contact.html#IRCChannels
https://ffmpeg.org/contact.html#MailingLists

[FranceBB]

Maybe get in touch with ffmpeg devs?
https://ffmpeg.org/contact.html#IRCChannels
https://ffmpeg.org/contact.html#MailingLists

I opened a ticket: https://trac.ffmpeg.org/ticket/9598#ticket

[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]

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 (https://freeimage.sourceforge.io/fnet/html/4A015DE9.htm)" 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 (https://web.archive.org/web/20010209092224/http://bmrc.berkeley.edu/research/mpeg/faq/mpeg2-v38/faq_v38.html)
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 (https://mjpeg-users.narkive.com/O1iMu1ro/chroma-sample-alignment#post3)
As you say in your web page, 4:2:2 always has co-sited chroma samples...

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

Edit:

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.php?p=1953360#post1953360

[FranceBB]

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.


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


Exactly!


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


Neither have I, in fact.

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
https://i.ibb.co/TKmRLfX/page431.png

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]

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]

How VS guys didn't noticed this bug?

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



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.

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

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]

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


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


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.





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]

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]

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

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

[FranceBB]

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.


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:

https://i.imgur.com/6i38khc.png
https://i.imgur.com/bWeSVea.png

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):

https://i.imgur.com/o46iMzc.png

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:

https://i.imgur.com/182F5of.png

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:

https://i.ibb.co/3kTYhvb/chromalocations.png

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]

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]

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.