Chroma siting bugs?

[absence]

I was trying a 2.6 build and noticed different results from the following two functions:

ConvertToYV12(interlaced=true, chromaplacement="MPEG2")
ConvertToYV12(interlaced=true)

According to the documentation, MPEG2 is the default chromaplacement, so they ought to produce the same result. I took a look at the source code (convert_planar.cpp) and found out that the two cases use different code paths. I didn't go into them in detail, so maybe there's a bug, or maybe the difference is just noise caused by a different algorithm.

What DOES look like a bug is the chroma placement for DV (PLACEMENT_DV). The U offset is the same for MPEG2 and DV, but according to http://www.mir.com/DMG/chroma.html DV chroma samples are sited on top of luma samples, not between them vertically like MPEG2.

[IanB]

There is a difference only for YUY2 inputConvertToYV12(interlaced=true, chromaplacement="MPEG2")will used the new code path and convert YUY2 to YV16 (lossless) then to convert YV16 to YV12 (chroma resizing).
ConvertToYV12(interlaced=true)will use the 2.5 code, which fast converts YUY2 to YV12 directly (with some compromises).

The chroma placement code is a bit (a lot) of a mess. It currently parses in 2 place, 1st in ConvertToPlanarGeneric::CreateYV12() then again in ConvertToPlanarGeneric::ConvertToPlanarGeneric(). Neither code is complete or correct. It also does nothing for the YV12 -> YV12 case, which is probably when it is most needed. I will possibly move this functionality to a separate filter or better define the argument to remove the ambiguity.

Also your reference site is missing the "Progressive PAL DV chroma placement" offered by some cameras, which is Cb and Cr samples sited on alternate lines of the frame instead of the fields.
_______________________________________________

Discussion :-

I am thinking chroma placement is really only a YV12 format issue. There are 2 needs :-

1. YV12 input with specified chroma placement, including interlaced attribute, outputting to another planar format (YV24, YV16, YV12 or YV411) with normal Avisynth expected chroma placement.

2. Inputting with a planar format with normal Avisynth expected chroma placement, outputting to YV12 with specified chroma placement, including interlaced attribute.

Also available from this could be generic chroma plane shifting, but that really is incidental and warrants a separate script verb with it's own syntax even if it uses the same engine.

Thoughts?

[absence]

Thoughts?

Currently a user unaware of the chroma siting issue risks opening a YV12 file with DV encoding and process it with Avisynth filters that expect Cb and Cr to be sited at the same luma sample. I should know; I recently made this mistake, and the chroma of my deinterlaced double-rate result jumps up and down every other frame. :)

To make users aware of the problem there shouldn't be a default chroma siting when opening YV12 files, but an error message if a user doesn't somehow specify one. That way Avisynth can convert it to the siting it mandates (MPEG2?), as there is little sense in passing data with unsupported siting (e.g. DV) to the plugins. Of course, for people who really know what they're doing, it should be possible to override the automatic conversion.

Ideally, there could be a flag in the clip specifying the chroma siting instead of a conversion on input, but then all the plugins would have to support the different sitings.

[IanB]

Would have, Could have, Should have!

For better or worse Avisynth has no concept chroma sitting or a whole lot of other things like Is Interlaced. There have been discussions in the past about adding meta data to clips but they always fall apart when it comes to enforcement. The best that ever happens is someone writes a plugin to solve an issue, in this case a partially implemented ChromaPlacement option with bugs (sorry about that chief).

Over in VirtualDub land Avery Lee rigidly follows the fourCC definition for YV12 to the letter, ie. Mpeg2 chroma sitting, Black=16, White=235, Progressive picture structure, Rec601 colorimetry, etc ... It saves him a whole lot of grief from his users but it limits the available functionality. Here in Avisynth land we are a bit more laid back, we provide an internal format misnamed YV12. It provides 8 bit data planes with chroma information subsampled 50% both horizontally and vertically. That's it, everything else is freely a user choice. Various filters assume certain attributes about the data and it is the script authors responsibility to use or abuse those assumptions.


Also not sure why you would get chroma jumping up and down because of wrong sitting, the offset is a constant error, it does not change per frame/field.

[Wilbert]

Discussion :-

I am thinking chroma placement is really only a YV12 format issue. There are 2 needs :-

1. YV12 input with specified chroma placement, including interlaced attribute, outputting to another planar format (YV24, YV16, YV12 or YV411) with normal Avisynth expected chroma placement.

2. Inputting with a planar format with normal Avisynth expected chroma placement, outputting to YV12 with specified chroma placement, including interlaced attribute.

Sounds great.

[absence]

Various filters assume certain attributes about the data and it is the script authors responsibility to use or abuse those assumptions.

While enforcing the use of metadata is impossible, it would be better for Avisynth to have guidelines than to leave it completely up to chance. The level of consistency would increase, if only slightly. :)

Also not sure why you would get chroma jumping up and down because of wrong sitting, the offset is a constant error, it does not change per frame/field.

When DV siting is interpreted as MPEG2 siting, interpreted Cb is 1.5 lines away from actual Cb in the top field and 0.5 in the bottom one. For Cr it's the other way round.

[IanB]

Ah yes, there is a SeparateFields() and DoubleWeaveFields() in the mix. :o

Having read the code a bit harder, the chromaplacement code is only active for YV12 output, i.e. ConvertToYV12(). It attempts to do DV chroma siting for the output YV12 data from input co-sited YV24, YV16 or YV411 chroma (Vertical chroma subsampling == 1). The 2nd setup code in ConvertToPlanarGeneric::ConvertToPlanarGeneric() has the final word. The 1st setup code results in ConvertToPlanarGeneric::CreateYV12() are overwritten by the 2nd. :(
___________________________

Okay what functionality are you trying to achieve?

I am guessing you are using Cedocida DV codec with the DV YV12 chroma sampling Decoder option.

And I am further guessing you want to take the input interlaced PAL DV from Cedocida and produce 50 frames per second Bobbed output, either YUY2 or YV12 with MPEG2 progressive chrome siting ready for other regular processing.

Am I close?

[absence]

Am I close?

Yes. :) I solved it by writing my own plugin, but what I wanted to do was to deinterlace YV12 with DV siting using TempGaussMC, which seems to assume MPEG2 siting. The DV YV12 interlace had to be converted to MPEG2 YV12 interlace, and then TempGaussMC makes it MPEG2 YV12 progressive (50 frames).

[2Bdecided]

But there are two ready-made solutions inside Cedocida itself.

You can make it output MPEG-2 YV12 (it does the conversion), or you can make it output correct YUY2, and (if you wish) convert it to MPEG-2 YV12 in AVIsynth.

Cheers,
David.