[BUG] Interlace Store Method Changing Upon Conversion

[Selur]

Download access is password protected.
-> send you a new link to my current dev version via PM, try with that one (remember to recreate the jobs and not try old ones) and if that version fails, share a debug output in a way I can access it.

Cu Selur

[Analog]

Hi Selur,

I tried the latest dev build and it won't boot. I get the following errors in order:

"QSVEncModel already has a field named vuiRangeValue"

"QSVEncModel already has a field named multiBFramePyramid"

"CalculatorModel doSet-> found no field: 'qsvenc_ignoreBelowOneMB'" x11 times

Then many popups rapidly appear and close before Hybrid closes w/o any other information. Since it won't start I can not provide any other debug information...

Any help would be appreciated!

P.S. I also updated permissions on the file in my previous post. Sorry about that.

[Selur]

ah that's a debug message I left enabled while building the dev version.
-> will look at it after work today

[Selur]

Send you a new link via pm.

Cu Selur

[Analog]

Hi Selur,

I was able to try the latest dev version that you sent me, but the "size too small" bug is still there.

I experimented with this a little and found that it only seems to happen when I convert from 10-bit FFV1 to 8-bit FFV1. 10-bit FFV1 to 10-bit FFV1 works fine while 10-bit v210 to 8-bit FFV1 also works fine. I need to do this conversion due to QTGMC only accepting 8-bit files... It did work before.

The download here has debug log output, input file, and profile: https://drive.google.com/file/d/1TWnTlje...sp=sharing

Let me know if you have any ideas...

Thanks!

[Selur]

I don't get why you do the conversion to 8bit FFV1, before using QTGMC since Hybrid should convert to 8bit automatically.
Problem is with:
[codc]"C:\Program Files\Hybrid\64bit\ffmpeg.exe" -y -noautorotate -nostdin -threads 8 -i "D:\VIDEO\outputsdfg.mkv" -map 0:0 -an -sn -vf scale=in_range=pc:out_range=pc -sws_flags accurate_rnd+full_chroma_inp,setfield=bff -pix_fmt yuv422p -fps_mode passthrough -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 4 -slicecrc 0 -flags +ildct+ilme -top 0 -metadata encoding_tool="Hybrid 2022.08.26.1" "C:\VIDEO\output_2022-08-27@00_11_46_6410_04.mkv"[/code]
Seems like:

[swscaler @ 000001885a3b0bc0] [Eval @ 0000007f2a5fde40] Invalid chars ',setfield=bff' at the end of expression 'full_chroma_inp,setfield=bff'
[swscaler @ 000001885a3b0bc0] Unable to parse option value "full_chroma_inp,setfield=bff"

is the issue.
Seems like combining the decoder and encoder call fails.
=> I'll look at it.

[Analog]

Thanks for looking into this so quickly!

I used to go directly from interlaced 10-bit FFV1 to progressive 10-bit ProRes before the QTGMC update, but I don't see a way to convert from 10-bit FFV1 to 8-bit ProRes in one step...? (I could be missing it!) So I'm converting to interlaced 8-bit FFV1 as an intermediate step until HAvsFunc is fixed. I also tried converting from interlaced 10-bit FFV1 to progressive ProRes with the latest dev release but I still get borked (washed out) so I'm not sure how to force it to process as 8-bit.

[Selur]

I don't see a way to convert from 10-bit FFV1 to 8-bit ProRes in one step...?

Open file, set ProRes with 8bit as output.

also tried converting from interlaced 10-bit FFV1 to progressive ProRes with the latest dev release but I still get borked (washed out)

If you would feed 10bit content to a 8bit encoder it would simply crash, since it could not handle the extended color ranges. (and even if it would clip the ranges to 0-255 or 16-235 you would not get washed out colors but basically a black output)
So I would say:
That is not a problem with 10bit or 8bit handling, normally I would say it sounds like a color matrix or luma range issue, but since
your content has HDR infos (Master Display: G(10500,35500)B(7000,4000)R(33500,16500)WP(15505,15810)) with it, it probably simply is that these infos are not kept properly.
Since neither FFV1 not ProRes support HDR signaling by itself this is related to tagging in the container.
Also something is seariously wrong with the flagging of your input.

Color range                              : Full
Color primaries                          : BT.470 System M
Transfer characteristics                 : BT.470 System M
Matrix coefficients                      : FCC 73.682
Mastering display color primaries        : R: x=0.670000 y=0.330000, G: x=0.210000 y=0.710000, B: x=0.140000 y=0.080000, White point: x=0.310100 y=0.316200

HDR content uses Rec. 2020ncl or Rec. 2020cl color matric nocth fcc which is used for SD content. Also HDR content usually does not use 'full' but 'limited' color range. I wouldn't be surprised if you run into issues there with some decoders.

I fixed the FFV1 10bit to 8bit conversion. The main issues were:
a. a bug in Hybrid regarding the combination of decoder and encoder calls
b. a bug in ffmpeg which accepts '-fps_mode passthrough' as one argument, but can't properly parse '-fps_mode' 'passthrough' when fed through an option list.
-> fixed a. and replace '-fps_mode' with the old and depricated '-vsync' option and send you a link to a new dev version, which should allow the FFV1 10bit to FFV1 8bit conversion, but you really should look into your handling of color/vui signaling since atm. the signaling of your content is wrong and proper decoding is mainly dependend on luck.
(Hybrid does allow to create non-compliant vui signaling, but it assumes the user is aware of what his setting mean,..)

Cu Selur

Ps.: QTGMC works fine here with 10bit content,... (support for 10bit was added a year ago ar so to QTGMC...)

[Analog]

Hi Selur,

I tried the dev release (2022.08.27.1) you sent me but, unfortunately, the same exact failure still occurs with the example file I sent you. Maybe your changes didn't commit properly to the build?

Open file, set ProRes with 8bit as output.

I really must be blind. I can't find where I can choose the bit depth. I checked under the ProRes tab (which always shows the source bit depth) and the various filter tabs... Should I be checking a different tab?

If you would feed 10bit content to a 8bit encoder it would simply crash, since it could not handle the extended color ranges. (and even if it would clip the ranges to 0-255 or 16-235 you would not get washed out colors but basically a black output)

It wouldn't simply discard the last two bits of precision, a la audio bit crushing?

That is not a problem with 10bit or 8bit handling, normally I would say it sounds like a color matrix or luma range issue...

...QTGMC works fine here with 10bit content,... (support for 10bit was added a year ago ar so to QTGMC...)

Yes, QTGMC works with 10-bit, but a bug causes washed out output when source matching is enabled. We discussed this back in July. I still have to file a bug report at the HAvsFunc GIT. It used to work with an old dev build I used in April so I'm sure it's something they did...

Also something is seariously wrong with the flagging of your input.

Yes, I'm messing around with these parameters to see if the old FCC color gamut (which is wider than SMPTE 601 but smaller then Rec 2020) can be reproduced with these parameters. I plan on researching how these tags are prioritized/interpreted in the future. Setting these on files that are known good (most of my FFV1 captures) has been OK on playback in the applications I use so far.

Also HDR content usually does not use 'full' but 'limited' color range.

My BlackMagic hardware is capturing as full but flagging as limited via the Thunderbolt interface so I've been updating the tags to full range. Its a big bug on their end and I'm still figuring out the best way to compensate on my end. For now, I'm flagging the master files as full range and converting to limited range with the "levels" filter only when making output for YouTube, etc. The tags work so far in my known good files...

[Selur]

You are right you can't encode to 8bit with ProRes no matter what, since there is no 8bit ProRes.
ProRes is always 8bit or 10bit.

It wouldn't simply discard the last two bits of precision, a la audio bit crushing?

No.

Yes, QTGMC works with 10-bit, but a bug causes washed out output when source matching is enabled. We discussed this back in July. I still have to file a bug report at the HAvsFunc GIT. It used to work with an old dev build I used in April so I'm sure it's something they did...

It's probably a bug in Vapoursynth.
-> using VapoursynhtR60RC1 should fix it.

Cu Selur