Effective February 22, 2024, Google Groups will no longer support new Usenet content. Posting and subscribing will be disallowed, and new content from Usenet peers will not appear. Viewing and searching of historical data will still be supported as it is done today.
Dismiss

MPEG file duration

10 views
Skip to first unread message

Mike D Sutton

unread,
Jan 11, 2005, 7:02:15 AM1/11/05
to
I'm writing a simple library to extract various bits (no pun intended ;) of information from an MPEG video file, however I'm a
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

unread,
Jan 12, 2005, 4:56:31 AM1/12/05
to
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.

HaND,
--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41

Mike D Sutton

unread,
Jan 12, 2005, 6:32:48 AM1/12/05
to
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? 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

unread,
Jan 13, 2005, 6:22:15 AM1/13/05
to
Mike D Sutton wrote:
> 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

unread,
Jan 13, 2005, 10:35:55 AM1/13/05
to
> No. But if you wish, you can do it just once and create an index file.

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

unread,
Jan 13, 2005, 5:56:42 PM1/13/05
to
Mike D Sutton wrote:
> 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.)
Yes, I believe there's a windows port of the "ffmpeg" library.

Mike D Sutton

unread,
Jan 13, 2005, 7:06:53 PM1/13/05
to
> Yes, I believe there's a windows port of the "ffmpeg" library.

Thanks, I'll take a look.

Mike

Michel Bardiaux

unread,
Jan 17, 2005, 6:05:29 AM1/17/05
to

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

unread,
Jan 20, 2005, 6:06:03 AM1/20/05
to
Michel Bardiaux wrote:

> 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

Reply all
Reply to author
Forward
0 new messages