MPEG file duration
Mike D Sutton
little confused about how to properly interpret the duration of the video. My first guess would be that the GOP header would
contain this information but perhaps I'm interpreting the time code of the block incorrectly. Do I have to scan the entire file and
count frame headers to find the duration or is there a more efficient way?
I've gone through the source code of two MPEG decoders and my head is still spinning so any help on this issue would be greatly
appreciated.
Cheers,
Mike
Michel Bardiaux
except the one you already thought of: count frame headers.
Of course, if you produce your own MPEGs then you can take care at
encoding time to have no holes in timecodes, then you can simply take
the difference of the 1st and last timecodes. Or do as I do: produce
exclusively files of eactly 1500 frames, ie 1 minute. Thr price is that
any incomplete file has to be junked completely.
HaND,
--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41
Mike D Sutton
> There is simply no *reliable* way to obtain the duration of an MPEG file
> except the one you already thought of: count frame headers.
>
> Of course, if you produce your own MPEGs then you can take care at
> encoding time to have no holes in timecodes, then you can simply take
> the difference of the 1st and last timecodes. Or do as I do: produce
> exclusively files of eactly 1500 frames, ie 1 minute. Thr price is that
> any incomplete file has to be junked completely.
Ok, looks like I'll go for the first and last timecode solution for now and offer the frame header count as an alternative. Is
these a faster way of navigating frame headers other than seeking through the file to get a sequence start code? I realise this is
intended for easily re-syncing streams but for this kind of operation it's a killer in comparison with something like AVI which has
the size stored for each RIFF chunk and an index table.
Cheers,
Mike
- Microsoft Visual Basic MVP -
E-Mail: ED...@mvps.org
WWW: Http://EDais.mvps.org/
Michel Bardiaux
> Hi Michel,
>
>
>>There is simply no *reliable* way to obtain the duration of an MPEG file
>>except the one you already thought of: count frame headers.
>>
>>Of course, if you produce your own MPEGs then you can take care at
>>encoding time to have no holes in timecodes, then you can simply take
>>the difference of the 1st and last timecodes. Or do as I do: produce
>>exclusively files of eactly 1500 frames, ie 1 minute. Thr price is that
>>any incomplete file has to be junked completely.
>
>
> Ok, looks like I'll go for the first and last timecode solution for now and offer the frame header count as an alternative. Is
> these a faster way of navigating frame headers other than seeking through the file to get a sequence start code?
No. But if you wish, you can do it just once and create an index file.
> I realise this is
> intended for easily re-syncing streams but for this kind of operation it's a killer in comparison with something like AVI which has
> the size stored for each RIFF chunk and an index table.
At a significant price: MPEG files are much more resistant to damage.
You can concatenate them, split them any which way, take away arbitrary
chunks, corrupt some parts, many players will still play the file
(though seeking often becomes hairy...) or at least some tools like
ffmpeg will recover the good parts. Try that with AVI...
> Cheers,
>
> Mike
Mike D Sutton
Ok, makes sense
> At a significant price: MPEG files are much more resistant to damage.
> You can concatenate them, split them any which way, take away arbitrary
> chunks, corrupt some parts, many players will still play the file
> (though seeking often becomes hairy...) or at least some tools like
> ffmpeg will recover the good parts. Try that with AVI...
Very true, thanks for your assistance on the matter I think I have all I need to complete this now.
Cheers,
Mike
P.s. On another (but similar) issue, do you happen to know of a good and reasonably easy to use MPEG encoder that can write MPEG 1/2
which I can just throw frames at (sound optional for now, not essential for the time being but it would be handy later.)
Currently we're using the MCL from Gromada.com however I'm just wondering what those who actually know what they're doing use? *g*
Language isn't really an issue, C/C++/Delphi/VB would be fine but I'd prefer to avoid anything .NET for now, freeware would be great
but if there's a reasonably priced commercial solution then that would also be fine.
Jim Leonard
> P.s. On another (but similar) issue, do you happen to know of a good
and reasonably easy to use MPEG encoder that can write MPEG 1/2
> which I can just throw frames at (sound optional for now, not
essential for the time being but it would be handy later.)
Mike D Sutton
Thanks, I'll take a look.
Mike
Michel Bardiaux
We use ffmpeg on Linux, but I can confirm it does work on Win32
(compiled with mingw). I recommend you visit www.ffmpeg.org, subscribe
to ffmpeg-users, and use the latest CVS version - the latest released
tarball has some traps for the win32 users.
>
> - Microsoft Visual Basic MVP -
> E-Mail: ED...@mvps.org
> WWW: Http://EDais.mvps.org/
>
>
Tobias Bergmann
> Mike D Sutton wrote:
> We use ffmpeg on Linux, but I can confirm it does work on Win32
> (compiled with mingw). I recommend you visit www.ffmpeg.org, subscribe
> to ffmpeg-users, and use the latest CVS version - the latest released
> tarball has some traps for the win32 users.
There are several Win32 builds of ffmpeg on this mirror:
http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/
bis besser,
Tobias