FFmpeg video stream interlaced, container progressive, why?

[Selur]

Hi,
I use the following calls.

• extracting audio:
  

  ffmpeg -y -threads 8 -i "C:\Users\Selur\Desktop\HuffInterlaced.avi" -map 0:1 -vn -sn -ac 2 -ar 96000 -acodec pcm_s16le -f wav -map_metadata -1 -metadata encoding_tool="Hybrid 2023.12.23.1" "J:\tmp\iId_1_aid_1_2023-12-23@07_12_29_4610_01.wav"

• reencoding video:
  

  ffmpeg -y -noautorotate -nostdin -threads 8 -i "C:\Users\Selur\Desktop\HuffInterlaced.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv,setfield=tff -pix_fmt yuv444p -vsync 0 -top 1 -vcodec ffvhuff -coder 0 -context 0 -non_deterministic true -flags +ildct+ilme -top 1 -metadata encoding_tool="Hybrid 2023.12.23.1" "J:\tmp\HuffInterlaced_new_1_2023-12-23@07_12_29_4610_02.avi"

  Video (stream&container) is properly flagged as interlaced.
• muxing audio&video:
  

  ffmpeg -y  -r 30000/1001 -fflags +genpts -i "J:\tmp\HuffInterlaced_new_1_2023-12-23@07_12_29_4610_02.avi" -top 1 -flags +ildct+ilme -i "J:\tmp\iId_1_aid_1_2023-12-23@07_12_29_4610_01.wav" -metadata encoding_tool="Hybrid 2023.12.23.1" -c:0 copy -c:1 copy -map 0:0  -map 1:0  -aspect 720:480 -r 30000/1001 -f avi "G:\Output\HuffInterlaced_new.avi"

  Video container is flagged as progressive, video stream is flagged as interlaced.

My problem is that after the muxing call the container is flagged as progressive, video stream is flagged as interlaced.
I want both to be flagged interlaced, does someone know how to fix the muxing call (without having to reencode the video)?
(the calls need to be separate, so doing all the above in one call is no solution for me)

Cu Selur

[ProWo]

Retry muxing without

-f avi

[Selur]

Sadly, without '-f avi' I still get:

Scan type                                : Progressive
Original scan type                       : Interlaced

Cu Selur

[ivanb]

FFMPEG AVI muxer writes number of fields based on par->field_order value. But this field is never set when we copy ffvhuff video, so the muxer just uses the default (progressive) here.

I can be mistaken, but it looks like your problem can't be solved without patching of FFMPEG

[Selur]

No problem, I'll create an issue tracker entry for ffmpeg after the holidays until someone comes up with another solution.

Cu Selur

[ivanb]

Since HuffYUV is a lossless codec, additional decoding/encoding should not make the picture worse. So if processing time is not that critical, you can just use -c:0 ffvhuff in your "muxing" step (or eliminate "re-encode video" step at all)

[Selur]

Thanks.
Yeah, that would be a workaround for the broken .avi muxing support in ffmpeg.
Just using '-c:0 ffvhuff' is not enough, otherwise the default coder and context would be used. When muxing a huffuv videostream and an audiostream you always need to reencode if the huffyuv stream is interlaced.
=> any idea how to identify which coder and context was used? :/

Reencoding is needed since it's usually also includes Vapoursynth&co, I just simplified the whole process here to show the problem more easily.

Cu Selur

Ps.: I created an entry in the ffmpeg bug tracker: https://trac.ffmpeg.org/ticket/10761

[dannyboy48888]

On encode you got to do -vf setfield=tff or bff. Otherwise the actual video will be encoded as interlaced but the container won't have any flag and default to progressive or worse the wrong field order.

[Selur]

Setting "-flags +ildct+ilme -top 1" should be enought, but I'll give it a try.

[Selur]

Like I thought, even when adding "-vf setfield=tff" and using:

ffmpeg -y -noautorotate -nostdin -threads 8 -i "C:\Users\Selur\Desktop\HuffInterlaced.avi" -map 0:0 -an -sn -vf setfield=tff,zscale=rangein=tv:range=tv,setfield=tff -pix_fmt yuv444p -vsync 0 -top 1 -vcodec ffvhuff -coder 0 -context 0 -non_deterministic true -flags +ildct+ilme -top 1 -metadata encoding_tool="Hybrid 2023.12.23.1" "J:\tmp\HuffInterlaced_new_1_2023-12-23@07_12_29_4610_02.avi"

after the remux the output is still:

Scan type                                : Progressive
Original scan type                       : Interlaced

Cu Selur