[MPlayer-dev-eng] MPCF: sub_packet_size concerns

[Michael Niedermayer]

Hi

On Friday 14 February 2003 18:48, D Richard Felker III wrote:
> On Fri, Feb 14, 2003 at 05:51:36PM +0100, Michael Niedermayer wrote:
[...]
> > anyway isnt the number of samples per packet constant ? if not then we
> > need to think about this a bit
>
> Unfortunately, no. That's the reason why vorbis audio cannot be stored
> reliably in avi files. :( AVI (stupidly) requires either the bytes per
> frame, or else the decoded samples per frame, to be a constant.
i should definitively look more at audio coding docs ...

>
> > some possible solutions:
> > 1. limit the maximum length (in time) of a packet so that precisse enough
> > seeking is possible
>
> IMHO this is a very very bad solution; it could lead to serious a/v
> desync after multiple reencodes with seeking. And if container frames
> are short enough to make precise seeking possible, you'll only have a
> couple audio packets per frame, and so you'll get more overhead by
> using subpackets rather than less. :(
IMHO an encoder which just seeks to the closest audio & video keyframe, 
ignores their timestamps and puts them with timestamp = 0 in a file is 
broken, and subpackets with timestamps will just reduce the problem but not 
solve it

>
> > 2. add a optional timestamp or number of samples to the subpackets
>
> I like this option. Or just doing away with subpackets altogether.
i dont like this option ;)
and no subpackets means alot of overhead:
assuming we have a 64kbit/sec stream and 100byte packets then we have 80 
packets per second and perhaps ~5 bytes extra overhead per packet if we dont 
use subpackets (assuming we avoid storing startcodes for them otherwise we 
have another +8 bytes)
-> 400 byte/sec -> 1.4mb / hour (for 1 64kbit stream) 
if we have more streams (for different languages) than its alot more

>
> > 3. decode a whole packet and drop the samples until the point to which we
> > want to seek
>
> This is also very bad because you can't seek without the decoder.
> Think of mencoder -oac copy -ss foo.
yes, wheres the problem with it? u just seek to the packet & not the 
subpacket, and keep the timestamps for the packets, there is no desync, the 
fact that audio & video will start at slightly different timestamps cannot be 
avoided unless we reencode one of the streams

[...]

Michael