[FFmpeg-trac] #2877(undetermined:new): Unable to rewind/seek a mp3
FFmpeg
trac at avcodec.org
Fri Sep 20 10:55:31 CEST 2013
#2877: Unable to rewind/seek a mp3
-------------------------------------+-------------------------------------
Reporter: jpo38 | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: unspecified | undetermined
Keywords: seek | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by saste):
Replying to [comment:10 jpo38]:
> Thank you for investigating this problem.
>
> When I read my mp3 files, AVFormatContext::start_time is 0, so I suspect
my file starts with timestamp 0, right?
>
> I replaced
> av_seek_frame( container, audio_stream, 0, AVSEEK_FLAG_FRAME );
> by
> avformat_seek_file( container, audio_stream, INT64_MIN,
container->start_time, INT64_MAX, 0 )
>
> No change. I can still see the bug.
>
> I ran {{{ffprobe IN.mp3 -read_intervals "%2,0%2" -of compact
-show_packets}}}
>
> Here is the output (truncated):
[...]
> Looks like you read the file twice and you're getting the same number of
data. It works the same for me, only the data I read (when converted to
float/double) are not the same....
> Did you try to compile my sample? It's very straightforward. It reads
the file once, rewinds and reads again. It then compares data. We read the
same number of samples but not the same values...
It doesn't explain the issue, but you could try to flush the data in the
decoder before re-using it in the second loop, since it is the only object
which is reused between the two sessions. Also, with which formats does it
happen, how much is the data different, how many samples differ?
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2877#comment:11>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list