Interlacement information is not passed from the lavfi demuxer to the rawvideo decoder

[dave rice]

Summary of the bug:

The values for frame:interlaced_frames and frame:top_field_frame always seem to be set to zero.

If I generate a test file that is TFF via

ffmpeg -y -f lavfi -i mandelbrot -target ntsc-dv -t 0.5 -vf setfield=tff tff.mov
ffmpeg version git-2014-10-25-80b29c2 Copyright (c) 2000-2014 the FFmpeg developers
  built on Oct 25 2014 11:44:58 with Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-libass --enable-ffplay --enable-libopenjpeg --disable-decoder=jpeg2000 --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      54. 11.100 / 54. 11.100
  libavcodec     56.  9.100 / 56.  9.100
  libavformat    56. 10.100 / 56. 10.100
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  2.100 /  5.  2.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, lavfi, from 'mandelbrot':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGBA / 0x41424752), rgba, 640x480 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, dv, to 'tff.mov':
  Metadata:
    encoder         : Lavf56.10.100
    Stream #0:0: Video: dvvideo, yuv411p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc56.9.100 dvvideo
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> dvvideo (native))
Press [q] to stop, [?] for help
frame=   15 fps=0.0 q=0.0 Lsize=    1758kB time=00:00:00.50 bitrate=28771.2kbits/s dup=2 drop=0    
video:1758kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

then mediainfo and ffmbc report the file as TFF, but in ffprobe all top_field_first equals 0.

ffprobe -f lavfi "movie=tff.mov" -show_entries frame=top_field_first,interlaced_frame
ffprobe version git-2014-10-25-80b29c2 Copyright (c) 2007-2014 the FFmpeg developers
  built on Oct 25 2014 11:44:58 with Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-libass --enable-ffplay --enable-libopenjpeg --disable-decoder=jpeg2000 --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      54. 11.100 / 54. 11.100
  libavcodec     56.  9.100 / 56.  9.100
  libavformat    56. 10.100 / 56. 10.100
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  2.100 /  5.  2.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
[dv @ 0x7fafd181a200] Estimating duration from bitrate, this may be inaccurate
Input #0, lavfi, from 'movie=tff.mov':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (Y41B / 0x42313459), yuv411p, 720x480 [SAR 1:1 DAR 3:2], 29.97 tbr, 29.97 tbn, 29.97 tbc
[FRAME]
interlaced_frame=0
top_field_first=0
[/FRAME]
[FRAME]
interlaced_frame=0
top_field_first=0
[/FRAME]
[ ... ]
[FRAME]
interlaced_frame=0
top_field_first=0
[/FRAME]

Note that I'm not looking for information from idet on what the interlacement or scan order 'looks' like but I am hoping to use top_field_first and interlaced_frame to decipher whether the codec or container reports the frame as. I tested a number of files and have not been able to ever get a 1 for top_field_first or interlaced_frame over a variety of codecs.

[Carl Eugen Hoyos]

Is there a reason why you didn't test the following?

$ ffprobe tff.mov -show_entries frame=top_field_first,interlaced_frame

I agree that there may be a bug but don't you agree that it is almost certainly not related to ffprobe?

[dave rice]

Ah, you're right:

ffprobe tff.mov -show_entries frame=top_field_first,interlaced_frame
ffprobe version git-2014-10-25-80b29c2 Copyright (c) 2007-2014 the FFmpeg developers
  built on Oct 25 2014 11:44:58 with Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-libass --enable-ffplay --enable-libopenjpeg --disable-decoder=jpeg2000 --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '
  libavutil      54. 11.100 / 54. 11.100
  libavcodec     56.  9.100 / 56.  9.100
  libavformat    56. 10.100 / 56. 10.100
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  2.100 /  5.  2.100
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
[dv @ 0x7f8a0b80da00] Estimating duration from bitrate, this may be inaccurate
Input #0, dv, from 'tff.mov':
  Metadata:
    timecode        : 00:00:00:00
  Duration: 00:00:00.50, start: 0.000000, bitrate: 28771 kb/s
    Stream #0:0: Video: dvvideo, yuv411p, 720x480 [SAR 8:9 DAR 4:3], 28771 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
[FRAME]
interlaced_frame=1
top_field_first=1
[/FRAME]
[FRAME]
interlaced_frame=1
top_field_first=1
[/FRAME]

So perhaps this means that the interlacement metadata is not passing through the movie filter. The reason I was using the movie filter is that I was hoping to generate one command to gather both info from idet about interlacement as well as info about what the codec/container says about interlacement to identify conflicts.

[Carl Eugen Hoyos]

Replying to dericed:

So perhaps this means that the interlacement metadata is not passing through the movie filter.

That was my guess but I don't know much about the internals of this filter.

The reason I was using the movie filter is that I was hoping to generate one command to gather both info from idet about interlacement as well as info about what the codec/container says about interlacement to identify conflicts.

Thank you for explaining this!