Reimar Döffinger <b...@reimardoeffinger.de> added the comment:
On Sat, Dec 04, 2010 at 12:52:30AM +0000, Deyan wrote:
> I tested with: mplayer, windows medial player, Firefox.
Playback issue confirmed with ffplay, too.
Using FFmpeg to transcode to a different format also keeps the "hang".
Useing "-vcodec copy -f framecrc" shows the difference is in the
timestamps: the "good" (I have some doubts that it isn't just
less horrible) file has timestamp jumps a bit spread out all
over, whereas the bad one has more gradual time-stamps but then
a large jump.
Typical excerpt from the diff good to bad:
0, 30030, 47, 0x9f471ae3
0, 33784, 14, 0x3987078d
0, 37538, 22979, 0x975c0c10
-0, 48799, 469, 0x4624cd4d
-0, 52553, 128, 0xe6c93b29
-0, 56306, 116, 0x6e73317c
+0, 41291, 469, 0x4624cd4d
+0, 45045, 128, 0xe6c93b29
+0, 48799, 116, 0x6e73317c
0, 60060, 22954, 0xe74718ed
I suspect that this is only an issue with variable frame-rate
input, explicitly specifying -r before the output when encoding
might help.
Note that since this depends on encoder version, it might well be
related to this in libtheoraenc.c (note that there are more reasons
than just multithreading that would cause this to break):
// HACK: assumes no encoder delay, this is true until libtheora becomes
// multithreaded (which will be disabled unless explictly requested)
avc_context->coded_frame->pts = frame->pts;
avc_context->coded_frame->key_frame = !(o_packet.granulepos &
h->keyframe_mask);
________________________________________________
FFmpeg issue tracker <iss...@roundup.ffmpeg.org>
<https://roundup.ffmpeg.org/issue2398>
________________________________________________
