[FFmpeg-user] Unexpected results from the "idet" filter

Tim Nicholson nichot20 at yahoo.com
Fri Apr 20 16:31:27 CEST 2012


I have been having a play around with the idet filter and come across
some unexpected results.

In summary it seems to work well *provided* that the source stream can
be interpreted without any auto insertion of a scale 0 filter to change
the pix_fmt. For example:-

===================================================================
ffmpeg -i AVCiHD-short-mute.mov -an -vf idet -c:v rawvideo -an -y -f
rawvideo /dev/null
ffmpeg version N-39947-gd833fea-by_Tim Copyright (c) 2000-2012 the
FFmpeg developers
  built on Apr 20 2012 09:49:58 with gcc 4.6.2
  configuration: --extra-version=by_Tim --enable-static --disable-shared
--enable-gpl --enable-nonfree --enable-version3
--prefix=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local
--libdir=/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64
--samples=../fate-suite/ --enable-runtime-cpudetect
--extra-cflags='-static
-I/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/include'
--extra-ldflags='-static
-L/mnt/msds-store-0/tim/ffmpeg-tux/usr/local/lib64'
--progs-suffix=_Apr-20 --enable-libfaac --enable-libx264
--enable-libfreetype --disable-ffplay
  libavutil      51. 46.100 / 51. 46.100
  libavcodec     54. 14.101 / 54. 14.101
  libavformat    54.  3.100 / 54.  3.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 70.100 /  2. 70.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'AVCiHD-short-mute.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 512
    compatible_brands: qt
    encoder         : Lavf54.3.100
  Duration: 00:00:03.00, start: 0.000000, bitrate: 113667 kb/s
    Stream #0:0(eng): Video: h264 (High 4:2:2 Intra) (avc1 /
0x31637661), yuv422p10le, 1920x1080 [SAR 1:1 DAR 16:9], 113664 kb/s, 25
fps, 25 tbr, 25 tbn, 50 tbc
    Metadata:
      handler_name    : DataHandler
[buffer @ 0x17d0320] w:1920 h:1080 pixfmt:yuv422p10le tb:1/1000000
sar:1/1 sws_param:flags=2
[buffersink @ 0x17d0840] No opaque field provided
Output #0, rawvideo, to '/dev/null':



  Metadata:
    major_brand     : qt
    minor_version   : 512
    compatible_brands: qt
    encoder         : Lavf54.3.100
    Stream #0:0(eng): Video: rawvideo (Y3[10][10] / 0xA0A3359),
yuv422p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc
    Metadata:
      handler_name    : DataHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> rawvideo)
Press [q] to stop, [?] for help
AV Filter told us it has a frame available but failed to output one
0.0kbits/s
frame=   74 fps= 10 q=0.0 Lsize=       0kB time=00:00:02.96 bitrate=
0.0kbits/s


video:599400kB audio:0kB global headers:0kB muxing overhead -100.000000%
[idet @ 0x17d10a0] Single frame detection: TFF:32 BFF:0 Progressive:0
Undetermined:42
[idet @ 0x17d10a0] Multi frame detection: TFF:58 BFF:0 Progressive:0
Undetermined:16

===================================================================

But when a scale filter is auto inserted:-

===================================================================
ffmpeg -i AVCiHD-short-mute.mov -an -vf idet -c:v rawvideo -pix_fmt
yuv420p -an -y -f rawvideo /dev/null
ffmpeg version N-39947-gd833fea-by_Tim Copyright (c) 2000-2012 the
FFmpeg developers

[...]

[buffer @ 0x17dbe40] w:1920 h:1080 pixfmt:yuv422p10le tb:1/1000000
sar:1/1 sws_param:flags=2
[idet @ 0x17d1140] auto-inserting filter 'auto-inserted scale 0' between
the filter 'src' and the filter 'Parsed_idet_0'
[scale @ 0x17d1e00] w:1920 h:1080 fmt:yuv422p10le sar:1/1 -> w:1920
h:1080 fmt:yuv420p sar:1/1 flags:0x4

[...]



video:224775kB audio:0kB global headers:0kB muxing overhead -100.000000%
[idet @ 0x17d1140] Single frame detection: TFF:0 BFF:0 Progressive:0
Undetermined:74
[idet @ 0x17d1140] Multi frame detection: TFF:0 BFF:0 Progressive:0
Undetermined:74
=====================================================================

Also the pix_fmt type seems to affect the detection accuracy, the same
source material converted to DV:-

===================================================================
ffmpeg -i DV-short.mov -an -vf idet -c:v rawvideo -an -y -f rawvideo
/dev/null
ffmpeg version N-39947-gd833fea-by_Tim Copyright (c) 2000-2012 the
FFmpeg developers
  built on Apr 20 2012 09:49:58 with gcc 4.6.2

[...]

    Stream #0:0(eng): Video: dvvideo (dvcp / 0x70637664), yuv420p,
720x576 [SAR 64:45 DAR 16:9], 28800 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc

[...]



video:44955kB audio:0kB global headers:0kB muxing overhead -100.000000%
[idet @ 0x17d0d60] Single frame detection: TFF:68 BFF:0 Progressive:0
Undetermined:6
[idet @ 0x17d0d60] Multi frame detection: TFF:73 BFF:0 Progressive:0
Undetermined:1
===================================================================

Note the improved detection.

Also whilst down coverting the pix_fmt seems to completely nobble the
filter, up converting only slightly impairs its performance:-

===================================================================
ffmpeg -i DV-short.mov -an -vf idet -c:v rawvideo -pix_fmt yuv422p -an
-y -f rawvideo /dev/null
ffmpeg version N-39947-gd833fea-by_Tim Copyright (c) 2000-2012 the
FFmpeg developers

[...]


[buffer @ 0x17db580] w:720 h:576 pixfmt:yuv420p tb:1/1000000 sar:64/45
sws_param:flags=2
[idet @ 0x17d0ea0] auto-inserting filter 'auto-inserted scale 0' between
the filter 'src' and the filter 'Parsed_idet_0'
[scale @ 0x17d1b60] w:720 h:576 fmt:yuv420p sar:64/45 -> w:720 h:576
fmt:yuv422p sar:64/45 flags:0x4

[...]



video:59940kB audio:0kB global headers:0kB muxing overhead -100.000000%
[idet @ 0x17d0ea0] Single frame detection: TFF:47 BFF:0 Progressive:0
Undetermined:27
[idet @ 0x17d0ea0] Multi frame detection: TFF:58 BFF:0 Progressive:0
Undetermined:16
===================================================================

I do not know if these figures indicate a limitation of the idet filter,
or the way that pix_fmt conversion is applied. Interestingly replacing
the auto inserted filters with a manual "scale=0:0:interl=1" to force
the scaler into interlace mode makes no difference to the results....

-- 
Tim


More information about the ffmpeg-user mailing list