This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

[BUG] Maintaining Interlace On Output
#1
Hi Selur,

I recently upgraded to 2022.03.20.1 and have been having issues maintaining interlace (interlaced input -> interlaced output) when I convert from uncompressed YUV to FFV1. (I have not tried changing those parameters)

[*]What Hybrid version did you use?(Windows/Mac/Linux 32/64bit + versions number)
Hybrid 2022.03.20.1; Windows 11 x64 build 22000
[*]What did happen? If an error message came up what did it exactly say?
When starting encoding a box that says "Aborting: Encoding is set for progressive output, but the input is not progressive!"
[*]What did you do to get to the bug? (best thing is a detailed step-by-step guide so that I can reproduce the problem)
Set video processing to FFV1, output to local output, disable de-interlacing, import video, begin encoding.
[*]Debug output would be helpful:
  1. start Hybrid
  2. set an default output path: Config->Paths->Default output path
       (This is where the debug output will be created unless you specify an output file inside another path.
       If an old HybridOutput.txt already exists in that folder delete it.)
  3. enable Debug output: Config->Internals->Create debug file (unless told to, do not change the debug level)
  4. do everything you did to create you problem
  5. compress (zip/7z/rar/..) the HybridDebugOutput.txt before you post it
Debug output in attached link.
[*]a small sample, which allows the reprocudtion of the problem would be nice
Sample file in attached link.

Overriding input scan type to bottom field first does not appear to help...

Perhaps I am losing my mind here but please help!

I can not seem to attach any files so I've attached everything as a ZIP at this Google Drive link: https://drive.google.com/file/d/1FYDTCbg...sp=sharing

Thanks for your time!
Reply
#2
Problem is probably that FFV1 does not specifically support interlaced content, iirc. FFV1 can save interlaced content while maintaining the interlaced structure, but everything is flagged as progressive.
-> I'll look into skipping that check for ffv1 after work today.

Side note: "disable de-interlacing" is probably the wrong approach, normally one would overwrite the scan type.

Cu Selur
Reply
#3
(19.04.2022, 07:27)Selur Wrote: Problem is probably that FFV1 does not specifically support interlaced content, iirc. FFV1 can save interlaced content while maintaining the interlaced structure, but everything is flagged as progressive.
-> I'll look into skipping that check for ffv1 after work today.

Side note: "disable de-interlacing" is probably the wrong approach, normally one would overwrite the scan type.

Cu Selur

Thanks for the fast reply as always! Sounds good. I wouldn't have an issue if there is a "support interlace on unsupported formats" checkbox or setting if that would be a good compromise.

Interesting to note FFV1 doesn't have interlaced content in it's specs. I've been using it with Hybrid for (literally) years with no issues playing back on programs like MPC-HC. Do you believe it's a bad format to use for lossless archival of interlaced content?

Also, thanks for the note regarding "disable de-interlacing." I figured I should disable it and let it follow the scan order defined in the input file. Is it better to define the scan order for a reason other than to ensure an input file with a bad header wouldn't be considered progressive?
Reply
#4
No, FFV1 isn't a bad archival format, it just doesn't differentiate between interlaced and progressive data.
The best way to fix this is for me to add a dummy selection to the FFV1 encoder which lets the user decide whether wants interlaced or progressive data to be saved.
Since this will influence how Hybrid does filtering.
If you don't do any filtering overwriting the input scan type to progressive should be fine too.

Cu Selur
Reply
#5
Send you a link to a dev version which allows to set Interlaced for FFV1, so if you want to output interlaced, make sure to enable it in the FFV1 settings.

Cu Selur
Reply
#6
Hi Selur,

I tried the 2022.04.19.1 release you sent me. It no longer shows the progressive popup, but it is still not working unfortunately.

If I load my video, and leave FFV1 as defaults (4:2:0, 8-bit), I get an "Illegal output resolution (720x486). Interlaced YUV420PX requires mod4 compatible height." error. I've been using these sources to create interlaced FFV1 files for ages so I'm not sure why I'm getting called out for a non mod4 resolution now.

If I change the output format to 4:2:2 10-bit as I usually do to match the source, I get no popup error but no job is created and no encoding is attempted. If I add audio encoding, Hybrid outputs a 75-ish KB file with a dummy header containing only audio information.

I've attached an updated zip here: https://drive.google.com/file/d/1tjTDaRD...N0LGwfrve/

Thanks again for your help & time.
Reply
#7
Quote:If I load my video, and leave FFV1 as defaults (4:2:0, 8-bit), I get an "Illegal output resolution (720x486). Interlaced YUV420PX requires mod4 compatible height." error. I've been using these sources to create interlaced FFV1 files for ages so I'm not sure why I'm getting called out for a non mod4 resolution now.
This is correct. YUV4:2:0 interlaced needs to be mod4. This did not happen before since you basically overwrote the input scan type to progressive, which is fine if you don't do any filtering.

Quote:If I change the output format to 4:2:2 10-bit as I usually do to match the source, I get no popup error but no job is created and no encoding is attempted.
My guess is that I broke something for the job creator by adding the interlaced workaround.
-> looking into it
Reply
#8
Found the issue made a typo which basically disabled all job generation for jobs where FFmpeg is used as decoder and encoder at the same time. Smile
-> compiling a new version will send you a new link in ~10min.

Cu Selur
Reply
#9
send pm with new link
going to bed now Smile
if it doesn't work I can look at it tomorrow after work

Cu Selur
Reply
#10
Hi Selur,

I've got good news! Your latest update works perfectly! The output is exactly what I expected. Hopefully this will let you sleep a bit more peacefully tonight. Smile

Thanks again for your help & incredibly fast solution to this matter!

(19.04.2022, 21:02)Selur Wrote:
Quote:If I load my video, and leave FFV1 as defaults (4:2:0, 8-bit), I get an "Illegal output resolution (720x486). Interlaced YUV420PX requires mod4 compatible height." error. I've been using these sources to create interlaced FFV1 files for ages so I'm not sure why I'm getting called out for a non mod4 resolution now.
This is correct. YUV4:2:0 interlaced needs to be mod4. This did not happen before since you basically overwrote the input scan type to progressive, which is fine if you don't do any filtering.

Ah, that makes sense thinking about subsampling... I guess that's why DVD is 720x480 instead of 486!
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)