[FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video

[Aaron Levinson]

On 3/26/2017 10:34 AM, Aaron Levinson wrote:
> On 3/26/2017 4:41 AM, Matthias Hunstock wrote:
>> Am 26.03.2017 um 11:50 schrieb Aaron Levinson:
>>> When using the following command to play back either file:
>>>  ffmpeg -i <mpegts file> -f decklink -pix_fmt uyvy422 "DeckLink SDI
>>>  4K", I noticed that with the mpegts file with the AAC audio stream,
>>>  it would correctly select an interlaced video mode for the video
>>>  output stream, but with the mpegts file with the Opus audio stream,
>>>  it would use a progressive video mode (1080p29.97) for the video
>>>  output stream.
>>
>> Which FFmpeg version did you test this with?
>>
>> There was a change related to this just short time ago.
>>
>> Does it happen with current git HEAD?
>>
>> Matthias
> 
> This issue occurs with the current git HEAD.  I'm aware of the
> Blackmagic improvement that was added in February to add support for
> interlaced video modes on output, and actually that's one of the reasons
> why I'm using the latest git sources, as opposed to, say, 3.2.4.  This
> particular issue has nothing to do with Blackmagic, and I only used
> Blackmagic in the example that reproduces the bug because it is
> something that can be reproduced on both Windows and Linux (and
> presumably also on OS/X).  The issue also occurs if I do something like
> -f rawvideo out.avi on Windows, and I'm sure that there are plenty of
> other examples.
> 
> Aaron Levinson

Has anyone had a chance to review this patch yet, which I submitted on March 26th?  To demonstrate the impact of this patch, here's some output of before and after for an .h264 file with interlaced 1080i59.94 video content:

Command-line:  ffmpeg -i test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts

Before patch:

--------------------------------------

Input #0, h264, from 'test8_1080i.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
  Metadata:
    encoder         : Lavf57.72.100
    Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.92.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1

--------------------------------------

After patch:

--------------------------------------

Input #0, h264, from 'test8_1080i.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native))
Press [q] to stop, [?] for help
Output #0, mpegts, to 'test8_1080i_mp2_2.ts':
  Metadata:
    encoder         : Lavf57.72.100
    Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.92.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1

--------------------------------------

As can be seen, before the patch, after decoding the .h264 file and then re-encoding it as mpeg2video in an mpegts container, the interlaced aspect of the video has been lost in the output, and it is now effectively 1080p29.97, although the video hasn't actually been converted to progressive.  ffmpeg simply thinks that the video is progressive when it is not.  With the patch, the interlaced aspect is not lost and propagates to the output.  So, this conclusively demonstrates that the issue has nothing to do with Blackmagic and is a more general issue with interlaced video and decoding.

I can make the input file available if that would be helpful.

Anyway, it would be great if this bug fix could make it into ffmpeg.

Thanks,
Aaron Levinson