[MPlayer-dev-eng] Re: container format

Michael Niedermayer michaelni at gmx.at
Thu Feb 6 19:10:38 CET 2003


Hi

On Thursday 06 February 2003 18:54, Arpi wrote:
> Hi,
>
> > > I think it may be done with one additional bit - integer framerate and
> > > optional divider (if flag is 0 then 1.0 and otherwise 1.001 - see MPEG
> > > standard) so you can have these 29.97 as 30/1.001 and the same 23.976
> > > as 24/1.001. :)
> >
> > Why not spend 3 more bytes so you'll get a complete int for the
> > dividend? So you'd save (30000, 1001) AND you could also specifiy any
> > other fps you'd want...
>
> i vote for v/v, so it could be VLC-like coded.
>
> btw i would add one entry to the goals:
> - eaisly readable/editable in HEX editor/viwer
> yes it look stsupid but it isn't :)
use a BIT editor/viewer :))

>
> the only thing it expects to avoid variable length bitfields, like:
>         lsb_timestamp                           u(lsb_timestamp_length)
>         stream_id                               u(log2_stream_count)
>         priority                                u(2)
>
> i think that 'v' type is far enough for the stream_id.
hmm, currently there are 2bits for priority, 2 flags, the timestamp & 
stream_id these fit n 2 bytes normally, but if we encode the stream_id as v 
(its often just one bit, audio/video stream) then we need 3 bytes

and 1 byte per frame is 100k per hour for 30fps, thats ~0.025 % for a 650mb 
file, hmm ill guess thats ok :)
its the only non byte based thing in there and so its a nice simplification if 
its removed, so i'll use 'v' type for stream_id & lsb_timestamp & put the 
rest into a flags byte, unless someone has another idea (perhaps arithmetic 
coding ;)) )

[...]

Michael


More information about the MPlayer-dev-eng mailing list