[Libav-user] Seeking in VBR MP3 file

[Tuukka Pasanen]

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.
>
>
Hello,
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 
do this
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 
diffrence.
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
[FRAME]
media_type=audio
key_frame=1
pkt_pts=99901440
pkt_pts_time=7.079184
pkt_dts=99901440
pkt_dts_time=7.079184
pkt_duration=368640
pkt_duration_time=0.026122
pkt_pos=125757
pkt_size=417
sample_fmt=s16p
nb_samples=1152
channels=2
channel_layout=stereo
[/FRAME]

This is second frame with  ffprobe -show_frames
[FRAME]
media_type=audio
key_frame=1
pkt_pts=80363520
pkt_pts_time=5.694694
pkt_dts=80363520
pkt_dts_time=5.694694
pkt_duration=368640
pkt_duration_time=0.026122
pkt_pos=101556
pkt_size=417
sample_fmt=s16p
nb_samples=1152
channels=2
channel_layout=stereo
[/FRAME]

Tuukka