[Libav-user] Seeking in VBR MP3 file
pasanen.tuukka at gmail.com
Tue Oct 29 08:25:23 CET 2013
On 28.10.2013 19:40, Carl Eugen Hoyos wrote:
> Tuukka Pasanen <pasanen.tuukka at ...> writes:
>> I pulled down version 2.1 from git version and there is no
>> change. Commit 'e096283' seems to fix MP3 CBR like it says.
>> Some VBR level 1 files works also sounds pretty good. One
>> starts to hear more errors from VBR level 2 and above. I
>> made some test files with lame 3.99.5 and get same results
>> from VBR level 1-4 (Lame now defaults to level 4). Is there
>> some debugs that I can put my fingers in?
> Is the problem also reproducible with ffmpeg (the application)?
> Look at ticket #2590 for another example that was reproducible
> with ffmpeg. If it is reproducible, please provide a test case.
First I ask should I file a ticket? Probably because I'm asking. It
could be reproducible with ffmpeg but you can't see how?
I try to explain why. In my test VBR 4 mp3 file. I jump random jump
point '99901440' (which should be at byte: 624384 B)
if we read with ffprobe -show_frames it exist (see end of message).
If we ut this in avformat_seek_file and never read first frame with flag
AVSEEK_FLAG_BACKWARD we jump to probably in Xing jump point PTS
'80802202' Byte offset '505014 B'. Xing VBR jump point is alright (all
though Libav and FFMPEG 0.11 doesn't do it like this) because you can
just travel near right PTS which in this time is '99602842' so PTS
diffrence is 298598 (Bytes: -1866 B).
Things get interesting if we travell backwards in time to PTS 80802202
and jump couple 2304 bytes backward like 80363520 (Byte offset 502272)
then we get to PTS 0 so everything goes right first point what we tried
to jump PTS 99901440.
Problem comes in existence if like to get these two points together so
we start reading first jump point and read couple frames and then user
wants to jump another point in file (second PTS) and then we try to
solve how to make them in cache (which works in milli seconds and point of
PCM) because these two points are not in same PTS space because if just
tune -(1186 * 2) B backwards time PTS still ain't same!
Like I same Libav 9 does this correct and this PTS incorrectness causes
also 'Header missing error' even if we try to jump precalculated jump
points (2304 * wanted point) which again works with Libav 9. More
problematic this comes if we go forward and PTS jump like crazy. I could
like every time start reading from beginning until I get correct point
but then whole idea using FFMPEG is just waste of time.
So if you want to reproduce this with ffmpeg have VBR 4 lame encoded mp3
and then first jump with -ss 00:00:07.079 and read translate 10s to wav.
then rerun ffmpeg with -ss 00:00:05.694. After that launch for examle
audacity import both wav and but them manually in correct place then try
to make them look same or just launch ffplay with -ss 00:01:35 and start
jumping forward and backward and if you can get it show PTS you notice
or you can use my small example app to debug this.. it would be nice to
ffprobe to have -ss also you could debug stuff like this!
Sorry this wasn't very clean and now frames from ffprobe:
This First frame is where we tried to jump printed with ffprobe -show_frames
This is second frame with ffprobe -show_frames
More information about the Libav-user