Fix seeking when the start time is non-zero.
The seek timestamp should always be adjusted by the start time, though this manipulation should not be visible to external (web) clients. Since this is an FFmpeg only problem, I've removed the concept of start time from the Demuxer interface in favor of local method only for FFmpegDemuxer. FFmpegDemuxerStream's will now use this value to adjust timestamps such that external clients always see a zero based timeline. Doing so required moving some of our ogg vorbis discard code into the FFmpegDemuxerStream, which actually makes it more accurate and more narrowly scoped to ogg w/ vorbis instead of all vorbis. These changes subtly change how we handle seeking. Previously we would let FFmpeg choose the stream to perform seeking within. Now we will use the video stream only if it contains the seek timestamp, if none exists or does not contain the seek timestamp, we'll use the stream with the lowest start time. I've extended the tests around non-zero start times to verify the new behavior. An FFmpeg DEPS roll is required for the new tests to pass: 5c3de80 Pass remaining command-line arguments to ffmpeg's configure de80875 Change the sigs file to use c-style comments. cb19b2d Update ffmpeg's GN build to use new yasm assemble format. 9c12290 Revert "avformat/mp3dec: fix start time in light of initial skip samples" 1e661a6 avcodec/vorbisdec: Reset first_frame 7d88be4 avformat/oggparsevorbis: Dont attempt to calculate timestamps from gp=0 BUG=377295 TEST=New unittests. Demo page from bug works. Layout tests pass. Review URL: https://codereview.chromium.org/335273002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@278046 0039d316-1c4b-4281-b951-d872f2087c98
Showing
This diff is collapsed.
Please register or sign in to comment