[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