Opened 6 years ago
Last modified 3 years ago
#6971 open defect
ffmpeg drops frames after deinterlacing
| Reported by: | Cary Knoop | 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 (31)
comment:1 by , 6 years ago
| Component: | ffmpeg → undetermined |
|---|---|
| Keywords: | cuvid added |
| Version: | 3.4 → git-master |
follow-up: 3 comment:2 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
| Keywords: | deinterlace framerate added |
|---|
comment:6 by , 6 years ago
| Keywords: | deinterlace framerate removed |
|---|
comment:7 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
./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 by , 6 years ago
everything works fine, -r 50 , but you have to choose proper H264 profile - for 1080p -high 4.2 ... so no bugs are there...
comment:11 by , 5 years ago
@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 by , 5 years ago
Just tried again, output is more than 3-4 seconds async when I use -r 50 as input.
comment:13 by , 5 years ago
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?
follow-up: 16 comment:14 by , 5 years ago
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?
follow-up: 17 comment:15 by , 5 years ago
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.
follow-up: 19 comment:16 by , 5 years ago
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 by , 5 years ago
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.
follow-up: 20 comment:18 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
Replying to cehoyos:
Since you mention
-r 50all 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 by , 5 years ago
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 by , 5 years ago
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.
follow-up: 24 comment:23 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
@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.
comment:27 by , 5 years ago
Also compared with ffmpeg-3.3.9 with -r 50 on output, frame timestamps come in sequential order there.
follow-up: 29 comment:28 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
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?
comment:31 by , 3 years ago
| Status: | new → open |
|---|
Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.