FFV1 RGB 16 bit?

[JonP01]

Hi,

I use the QTGMC deinterlacer as part of my workflow where I am also making multiple passes through Topaz Video AI where I am using the lossless FFV1 codec with an RGB 444 16 bit colour space. The reason is that since I am doing multiple input and output passes through Topaz I am remaining in the "internal" format that Topaz uses (RGB48) and obviously remaining totally lossless during the workflow (apart obviously from the effects of the filters I am using). From Topaz at a certain point in the workflow it then goes to Hybrid for temporal smoothing (source material is badly deinterlaced 25p - originally derived from 50i but unfortunately that is the best source that I have). The Hybrid output then goes back to Topaz for one final pass of yet another filter (AION AI) taking it to 50p.

With the Hybrid step, there does not seem to be any possible way to avoid an RGB to YUV conversion - whilst I can choose 16 bit and i444, I cannot choose RGB like I see in the dropdown box for the FFVHuff codec for example. The FFVhuff RGB option, however only processes material in RGB 16 bit (at least in all my testing) with the  Avisynth option selected under the filtering tab. This reduces processing speed drastically compared to the Vapoursynth option (the latter is about twice as fast) and in the end still outputs in YUV format regardless (and my input media is absolutely in RGB 444 16 bit format as per my Topaz parameters and this is verifiable with MediaInfo).

So my question is - is there any way at the "user" end I can tell FFV1 to remain within RGB 444 16 bit as per the input format? I did try to edit the associated json file for FFV1 but Hybrid appears to ignore it so I imagine the colour space options are hard coded elsewhere and I cannot change them.

I expect the answer is no but thought it worth asking just in case I have missed something.

Thank you.

[Selur]

No you haven't missed anything, Hybrid atm. does not support RGB for FFV1 atm..
Looking at the possible options:

Encoder ffv1 [FFmpeg video codec #1]:
    General capabilities: dr1 delay threads
    Threading capabilities: slice
    Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le yuv420p12le yuv422p12le yuv444p12le yuva444p16le yuva422p16le yuva420p16le yuva444p12le yuva422p12le yuva444p10le yuva422p10le yuva420p10le yuva444p9le yuva422p9le yuva420p9le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le gbrap14le gbrap10le gbrap12le ya8 gray10le gray12le gray14le gbrp16le rgb48le gbrap16le rgba64le gray9le yuv420p14le yuv422p14le yuv444p14le yuv440p10le yuv440p12le
ffv1 encoder AVOptions:
  -slicecrc          <boolean>    E..V....... Protect slices with CRCs (default auto)
  -coder             <int>        E..V....... Coder type (from -2 to 2) (default rice)
     rice            0            E..V....... Golomb rice
     range_def       -2           E..V....... Range with default table
     range_tab       2            E..V....... Range with custom table
     ac              1            E..V....... Range with custom table (the ac option exists for compatibility and is deprecated)
  -context           <int>        E..V....... Context model (from 0 to 1) (default 0)

I probably cloud add 16Bit RGB (rgb48le) support, but atm..

HuffYUVs 16bit RGB output works fine with Avisynth and Vapoursynth here.

Cu Selur

Ps.: RGB is always 444

[Selur]

=> Uploaded a new dev version which support RGB color formats with ffv1.

Cu Selur

[JonP01]

Thank you very much for the reply. I just tried the development version but it crashes out immediately if I select rgb but still works fine when selecting i444. The crash states "with exitCode -22" and also "crashed with exit status 0" on the Log tab. Although I had checked the debug file option before running it, it does not seem to produce any debug file so far as I could tell (or find). So I could only get it to produce a text report. I have attached them (one for a successful i444 run, the other for a failed rgb run. But I am not sure they are of any help. Coincidentally this is also exactly how FFvHuff crashed out when selecting rgb as well (though I only used it for testing purposes - I only use FFV1).

I did look at the report and I was just wondering if the ffmpeg command is correct where it states -color_range tv. I was wondering if that should have been -color range full but I don't pretend to be a ffmpeg command line expert - it took me a lot of time, trial and error just to do my own command lines for ffmpeg to get them working properly for final H.265 lossy encoding!

Anyway, I have attached the two reports if you wanted to take a look at some point. The "success_i444.txt" shows the successful run using color space i444. The fail_rgb.txt file is precisely the same input file and precisely the same settings - the only difference is that I changed the color space to rgb from i444.

Thank you.

[Selur]

Not a debug output -> useless to me. (read the sticky)
You might also, if your source is of good quality, those QTGMC settings make no sense. You might want to read up on QTGMCs settings.
Going to bed now.

Cu Selur

[JonP01]

I just changed the filtering on the top right drop down box on the Filtering tab from Vapoursynth (default on my setup) to Avisynth and ran it again - with rgb selected under the FFV1 tab but nothing else changed (and the same short test file as before). This time it worked and the output with MediaInfo correctly shows it as RGB 16 bit. So I am not sure what is happening here and for that matter I am not sure of the implication behind changing that drop down box setting or even if it matters - I will have to do some research and also check how it effects the processing speed.

---

Not a debug output -> useless to me. (read the sticky)
You might also, if your source is of good quality, those QTGMC settings make no sense. You might want to read up on QTGMCs settings.

I did read the sticky and changed the settings to produce a bug report but for some reason it does not produce one. I mentioned this in my previous post and acknowledged that the reports only might not be of any help and if that is the case that is fine - at least I tried.

As for QTGMC, I did thoroughly read up about it and have actually spent about 9 months refining my workflow which includes QTGMC (different settings for interlaced versus progressive input). The QTGMC documentation explicitly states that it can also be used on progressive input for temporal smoothing caused by poor deinterlacing (which is the problem I am dealing with in the source material) and I did very extensive testing to prove (or disprove) that to myself - carefully checking the final results on my LG OLED TV and making sure that the QTGMC step did actually madke an obvious and positive improvement. And it certainly did, though only with the settings I am using - applying source matching or enabling lossless for example produced a clearly inferior result to doing nothing at all but that is consistent with the QTGMC documentation on the topic in any case. I was just being thorough since the documentation was worded in such a way that it seemed to me that it was worth trying all the options regardless. 

http://avisynth.nl/index.php/QTGMC#Progressive_Input

So although you say the settings make no sense, they do work. At least in my situation and with the particular source material I am dealing with. If I were to use good quality progressive input and QTGMC it would be pointless and destructive to the final quality of the output but I am dealing with a special case here where the material was poorly mastered but it is the only source material in existence.

---

And my last post on the subject (bed time for me too). I just researched the differences between selecting the avisynth and vapoursynth options and it changes quite drastically what QTGMC filtering does - and avisynth is apparently an old 32 bit processing pipeline, no multithreading and does not support more than 8 bits in any case (and it explains why the test I did ran at less than half the speed of vapoursynth).

I also did a test where I just ran the input through Hybrid without any QTGMC filtering but with RGB selected and the resulting output was perfectly fine RGB 16 bit FFV1 according to MediaInfo.

So the changes you made to the development version for the RGB option work fine with the testing I have done and the problem I am having seems to be specifically related to QTGMC itself when RGB is selected.

I will happily stick with the workflow I was using before. Thank you for your quick responses and adding the RGB option.

[Selur]

a. you should look into creating a debug output (if Hybrid is not able to produce one, it might be a hint of a bigger problem)
b. for progressive input use Vapoursynth->Denoise->QTGMC not the one to deinterlace. (you mitht also want to read https://forum.selur.net/thread-3971.html and the thread linked in it)
c. Hybrid nowadays only comes with a 64bit Avisynth version, and the 32bit one is only added by an add-on. Maybe best deinstall Hybrid completely (with settings) and install it fresh.
=> can't really help with problems unless I get detailed info that allows to reproduce them, where a debug output usually is a big help.

Cu Selur