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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
