On 28.10.2013 19:40, Carl Eugen Hoyos wrote:
Tuukka Pasanen <pasanen.tuukka@...> 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
_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
