On Thu, Mar 02, 2006 at 04:29:50PM +0100, Michael Niedermayer wrote:
Hi
On Thu, Mar 02, 2006 at 01:25:38PM +0200, Oded Shimon wrote: [...]
EOR frames MUST be zero-length and must be set keyframe. All streams SHOULD end with EOR, where the pts of the EOR indicates the end presentation time of the final frame. An EOR set stream is unset by the first content frames. EOR can only be unset in streams with zero decode_delay . + has_checksum must be set if the frame is larger then 2*max_distance or its
I still feel this should be a seperate variable, the only reason you gave so far against it is that poor demuxers won't be able to decide... And IMO that's a very poor argument...
every additional field adds complexity, what do we gain here with that field? personally i would fix max_distance and not store it at all, as i fear people will set it to random values
? if (frame_size > 2*nut->max_distance)
if (frame_size > sc->max_size)
I fail to see the added complexity...
As for what do we gain - more freedom to the muxer, and the ability of limiting for ex. audio to a very small size and not increasing overhead, and limiting video to slightly higher to avoid additional overhead...
agree but only if we store all these max_size/distance stuff in u(16) so they cannot be arbitrary large
NO! They really need to be arbitrarily large! If you have a file where each frame is at least 5 megs, max_distance is useless unless it's well over 5 megs! If people set max_distance too high for their content, that just means their file will be very vulnerable to damage. This is a tradeoff that belongs in the hands of the user. If I am storing a private file where I insist on no damage and plan to throw away the file entirely and restore from backup if even 1 bit is damaged, there is no sense in me using a small max_distance. You're welcome to make nutlint complain if max_distance is larger than 32k, but it would probably be good to avoid doing this if max_distance is still smaller than 2*average_framesize or so. Rich