[Ffmpeg-devel] About converting individual WAV file
Michel Bardiaux
mbardiaux
Mon Jan 16 11:29:12 CET 2006
M?ns Rullg?rd wrote:
> Michel Bardiaux said:
>
>>M?ns Rullg?rd wrote:
>>
>>>"Takeshi.Tanaka" <ztanaka at esbd.ndss.jp> writes:
>>>
>>>
>>>
>>>>Hi this is Japanese developer team.
>>>>Could you give me a good idea after reading this mail?
>>>>
>>>>Converting a MPG file to individual WAV file by command-line,
>>>>test1.wav and test2.wav overlap each other for 0.5sec.
>>>>So that we cannot listen test1.wav and test2.wav correctly.
>>>>
>>>>This overlapping problem is only between test1.wav and test2.wav.
>>>>
>>>>Command Line coding
>>>>~ffmpeg -i input.mpg -ss 0 -t 30 test1.wav
>>>>~ffmpeg -i input.mpg -ss 30 -t 30 test2.wav
>>>>~ffmpeg -i input.mpg -ss 60 -t 30 test3.wav
>>>>
>>>>Am I mistaking anything here?
>>>
>>>
>>>Seeking in MPEG files can never be very accurate.
>>
>>I dont agree. Seeking *can* be perfectly accurate *if* the file has been
>>properly muxed, using correctly spaced timestamps. Extra precautions
>>like constant closed GOPs should help too. Its just that ffmpeg does not
>>try very hard to seek accurately, on the grounds that many files do not
>>follow these rules!
>
>
> The rules that files must follow are ISO 13818-1. Were it not for timestamp
> discontinuities, it would be fairly simple to do a binary search to a point
> before the desired time and count frames from there. The same I-frame issues
> apply here as with any other format, only the I-frames are a little harder to
> find. Now it happens that timestamp discontinuities are allowed so there's
> not a lot one can do.
>
> The DVD format specifies some extra restrictions that make life easier. There
> is an upper limit on the GOP size of 15 frames, and there must be a packet
> start at 2k aligned positions. The disks also have an index, usually with
> a granularity of about 4 seconds. There can still be timestamp discontinuities
> though.
>
There are 2 kinds of discontinuities: the 33-bits rollover, which *must*
be correctly handled by any software worthy of the name; and other
discontinuities, which one should avoid when encoding - but against
which software should be robust.
I just think that when an MPEG is somehow 'ideal' (no discontinuty
except rollover, no open GOPs) its a shame ffmpeg does not perform
better seeking.
--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be
Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
More information about the ffmpeg-devel
mailing list