ffmpeg/tests/ref/fate/gapless-mp3-notoc

d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3-notoc.out-1
c96c3ae7bd3300fd2f4debac222de5b7
3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
c96c3ae7bd3300fd2f4debac222de5b7
92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3
fate: gapless: test mp3 both with and without TOC Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-17 17:27:03 +02:00			`d5c88cf38416329a052a9b0cb140fb4c *tests/data/fate/gapless-mp3-notoc.out-1`
			`c96c3ae7bd3300fd2f4debac222de5b7`
fate: gapless: fix mp3 tests Seeking to a negative time did not have the desired effect of seeking to the next valid position (the file start). On the other hand, just "-ss 0" will normally seek to a position higher than 0, because it adds the start time of the file. (The start time is not 0 because the gapless code skips a few samples from the start.) Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do what you'd expect it would do. Also put the -ss option at the right place, before -i. This actually makes it seek, instead of something completely else. The ".out-3" test is no different in the -usetoc 0/1 cases, because the seeking is inaccurate (in both cases). Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-20 19:36:52 +02:00			`3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2`
fate: gapless: test mp3 both with and without TOC Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-17 17:27:03 +02:00			`c96c3ae7bd3300fd2f4debac222de5b7`
avformat/mp3dec: Adjust returned timestamp in the CBR seeking case With this the returned timestamp should match the packet instead of the requested timestamp, which may lay between packets Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at> 2015-04-20 20:42:38 +02:00			`92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3`