Hi, the problem seems to be that FFmpegDecoder::rewindButDontFlushQueues() is calling rewind() which in turn resets the timestamps returned by the FFmpegClocks object. This ignores the fact that there is still audio/video to be played out before the playout queues are actually empty.
FFmpegClocks::getAudioTime() returns 49.520416 FFmpegDecoder::rewindButDontFlushQueues() FFmpegClocks::rewind() m_audio_buffer_end_pts (0.000000) + m_audio_timer.time_s() (0.006894) - m_pause_ time (0.000000) - m_audio_delay (0.000000) - m_seek_time (0.000000) FFmpegClocks::getAudioTime() returns 0.007114 I do not have a fix right now, but I will be thinking about one. 2015-03-12 15:18 GMT+01:00 Christian Buchner <[email protected]>: > Reviving this old thread with new information. > > I use a 60 second MP4 clip for testing, no audio stream in the file. OSG > 3.2 branch is used with the FFMPEG plug-in. The FFMPEG version is 2.5.4 > stable (I tried GPL and LGPL builds). This is on Windows 7. > > After about 49 seconds, the value returned by > imagestream->getCurrentTime() wraps around to 0... instead of returning the > expected 49...60 seconds. This can be verified visually with the > osgmultiplemovies player using the -e FFMPEG command line option and > passing an MP4 file containing no audio stream. It will show the bad > timestamps just before the end of the MP4 file is reached. > > imagestream->getCurrentTime() internally calls getAudioTime() on the > FFmpegClocks object. Here are the member variable printouts before and > after the unexpected wraparound > > m_audio_buffer_end_pts (0.000000) + m_audio_timer.time_s() (46.598209) - > m_pause > _time (0.009297) - m_audio_delay (0.000000) - m_seek_time (-2.752658) > FFmpegClocks::getAudioTime() returns 49.341741 > > m_audio_buffer_end_pts (0.000000) + m_audio_timer.time_s() (0.041314) - > m_pause_ > time (0.000000) - m_audio_delay (0.000000) - m_seek_time (0.000000) > FFmpegClocks::getAudioTime() returns 0.041579 > > What I find interesting is that m_seek_time is reset, as well as > m_audio_timer.time_s(). > This might be triggered due to a wraparound of the decoder which already > rewinds and starts decoding the start of the file again, in my case 11 > seconds before playout of the entire file is finished. > > Christian > > > 2014-12-09 15:03 GMT+01:00 Christian Buchner <[email protected]> > : > >> Thanks for weighing in, >> >> I guess I will have to try various combinations of operating system and >> FFMPEG releases to get to the bottom of this. >> >> As a last resort I could imagine myself editing the ffmpeg plug-in source >> code. I would also try to add variable speed playback (without audio, as >> this would require audio resampling) >> >> Christian >> >> >> 2014-12-09 14:52 GMT+01:00 Robert Osfield <[email protected]>: >> >>> Hi Christian, >>> >>> I have just tried your video with osgmultiplemovies with svn/trunk but >>> it comes out black. I run the same movie in osgmovie it comes out fine >>> though. No stats though so doesn't reveal any particular problem. >>> >>> I'm not the author of the ffmpeg plugin so I can't provide any >>> particular insights off the top of my head. >>> >>> Robert. >>> >>> On 9 December 2014 at 13:31, Christian Buchner < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> the OSG 3.2 seems to have a problem with reported timestamps while >>>> replaying movies. I haven't tested never OSG development versions yet. The >>>> issue occurs close to the end of an MP4 file. >>>> >>>> The timestamp wraps around back to 0 before the end of the file is >>>> played out. There are also side effects, like the playout stopping >>>> temporarily until the wrapped around timestamps has caught up. >>>> >>>> I suspect this is due to ffpmeg having pre-buffered all data to the end >>>> of the file, and wrapping back around to 0 to re-buffer from the start of >>>> the file. But at that point the playout of the file hasn't finished yet, >>>> but the plug-in already reports timestamps of 0. >>>> >>>> I have a short 40 frame file (all I-frames) of 1.333 seconds duration >>>> that demonstrates the effect. >>>> >>>> >>>> https://www.dropbox.com/s/dzolh5kf2xk8zpa/overlay_iot_applications.mp4?dl=0 >>>> >>>> osgmultiplemovies -e FFMPEG overlay_iot_applications.mp4 >>>> >>>> would demonstrate the problem. Instead of playing out and looping >>>> smoothly, it interrupts playback at half the duration, only to resume later >>>> when the wrapped-around timestamp has caught up. This is bizarre. >>>> >>>> The ffmpeg version I've been testing with is the GPL'ed version >>>> ffmpeg-20140924-git-3bc0361-win64-shared >>>> >>>> Christian >>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> [email protected] >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
