#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 |
Description
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.
Attachments (1)
Change History (15)
comment:1 Changed 4 years ago by cehoyos
comment:2 Changed 4 years ago by Detergent
Yes it is, using ffmpeg version N-74514-gfffae8e
comment:3 Changed 4 years ago by 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.
comment:4 Changed 4 years ago by 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
comment:5 Changed 4 years ago by 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?
comment:6 Changed 4 years ago by cehoyos
- Keywords pullup added; ivtc removed
- Version changed from 2.7 to git-master
comment:7 Changed 4 years ago by 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.
comment:8 Changed 4 years ago by 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).
comment:9 Changed 4 years ago by 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.
comment:10 Changed 4 years ago by cehoyos
- Resolution set to invalid
- Status changed from new to closed
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
comment:11 Changed 4 years ago by Detergent
- Resolution invalid deleted
- Status changed from closed to reopened
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.
comment:12 Changed 4 years ago by Detergent
- Resolution set to invalid
- Status changed from reopened to closed
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.
comment:13 Changed 4 years ago by 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.
comment:14 Changed 4 years ago by 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 !
Is the issue reproducible with current FFmpeg git head?