Decimate filter doesn't work when used directly with fieldmatch

[Detergent]

Hello,

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 : ​https://drive.google.com/file/d/0Bz_fz7x43dCZT2tvZi1kZXJ0TUk/view?usp=sharing

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

[cehoyos]

Is the issue reproducible with current FFmpeg git head?

[Detergent]

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

[cehoyos]

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

[Detergent]

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 : ​http://pastebin.com/c4gKHDkU

You can also download the output file here : ​https://drive.google.com/file/d/0Bz_fz7x43dCZSmFDenpJd2VvdlU/view?usp=sharing

[Detergent]

ffmpeg log

[cehoyos]

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

[Detergent]

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.

[cehoyos]

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).

[Detergent]

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.

[cehoyos]

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
    Metadata:
      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:':
  Metadata:
    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
    Metadata:
      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

[Detergent]

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.

[Detergent]

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.

[cehoyos]

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 like the one you uploaded afaict.

[Detergent]

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 !