Arnd Bergmann <[email protected]> added the comment:
I have the same problem here and tried many different command line
option for hours, but I then noticed the unusual tbn value
(ffplay -stats):
Stream #0.0[0xfd55]: Video: vc1, yuv420p, 1920x1080 [PAR 1:1 DAR
16:9], 23.98 tbr, 90k tbn, 29.97 tbc
Without really knowing what this means (haven't hacked on ffmpeg since
2001), I experimented with changes to how the frame rate is
calculated.
Finally, this change did the trick:
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d3b9c09..43c1703 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2343,7 +2343,7 @@ AVStream *av_new_stream(AVFormatContext *s, int
id)
st->first_dts = AV_NOPTS_VALUE;
/* default pts setting is MPEG-like */
- av_set_pts_info(st, 33, 1, 90000);
+ av_set_pts_info(st, 33, 1001, 24000);
st->last_IP_pts = AV_NOPTS_VALUE;
for(i=0; i<MAX_REORDER_DELAY+1; i++)
st->pts_buffer[i]= AV_NOPTS_VALUE;
It does break a lot of other functionality (e.g. playing anything with
mplayer), but now I can play the file just fine using ffplay.
Setting the rate to 30000/1001 here (same as tbr and tbc) also solves
the skipping, but lets the file lose a/v sync.
I hope this helps track down the real cause for the annoying bug.
____________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue465>
____________________________________________________
