Hi On Thu, Mar 02, 2006 at 12:31:16PM -0500, Rich Felker wrote:
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!
are you drunk? if all frames are 5megs then max_distance==5mb will give you exactly the same file as any smaller max_distance, now if max_distance is set to 10mb you reduce the overhead by 1 syncpoint every 10mb, if its set to infinite you gain 2 syncpoints per 10mb and loose the ability to seek 1 syncpoint needs approximatly 8(startcode)+1(forw_ptr)+3(back_ptr)+4(pts) +4(crc) = 20byte are you seriously insisting on allowing the user to set max_distance higher then 5mb?! thats a maximum gain of 40byte per 10mb or 0.0003815% now i hope that the average windows kid will be smarter then rich and not come to the same conclusion that larger average frames somehow need larger max_distance, or otherwise we can forget the error recovering capabilities of nut in practice sorry but i wont continue these disscussions, expect me to fork if this continues, proposals should be judged on their effects (like overhead, complexity, error robustness, amount of memory or computations or delay , ...) but not on philosophical ones, nonexisting codecs, nonexisting demuxer architectures, nonexisiting kernels and so on my proposed header compression, which has negligible complexity would reduce the overhead by ~1% and was rejected based on nonexistant kernel and demuxer architectures so either 0.0003815% is significnat that my header compression will go into the spec or arbirary sized max_distance leaves it, choose, but stop to change the rules for each thing depening upon if you like it or not [...] -- Michael