Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4785 closed defect (invalid)

Decimate filter doesn't work when used directly with fieldmatch

Reported by: Detergent Owned by:
Priority: normal Component: avfilter
Version: git-master Keywords: fieldmatch decimate pullup
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no



For a lot of telecined inputs, using '-vf fieldmatch,decimate' will not work and the result will have too many dropped frames that will result in accelerated playback (leading to audio desync).

Now, the weird part is the following. This will not work :

ffmpeg -i input.1080i.ts -vf fieldmatch,decimate -vcodec libx264 out.mkv

However, this command will work flawlessly :

ffmpeg -i input.1080i.ts -vf fieldmatch -f yuv4mpegpipe - | ffmpeg -i - -vf decimate -vcodec libx264 out.mkv

You can download a telecined sample that will reproduce the problem using the above commands here :

I am using FFmpeg 2.7.2 and used MPC-HC 1.7.9 to play the outputs.

Attachments (1)

output.txt (4.0 KB ) - added by Detergent 7 years ago.
ffmpeg log

Download all attachments as: .zip

Change History (15)

comment:1 by Carl Eugen Hoyos, 7 years ago

Is the issue reproducible with current FFmpeg git head?

comment:2 by Detergent, 7 years ago

Yes it is, using ffmpeg version N-74514-gfffae8e

comment:3 by Carl Eugen Hoyos, 7 years ago

Please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

comment:4 by Detergent, 7 years ago

The command is the one described in the ticket :

ffmpeg -i sample.ts -vf fieldmatch,decimate -vcodec libx264 out.mkv

The complete log is available here :

You can also download the output file here :

by Detergent, 7 years ago

Attachment: output.txt added

ffmpeg log

comment:5 by Carl Eugen Hoyos, 7 years ago

Where does the input file come from?
It indicates that it was created with FFmpeg, is the issue also reproducible with the original stream?

comment:6 by Carl Eugen Hoyos, 7 years ago

Keywords: pullup added; ivtc removed
Version: 2.7git-master

comment:7 by Detergent, 7 years ago

The original file comes from a TV cap I did (HBO US). The sample was derived from it with FFmpeg using stream copy. The problem also exists with the original stream, yes.

comment:8 by Carl Eugen Hoyos, 7 years ago

I don't know if it makes a difference for this ticket but please understand that in the general case the original stream - cut with dd - is needed, not a file created with FFmpeg (that has difficulties creating valid transport streams).

comment:9 by Detergent, 7 years ago

In this particular case, FFmpeg reacts the same way whether it's on the original file or the sample.
It's not an important matter as there is a workaround (see the second command in the ticket, it works on both the original and the sample), but there is definitely something wrong with how decimate (or something else) operates when used in the same process as the other filters.

comment:10 by Carl Eugen Hoyos, 7 years ago

Resolution: invalid
Status: newclosed

The sample you uploaded has progressive content, it cannot be processed by an inverse telecine filter.

$ ffmpeg -i sample.ts -vf idet -an -f null -
ffmpeg version N-74483-gb807f7e Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      54. 30.100 / 54. 30.100
  libavcodec     56. 57.100 / 56. 57.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 34.100 /  5. 34.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mpegts, from 'sample.ts':
  Duration: 00:00:20.59, start: 1.400000, bitrate: 13685 kb/s
  Program 1
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, max. 38800 kb/s, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x101](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
Output #0, null, to 'pipe:':
    encoder         : Lavf56.40.101
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
      encoder         : Lavc56.57.100 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> rawvideo (native))
Press [q] to stop, [?] for help
[null @ 0x3767540] Encoder did not produce proper pts, making some up.
frame=  464 fps=380 q=-0.0 Lsize=N/A time=00:00:19.28 bitrate=N/A
video:44kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_idet_0 @ 0x3769a40] Repeated Fields: Neither:   462 Top:     1 Bottom:     1
[Parsed_idet_0 @ 0x3769a40] Single frame detection: TFF:     0 BFF:     8 Progressive:   363 Undetermined:    93
[Parsed_idet_0 @ 0x3769a40] Multi frame detection: TFF:     0 BFF:     4 Progressive:   460 Undetermined:     0

comment:11 by Detergent, 7 years ago

Resolution: invalid
Status: closedreopened

Look, using the following :

ffmpeg -i sample.ts -vf fieldmatch -vcodec libx264 out.mkv

generates a 29.97 fps output which has one frame duplicate every 5 frames, which is exactly what you'd expect from fieldmatching a telecined content.

So, so far so good, all we need to do is drop those duplicate frames with a cycle of 5. That is what the decimate filter should do, but when used directly, it seems to drop more frames than is necessary.

Except when you use it like this, then it works perfectly and generates an excellent 23.976 progressive detelecined content :

ffmpeg -i sample.ts -vf fieldmatch -f yuv4mpegpipe - | ffmpeg -i - -vf decimate -vcodec libx264 out.mkv

Because somehow, dropping all the metadata and timestamps and feeding raw cfr frames to the decimate filter seems to work much better.

Last edited 7 years ago by Detergent (previous) (diff)

comment:12 by Detergent, 7 years ago

Resolution: invalid
Status: reopenedclosed

Ah well, nevermind. It indeed isn't telecined, it's progressive. But, there is still one frame duplicate every 5 frames and the decimate filter should be able to handle that, shouldn't it ?

For now I'll keep using the following command :

ffmpeg -i sample.ts -f yuv4mpegpipe - | ffmpeg -i - -vf decimate -vcodec libx264 out.mkv

As it produces excellent result.

Last edited 7 years ago by Detergent (previous) (diff)

comment:13 by Carl Eugen Hoyos, 7 years ago

fieldmatch does not work the way you expect it to work, it never duplicates frames. You can use the following filterchain to do what you want, ~unfortunately, decimate sometimes drops the wrong frame~:
-vf fps=30000/1001,fieldmatch,decimate
It works fine for a clean, bright sample that is either telecined or 24000/1001 progressive like the one you uploaded.

The reason it seems to fail for the sample in is that parts of the input have a framerate of ~20fps afaict: The cfr output video has to contains duplicate frames.

Last edited 7 years ago by Carl Eugen Hoyos (previous) (diff)

comment:14 by Detergent, 7 years ago

Ohh I see, so those duplicate frames were added by ffmpeg to match a 29.97 fps cfr output..

Thanks a lot for your time, I understand much better what happens now !

Note: See TracTickets for help on using tickets.