[MPlayer-dev-eng] MPCF proposal
Michael Niedermayer
michaelni at gmx.at
Tue Mar 11 11:40:59 CET 2003
Hi
On Tuesday 11 March 2003 08:06, D Richard Felker III wrote:
> On Tue, Mar 11, 2003 at 01:50:11AM -0500, D Richard Felker III wrote:
> > Somehow the MPCF discussion seems to have died off... So here's what I
> > propose:
>
> Now to respond to myself...
>
> > 1) Anyone who has remaining complaints or issues that haven't yet been
> > resolved with MPCF should post them now, and they should be discussed.
>
> I believe there are still some problems with the way audio packets
> will be stored. In particular, I think it's essential that the demuxer
> be able to obtain any codec-level audio packet and its timestamp
> without having access to the codec. Otherwise it's impossible to
> cut or splice audio files with any degree of precision.
>
> I see two possible solutions...
>
> a) Try to minimize the header size even more and do away with
> subpackets, i.e. all codec-level audio packets get stored in their own
> muxer-level packet.
>
> b) Store byte lengths and sample lengths of each subpacket
> vlc-encoded. If packet size in bytes and/or in samples is fixed, then
> the spec should require that one or both be omitted.
>
> IMO, solution (a) is much cleaner, but probably sacrifices a bit on
> file size. Therefore, solution (b) might be more appropriate. But...if
> it's really worth having subpackets to minimize filesize overhead,
> perhaps it would be better to just make a more minimal form for audio
> packets to begin with.
IMHO a and b are not solutions at all
i mean if we have 10ms per subpacket & 50 subpackets then your suggestions
will allow 10ms precise seeking/cutting, thats fine but what if a audio codec
uses larger packets like 500ms per subpacket? iam sure that compression can
be improved with larger subpackets so this will very likely happen sooner or
later if its not allready done by some codecs
the only solution is to cut less precisse and specify the start/end-timestamps
indeed this is just a very simple play-list/cue-list
[...]
> Personally, if I had to cast a vote, I'd say call it COOLA and use
> .10l for the extension.
i vote for nut
[...]
Michael
More information about the MPlayer-dev-eng
mailing list