[FFmpeg-user] handling interlaced video in a progressive sequence

[Anton Kapela]

List folk,

I've been working around a strange encoder and stream source problem;
would like to ask folks if I'm "doing it right" in trying to
so-compensate for this source problem.

In short, an h264 and mjpeg source encoder (RTP or TS) is sending me
frames coming from a 1080i29.97 "broadcast switching" system. Using
the h264 sequence, the PPS/SPS claims the colorspace and type to be
yuv420, and explicitly is "progressive."  Using the RTSP side, we see
that it's sending a properly setup SDP for the rtpmap/AVP via
RTSP/RTP, but of course doesn't tell us if it's interlaced or
progressive.

Regardless of the transport to us, this encoder sends frames
containing interlaced motion fields, and simply claims they're
progressive. Let's add one more wrench: the encoder claims it's
actually sending '30 fps' despite the frame during and timestamps
clearly having been sampled on a drop-frame 30000/1001 interval. Oops!

So here's what I'm doing now:

while :; do ffmpeg -fflags +discardcorrupt -vsync 1 -ec 3
-thread_queue_size 8192 -i http://encoder.source.etc:1234/0.ts -vf
format=yuv444p,fps=fps=30000/1001,fps=fps=60000/1001,tinterlace=interleave_top,fieldorder=tff,format=yuv420p
-c:a copy -c:v libx264 -x264opts interlaced=1:tff=1 -dc 10 -flags
+ildct+ilme -g 90 -preset medium -b:v 3.3M -maxrate:v 3.6M -bufsize
12M -weightp 0 -refs 3 -bf 2 -subq 10 -mixed-refs 1 -8x8dct 1
-partitions all -direct-pred auto -nal-hrd vbr -aq-mode autovariance
-aq-strength .7 -me_range 511 -trellis 2 -map_metadata -1
-map_chapters -1 -f mpegts -muxpreload 2 tcp://dest.host.etc:2345 ;
sleep 1 ; done

Take out the "fps=fps=30000/1001" and we eventually seem to 'slip'
which frames are getting used for top or bottom field by the rest of
the vf pipe. For a while, ffmpeg is reading frames at a claimed rate
of 30 fps, while they only arrive at an actual rate of 30000/1001; it
duplicates them (fps=fps=60000/1001), and then applies tinterleave.
Given the input underrun that will happen shortly after starting up,
this is "ok" only for a while. Eventually (10's of seconds in), we
slip - and the dup'd frame pair  is now stradling the wrong input
frame going to tinterleave. Eventually we slip again, and land back on
a correct top/bot frame pair duplicate set, and everything is good
again. This will oscillate indefinitely, and obviously looks visually
terrible.

Put in the drop-frame 30 fps declaration ahead of the drop-60
duplication step, and we stay sync'd indefinitely. Nice!

Questions:

a) is this workaround "ok" - and is there something else one ought to
do in this case? (ie. is there a non-duplication method to telling
x264 to "no, really, order these scanlines into the top field, and do
MBAFF on that" -- ie. force decoding "as if it were interlaced" even
though the PPS/SPS lied to us)

b) why does FFMPEG seem to care about the PPS/SPS claimed frame rate?
(ie. i could be handling 50i content all-of-a-sudden, and my whole
pipe will break it, since the duplication isn't a function like
'fps*2,' but is declared instead)

Best,

-Tk