Opened 11 months ago

Last modified 3 weeks ago

#6971 new defect

ffmpeg drops frames after deinterlacing

Reported by: CaryKnoop Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: cuvid
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

NVIDIA's encoder supports deinterlacing. This optionally includes deinterlacing with frame doubling. In case frame doubling is wanted the NVIDIA decoder correctly doubles the frames, however ffmpeg does not pass this on to the encoder but instead drops all doubled frames.

Regardless of the NVIDIA cuvid parameter settings -deint (1, 2) and -drop_second_field (0, 1) frames get dropped by ffmpeg.

How to reproduce:

For full hardware decoding and encoding:
% ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -deint 2 -drop_second_field 0 -i <interlaced mpeg-2 file> -c:v h264_nvenc -b:v 80M -profile:v high -preset slow <out file>

Or for hardware decoding and encoding but passing the intermediate results to system buffers:
% ffmpeg  -c:v mpeg2_cuvid -deint 2 -drop_second_field 0 -i <interlaced mpeg-2 file>  -c:v h264_nvenc -b:v 80M -profile:v high -preset slow <out file>

ffmpeg version N-89825-g1b5d3c08e3 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libmfx --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
  libavutil      56.  7.100 / 56.  7.100
  libavcodec     58.  9.100 / 58.  9.100
  libavformat    58.  5.100 / 58.  5.100
  libavdevice    58.  0.100 / 58.  0.100
  libavfilter     7. 11.101 /  7. 11.101
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100

CUDA library: 9,1
NVIDIA Driver: 388.19

Change History (30)

comment:1 Changed 11 months ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords cuvid added
  • Version changed from 3.4 to git-master

Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

comment:2 follow-up: Changed 11 months ago by CaryKnoop

Full command line with console output:

ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -deint 2 -drop_second_field 0 -i touched.demuxed.m2v -c:v h264_nvenc -b:v 80M -profile:v high -preset slow out1.mp4
ffmpeg version N-89825-g1b5d3c08e3 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libmfx --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth
  libavutil      56.  7.100 / 56.  7.100
  libavcodec     58.  9.100 / 58.  9.100
  libavformat    58.  5.100 / 58.  5.100
  libavdevice    58.  0.100 / 58.  0.100
  libavfilter     7. 11.101 /  7. 11.101
  libswscale      5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
  libpostproc    55.  0.100 / 55.  0.100
Input #0, mpegvideo, from 'touched.demuxed.m2v':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, smpte170m, top first), 720x480 [SAR 8:9 DAR 4:3], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (mpeg2_cuvid) -> h264 (h264_nvenc))
Press [q] to stop, [?] for help
Output #0, mp4, to 'out1.mp4':
  Metadata:
    encoder         : Lavf58.5.100
    Stream #0:0: Video: h264 (h264_nvenc) (High) (avc1 / 0x31637661), cuda, 720x480 [SAR 8:9 DAR 4:3], q=-1--1, 80000 kb/s, 29.97 fps, 30k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc58.9.100 h264_nvenc
    Side data:
      cpb: bitrate max/min/avg: 0/0/80000000 buffer size: 160000000 vbv_delay: -1
Past duration 0.999992 too large
frame= 4362 fps=1068 q=12.0 Lsize=  122530kB time=00:02:25.51 bitrate=6898.1kbits/s dup=18 drop=4338 speed=35.6x
video:122510kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.015960%

comment:3 in reply to: ↑ 2 Changed 11 months ago by cehoyos

Replying to CaryKnoop:

frame= 4362 fps=1068 q=12.0 Lsize=  122530kB time=00:02:25.51 bitrate=6898.1kbits/s dup=18 drop=4338 speed=35.6x

Possible work-around is to specify -r 60000/1001 as output frame rate.

comment:4 Changed 2 months ago by malakudi

Setting output frame rate with -r works till ffmpeg version 3.3.x
It doesn't work with versions from 3.4.0 till latest git.

So is this a bug in output framerate setting? What changed since 3.4.0 about this?

comment:5 Changed 2 months ago by malakudi

  • Keywords deinterlace framerate added

comment:6 Changed 2 months ago by cehoyos

  • Keywords deinterlace framerate removed

comment:7 Changed 2 months ago by malakudi

I have traced the commit that triggers the problem.
It is this one: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/bddb2343b6e594e312dadb5d21b408702929ae04

* commit '061a0c14bb5767bca72e3a7227ca400de439ba09':
  decode: restructure the core decoding code

CUVID decoder adapted by wm4.

It is difficult with my understanding on the code to find which part of the commit is in fault. Hope a dev can look at it.

comment:8 Changed 8 weeks ago by malakudi

Is it possible to review this by a developer? Maybe "wm4" that did the CUVID decoder adaptation on the new core decoding code?

comment:9 Changed 8 weeks ago by oromit

./ffmpeg -r 50 -c:v mpeg2_cuvid -deint adaptive -i ~/00001.ts -sn -an -qp 22 -c:v h264_nvenc -y out.mkv

Works fine for me on release/3.4, release/4.0 and master.

Note the -r 50 as input option, for the file which is originally 25 fps. You need to manually specify that, as ffmpeg.c is not up to the challenge of changing the fps from inside of a decoder.

comment:10 Changed 7 weeks ago by ferrys

everything works fine, -r 50 , but you have to choose proper H264 profile - for 1080p -high 4.2 ... so no bugs are there...

Last edited 7 weeks ago by ferrys (previous) (diff)

comment:11 Changed 6 weeks ago by malakudi

@oromit: -r 50 on input works (I have found this also myself) BUT, at least in my case, output has audio/video sync issues when I use -r 50 in input. -r 50 as output used to work but not after the above mentioned commit. I still use ffmpeg 3.3.8 with -r 50 as output and works fine. -r 50 AFTER above commit does nothing - same result as if it wasn't used.

Are you sure you don't have audio/video sync issues with -r 50 as input flag?

comment:12 Changed 6 weeks ago by malakudi

Just tried again, output is more than 3-4 seconds async when I use -r 50 as input.

comment:13 Changed 6 weeks ago by malakudi

I did some more tests and if input starts correctly from keyframe, then using -r 50 as input flag I don't have issues. However, my user case is transcoding live multicast mpegts streams or http unicast mpegts streams that I cannot guarantee they start at keyframe. When that is the case, -r 50 produces async output.
Why we can't make it to work with -r 50 at output as it does work BEFORE the above mentioned commit?

Last edited 6 weeks ago by malakudi (previous) (diff)

comment:14 follow-up: Changed 4 weeks ago by malakudi

After further testing, -r 50 on input works fine if input is a correct encoded file, starting from keyframe etc etc. If input is a live stream (http or udp multicast), even if it starts at keyframe, with -r 50 as input any input error will immediately result in audio/video sync error. -r 50 on input completely breaks the audio/video sync mechanism on input (I guess because it kind of breaks timestamps). So it is not a good solution, it works for some workloads (file transcoding) but not for live transcoding. -r 50 on output works fine on 3.3.8. How can I help to make -r 50 on output work again? Any hint to look at the code?

comment:15 follow-up: Changed 4 weeks ago by malakudi

In case any dev is following this, I made some progress finding the root cause of the issue. -r 50 on output does not always make ffmpeg to drop frames with cuvid's deint adaptive enabled. It does drop frames if original input is encoded as MBAFF. If original input is encoded as PAFF, then -r 50 on output does NOT drop frames and works as expected.
Hope this helps. I can provide two sample files if needed, one that drops frames on output and one that doesn't.

Last edited 4 weeks ago by malakudi (previous) (diff)

comment:16 in reply to: ↑ 14 ; follow-up: Changed 4 weeks ago by cehoyos

Replying to malakudi:

After further testing, -r 50 on input works fine if input is a correct encoded file, starting from keyframe etc etc.

If input is a live stream (http or udp multicast), even if it starts at keyframe, with -r 50 as input any input error will immediately result in audio/video sync error.

This is expected.

comment:17 in reply to: ↑ 15 Changed 4 weeks ago by cehoyos

Replying to malakudi:

In case any dev is following this, I made some progress finding the root cause of the issue. -r 50 on output does not always make ffmpeg to drop frames with cuvid's deint adaptive enabled. It does drop frames if original input is encoded as MBAFF. If original input is encoded as PAFF, then -r 50 on output does NOT drop frames and works as expected.

It is expected that behaviour wrt timebase is different for MBAFF (non-PAFF) and PAFF (including mixed PAFF and MBAFF) input.

comment:18 follow-up: Changed 4 weeks ago by cehoyos

Since you mention -r 50 all the time: This is what Mark used for his 25fps interlaced input, for the ntsc sample you tested originally, it should be -r 60000/1001 (for the working case which assumes same start time for audio and video which isn't always the case).

comment:19 in reply to: ↑ 16 Changed 4 weeks ago by malakudi

Replying to cehoyos:

Replying to malakudi:

After further testing, -r 50 on input works fine if input is a correct encoded file, starting from keyframe etc etc.

If input is a live stream (http or udp multicast), even if it starts at keyframe, with -r 50 as input any input error will immediately result in audio/video sync error.

This is expected.

Well, if it is expected, using -r XX as input flag is not an option for many workloads. -r XX as output should be "fixed" to work as it used to work before the above mentioned commit. Before the above mentioned commit, both kind of interlaced h264 input (MBAFF and PAFF) were working with -r XX on output. After that commit, as I found out, ffmpeg drops frames if input is MBAFF. It would be nice to fix this, although there is now an alternative, yadif_cuda filter. But since it used to work, it would be nice to make it work again.

comment:20 in reply to: ↑ 18 Changed 4 weeks ago by malakudi

Replying to cehoyos:

Since you mention -r 50 all the time: This is what Mark used for his 25fps interlaced input, for the ntsc sample you tested originally, it should be -r 60000/1001 (for the working case which assumes same start time for audio and video which isn't always the case).

Yes, I replaced now with -r XX, I wrote -r 50 in last messages because I now test on some 1080i50 inputs.

comment:21 Changed 4 weeks ago by cehoyos

Does the following make any difference? I just want to understand why it isn't possible to change the time base from the decoder.

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 0358936..292e1c1 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -225,7 +225,7 @@ static int CUDAAPI cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form
         avctx->bit_rate = format->bitrate;

     if (format->frame_rate.numerator && format->frame_rate.denominator) {
-        avctx->framerate.num = format->frame_rate.numerator;
+        avctx->framerate.num = format->frame_rate.numerator *2;
         avctx->framerate.den = format->frame_rate.denominator;
     }

comment:22 Changed 3 weeks ago by malakudi

It doesn't make any difference. Without -r XX on input or output, there are dropped frames. With -r XX on output, also dropped frames. With -r XX on input, no dropped frames but video/audio sync issues.

comment:23 follow-up: Changed 3 weeks ago by oromit

ffmpeg.c just does not support a decoder changing the framerate of a video. Making it so it does is a major undertaking.
The only way around it is to use the deinterlacer via API from an application that supports it.

comment:24 in reply to: ↑ 23 Changed 3 weeks ago by malakudi

Replying to oromit:

ffmpeg.c just does not support a decoder changing the framerate of a video. Making it so it does is a major undertaking.
The only way around it is to use the deinterlacer via API from an application that supports it.

It used to work with -r XX on output before the above mentioned commit. There is no way to make this happen again? Why it worked before and doesn't work now?

comment:25 Changed 3 weeks ago by oromit

The linked commit is a somewhat major behavior change in the decode.c involving the old and new decode API logic. It "working" before probably was probably pure luck.

comment:26 Changed 3 weeks ago by malakudi

@oromit, can you comment on the following? I run with debug_ts and see this pattern:

filter -> pts:32 pts_time:0.64 exact:31.859459 time_base:1/50
filter -> pts:33 pts_time:0.66 exact:32.859459 time_base:1/50
filter -> pts:34 pts_time:0.68 exact:33.859459 time_base:1/50
filter -> pts:35 pts_time:0.7 exact:34.859459 time_base:1/50
filter -> pts:36 pts_time:0.72 exact:35.859459 time_base:1/50
filter -> pts:37 pts_time:0.74 exact:36.859459 time_base:1/50
filter -> pts:38 pts_time:0.76 exact:37.859459 time_base:1/50
filter -> pts:39 pts_time:0.78 exact:38.859459 time_base:1/50
filter -> pts:40 pts_time:0.8 exact:39.859459 time_base:1/50
filter -> pts:41 pts_time:0.82 exact:40.859459 time_base:1/50
filter -> pts:42 pts_time:0.84 exact:41.859459 time_base:1/50
filter -> pts:43 pts_time:0.86 exact:42.859459 time_base:1/50
filter -> pts:44 pts_time:0.88 exact:43.859459 time_base:1/50
filter -> pts:45 pts_time:0.9 exact:44.859459 time_base:1/50
filter -> pts:46 pts_time:0.92 exact:45.859459 time_base:1/50
filter -> pts:47 pts_time:0.94 exact:46.859459 time_base:1/50
filter -> pts:48 pts_time:0.96 exact:47.859459 time_base:1/50
filter -> pts:49 pts_time:0.98 exact:48.859459 time_base:1/50
filter -> pts:50 pts_time:1 exact:49.859459 time_base:1/50
filter -> pts:51 pts_time:1.02 exact:50.859459 time_base:1/50
filter -> pts:52 pts_time:1.04 exact:51.859459 time_base:1/50
filter -> pts:53 pts_time:1.06 exact:52.859459 time_base:1/50
filter -> pts:54 pts_time:1.08 exact:53.859459 time_base:1/50
filter -> pts:55 pts_time:1.1 exact:54.859459 time_base:1/50
filter -> pts:56 pts_time:1.12 exact:55.859459 time_base:1/50
filter -> pts:57 pts_time:1.14 exact:56.859459 time_base:1/50
filter -> pts:58 pts_time:1.16 exact:57.859459 time_base:1/50
filter -> pts:59 pts_time:1.18 exact:58.859459 time_base:1/50
filter -> pts:60 pts_time:1.2 exact:59.859459 time_base:1/50
filter -> pts:61 pts_time:1.22 exact:60.859459 time_base:1/50
filter -> pts:62 pts_time:1.24 exact:61.859459 time_base:1/50
filter -> pts:63 pts_time:1.26 exact:62.859459 time_base:1/50
filter -> pts:64 pts_time:1.28 exact:63.859459 time_base:1/50
filter -> pts:65 pts_time:1.3 exact:64.859459 time_base:1/50
filter -> pts:66 pts_time:1.32 exact:65.859459 time_base:1/50
filter -> pts:67 pts_time:1.34 exact:66.859459 time_base:1/50
filter -> pts:68 pts_time:1.36 exact:67.859459 time_base:1/50
filter -> pts:69 pts_time:1.38 exact:68.859459 time_base:1/50
filter -> pts:70 pts_time:1.4 exact:69.859459 time_base:1/50
filter -> pts:71 pts_time:1.42 exact:70.859459 time_base:1/50
filter -> pts:72 pts_time:1.44 exact:71.859459 time_base:1/50
filter -> pts:73 pts_time:1.46 exact:72.859459 time_base:1/50
filter -> pts:74 pts_time:1.48 exact:73.859459 time_base:1/50
filter -> pts:75 pts_time:1.5 exact:74.859459 time_base:1/50
filter -> pts:76 pts_time:1.52 exact:75.859459 time_base:1/50
filter -> pts:77 pts_time:1.54 exact:76.859459 time_base:1/50
filter -> pts:78 pts_time:1.56 exact:77.859459 time_base:1/50
filter -> pts:79 pts_time:1.58 exact:78.859459 time_base:1/50
filter -> pts:80 pts_time:1.6 exact:79.859459 time_base:1/50
filter -> pts:81 pts_time:1.62 exact:80.859459 time_base:1/50
filter -> pts:82 pts_time:1.64 exact:81.859459 time_base:1/50
filter -> pts:83 pts_time:1.66 exact:82.859459 time_base:1/50
filter -> pts:84 pts_time:1.68 exact:83.859459 time_base:1/50
filter -> pts:85 pts_time:1.7 exact:84.859459 time_base:1/50
filter -> pts:86 pts_time:1.72 exact:85.859459 time_base:1/50
filter -> pts:87 pts_time:1.74 exact:86.859459 time_base:1/50
filter -> pts:88 pts_time:1.76 exact:87.859459 time_base:1/50
filter -> pts:89 pts_time:1.78 exact:88.859459 time_base:1/50
filter -> pts:90 pts_time:1.8 exact:89.859459 time_base:1/50
filter -> pts:91 pts_time:1.82 exact:90.859459 time_base:1/50
filter -> pts:92 pts_time:1.84 exact:91.859459 time_base:1/50
filter -> pts:93 pts_time:1.86 exact:92.859459 time_base:1/50
filter -> pts:98 pts_time:1.96 exact:97.859459 time_base:1/50
filter -> pts:101 pts_time:2.02 exact:100.859459 time_base:1/50
filter -> pts:102 pts_time:2.04 exact:101.859459 time_base:1/50
filter -> pts:104 pts_time:2.08 exact:103.859459 time_base:1/50
filter -> pts:100 pts_time:2 exact:99.859459 time_base:1/50
filter -> pts:99 pts_time:1.98 exact:98.859459 time_base:1/50
*** dropping frame 66 from stream 0 at ts 100
filter -> pts:110 pts_time:2.2 exact:109.859459 time_base:1/50
*** dropping frame 66 from stream 0 at ts 99
filter -> pts:115 pts_time:2.3 exact:114.859459 time_base:1/50
filter -> pts:114 pts_time:2.28 exact:113.859459 time_base:1/50
filter -> pts:116 pts_time:2.32 exact:115.859459 time_base:1/50
*** dropping frame 68 from stream 0 at ts 114
filter -> pts:112 pts_time:2.24 exact:111.859459 time_base:1/50
filter -> pts:111 pts_time:2.22 exact:110.859459 time_base:1/50
*** dropping frame 69 from stream 0 at ts 112
filter -> pts:122 pts_time:2.44 exact:121.859459 time_base:1/50
*** dropping frame 69 from stream 0 at ts 111
filter -> pts:127 pts_time:2.54 exact:126.859459 time_base:1/50
filter -> pts:126 pts_time:2.52 exact:125.859459 time_base:1/50
filter -> pts:128 pts_time:2.56 exact:127.859459 time_base:1/50
*** dropping frame 71 from stream 0 at ts 126
filter -> pts:124 pts_time:2.48 exact:123.859459 time_base:1/50
filter -> pts:123 pts_time:2.46 exact:122.859459 time_base:1/50
*** dropping frame 72 from stream 0 at ts 124
filter -> pts:134 pts_time:2.68 exact:133.859459 time_base:1/50
*** dropping frame 72 from stream 0 at ts 123
filter -> pts:139 pts_time:2.78 exact:138.859459 time_base:1/50
filter -> pts:138 pts_time:2.76 exact:137.859459 time_base:1/50
filter -> pts:140 pts_time:2.8 exact:139.859459 time_base:1/50
*** dropping frame 74 from stream 0 at ts 138
filter -> pts:136 pts_time:2.72 exact:135.859459 time_base:1/50
filter -> pts:135 pts_time:2.7 exact:134.859459 time_base:1/50
*** dropping frame 75 from stream 0 at ts 136
filter -> pts:146 pts_time:2.92 exact:145.859459 time_base:1/50
*** dropping frame 75 from stream 0 at ts 135
filter -> pts:151 pts_time:3.02 exact:150.859459 time_base:1/50
filter -> pts:150 pts_time:3 exact:149.859459 time_base:1/50
filter -> pts:152 pts_time:3.04 exact:151.859459 time_base:1/50
*** dropping frame 77 from stream 0 at ts 150
filter -> pts:148 pts_time:2.96 exact:147.859459 time_base:1/50
filter -> pts:147 pts_time:2.94 exact:146.859459 time_base:1/50
*** dropping frame 78 from stream 0 at ts 148
filter -> pts:158 pts_time:3.16 exact:157.859459 time_base:1/50
*** dropping frame 78 from stream 0 at ts 147
filter -> pts:163 pts_time:3.26 exact:162.859459 time_base:1/50
filter -> pts:162 pts_time:3.24 exact:161.859459 time_base:1/50
filter -> pts:164 pts_time:3.28 exact:163.859459 time_base:1/50
*** dropping frame 80 from stream 0 at ts 162
filter -> pts:160 pts_time:3.2 exact:159.859459 time_base:1/50
filter -> pts:159 pts_time:3.18 exact:158.859459 time_base:1/50
*** dropping frame 81 from stream 0 at ts 160
filter -> pts:170 pts_time:3.4 exact:169.859459 time_base:1/50
*** dropping frame 81 from stream 0 at ts 159
filter -> pts:175 pts_time:3.5 exact:174.859459 time_base:1/50
filter -> pts:174 pts_time:3.48 exact:173.859459 time_base:1/50
filter -> pts:176 pts_time:3.52 exact:175.859459 time_base:1/50
*** dropping frame 83 from stream 0 at ts 174
filter -> pts:172 pts_time:3.44 exact:171.859459 time_base:1/50
filter -> pts:171 pts_time:3.42 exact:170.859459 time_base:1/50
*** dropping frame 84 from stream 0 at ts 172
filter -> pts:182 pts_time:3.64 exact:181.859459 time_base:1/50
*** dropping frame 84 from stream 0 at ts 171
filter -> pts:187 pts_time:3.74 exact:186.859459 time_base:1/50
filter -> pts:186 pts_time:3.72 exact:185.859459 time_base:1/50
filter -> pts:188 pts_time:3.76 exact:187.859459 time_base:1/50
*** dropping frame 86 from stream 0 at ts 186
filter -> pts:184 pts_time:3.68 exact:183.859459 time_base:1/50
filter -> pts:183 pts_time:3.66 exact:182.859459 time_base:1/50
*** dropping frame 87 from stream 0 at ts 184
filter -> pts:194 pts_time:3.88 exact:193.859459 time_base:1/50
*** dropping frame 87 from stream 0 at ts 183
filter -> pts:199 pts_time:3.98 exact:198.859459 time_base:1/50
filter -> pts:198 pts_time:3.96 exact:197.859459 time_base:1/50
filter -> pts:200 pts_time:4 exact:199.859459 time_base:1/50
*** dropping frame 89 from stream 0 at ts 198

Above log is with -r 50 on output. It seems the frames timestamps are not coming in order and that's why they are dropped. Maybe we could introduce a buffer to re-order the frames there? Sorry if my suggestion is stupid, I don't completely understand the internals, just trying to find a solution.

edit: Also I now see that first 65-70 frames come out in sequence, then the "jumping" starts.

Last edited 3 weeks ago by malakudi (previous) (diff)

comment:27 Changed 3 weeks ago by malakudi

Also compared with ffmpeg-3.3.9 with -r 50 on output, frame timestamps come in sequential order there.

comment:28 follow-up: Changed 3 weeks ago by oromit

The issue is that the timebase will be 1/25 for 25i content. So it's impossible to represent 50 fps in that timebase, but a decoder can't change the timebase.
Hence the -r 50 on input, to trick ffmpeg.c into using a 1/50 timebase.
Results of trying to double the framerate on a timebase where +1 is already too much are pretty much random.

This jumping is weird though, and I can't reproduce it here. I suspect the source material is already broken like that and it just carries through.

Keep in mind that mpeg2 is most likely not a well tested format, and nvidias parser also is far from perfect for common formats. So it messing up the re-ordering is not out of the question.

comment:29 in reply to: ↑ 28 Changed 3 weeks ago by malakudi

Replying to oromit:

The issue is that the timebase will be 1/25 for 25i content. So it's impossible to represent 50 fps in that timebase, but a decoder can't change the timebase.
Hence the -r 50 on input, to trick ffmpeg.c into using a 1/50 timebase.
Results of trying to double the framerate on a timebase where +1 is already too much are pretty much random.

This jumping is weird though, and I can't reproduce it here. I suspect the source material is already broken like that and it just carries through.

Keep in mind that mpeg2 is most likely not a well tested format, and nvidias parser also is far from perfect for common formats. So it messing up the re-ordering is not out of the question.

Input of last log with the jumping frame timestamps is a standard h264 1080i dvb-t transmission here in Greece. You can get a small part of it from my vps server, http://207.154.237.57/files/input_1080i.ts

ffmpeg-3.3.9 does not show this jumping and that's why it works there with -r 50 on output. Full command I do this test is:

./ffmpeg-git -debug_ts -hwaccel cuvid -c:v h264_cuvid -deint adaptive -f mpegts -i input_1080i.ts -aspect 16:9 -flags:v +cgop -vcodec h264_nvenc -g 200 -refs 4 -bf 3 -profile:v high -level 4.2 -c:a aac -ac 2 -b:a 128k -r 50 -f mpegts -y /dev/null 2>&1 | egrep ^filter

comment:30 Changed 3 weeks ago by malakudi

Found a workaround! Adding -copyts parameter (and -r 50 on output) makes it work without dropping frames! And transcoded file seems to be OK, with video/audio sync. Why is this working?

Note: See TracTickets for help on using tickets.