Opened 11 years ago
Closed 11 years ago
#3095 closed defect (fixed)
Seeking in VBR MP3 file
Reported by: | Tuukka Pasanen | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avformat |
Version: | git-master | Keywords: | mp3 regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Seeking in mp3 CBR file is very accurate and works fine. Now when lame has default option to VBR level 4 and there is some problems in seeking.
This bug can be reproduced with ffprobe:
./ffprobe -show_frames -read_intervals 42.004898%+1,41.090612%42.031020,40.045714%41.116735 test-VBR4.mp3
Seek times are chosen from normal 'ffprobe -show_frames' without seeking. So playing from begining is working ok. If everything goes fine those PTS should be equal when seeking and when playing from start but now they are not.
Change History (13)
comment:2 by , 11 years ago
Could you confirm that this is a regression since 5864ce13 (ie that it worked fine with 8c51ea54), to some degree related to ticket #2590?
comment:3 by , 11 years ago
Yes I can If you just tell me what is the best way to get it out of GIT. My last way was check out last mp3dec before 1.0 and then 'patch -p1 -R' reverse stuf until I get to '5864ce13'. If I use git reset --hard to that and then 'patch -p1 -R' the patch is it enough??
comment:4 by , 11 years ago
Okay I can confirm that '8c51ea54' works ok and '5864ce13' break things.. If there is other way than 'git reset --hard SHASUM' please let me know..
comment:5 by , 11 years ago
Keywords: | regression added |
---|---|
Priority: | normal → important |
follow-up: 9 comment:6 by , 11 years ago
you can use "-usetoc 0" to get the old (slow but accurate) seeking behavior
follow-up: 8 comment:7 by , 11 years ago
is there any software that can seek better in this file ? that is seek more accuratly without reading the whole file sequentially
comment:8 by , 11 years ago
Replying to michael:
is there any software that can seek better in this file ? that is seek more accuratly without reading the whole file sequentially
Hello I have managed to made little example app for testing this bug for myself in https://github.com/illuusio/ffmpeg-example it's very very cruel but you can use it if you want. It tries to simulate Mixxx input plugging as it is my main goal of all this. Mixxx buffers stuff and you can seek backwards (as with vinyls or jump X place in file in DJ set) and the problem with mp3 (everyone’s most loved format) it doesn't sound very well if it's not precise place when you are going backwards or different place in file and play then buffered part.
follow-up: 10 comment:9 by , 11 years ago
Replying to michael:
you can use "-usetoc 0" to get the old (slow but accurate) seeking behavior
This sounds what I want! How do I turn it on?
av_opt_set_int(CodecCtx->priv_data, "usetoc", 1, 0);
doesn't do it.. If I can get speed of pre 1.0 and accurate seeking I'll be on my way..
comment:10 by , 11 years ago
Replying to tuukka:
av_opt_set_int(CodecCtx->priv_data, "usetoc", 1, 0);
usetoc is a demuxer, not a decoder option, see ffmpeg -h full
comment:11 by , 11 years ago
Okay you showed the way but I just can't get clue how to tune it..
av_opt_set_int(&m_pFormatCtx->iformat->priv_class, "usetoc", 1, 0);
Is this a correct way because if I do this sample_rates are reseted... or should I do this before I open codec?
Edit: If I do right after or before 'avcodec_open2' it works but not making any change
comment:12 by , 11 years ago
Ok I can verify this one works ok with code on GIT. So If you want to close this It up to you I can get my code working..
av_dict_set(&m_iFormatOpts, "usetoc", "0", 0); // Open file and make m_pFormatCtx if (avformat_open_input(&m_pFormatCtx,filename, NULL, &m_iFormatOpts)!=0) { printf("fe_decode_open: cannot open: %s\n", filename); return -1; } av_dict_free(&m_iFormatOpts);
comment:13 by , 11 years ago
Keywords: | mp3 added |
---|---|
Resolution: | → fixed |
Status: | new → closed |