Reimar Döffinger <[email protected]> added the comment: On Sat, Dec 04, 2010 at 12:30:10PM +0000, Baptiste Coudurier wrote: > Baptiste Coudurier <[email protected]> added the comment: > On 12/4/10 2:40 AM, Reimar Döffinger wrote: > > Reimar Döffinger <[email protected]> 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); > > Sort of, the problem is that the encoder outputs 0 bytes frames. > > Comment here: > 1. Your video starts out with digital black. Theora responds by > producing a single frame of black, and then zero-byte "dup frames" > indicating that nothing has changed. Some players are broken and don't > handle these frames correctly. Correctly working players, such as > Firefox, shouldn't have a problem, though. > > Are we supposed to write these frames in the ogg file ?
Since ogg has timestamps probably no. And while it might make sense for the encoder to output them (so it works nicely for users that can only handle constant frame-rate), I suspect that ffmpeg.c should discard them right away... Of course in theory there's the issue that some (not yet existing) codec might use 0-sized frames for something else (e.g. no coefficients but interpolate motion from previous motion), but I don't think we have consider that seriously. ________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/issue2398> ________________________________________________
