On Thu, Mar 02, 2006 at 11:55:41AM +0100, Michael Niedermayer wrote:
On Thu, Mar 02, 2006 at 10:38:54AM +0200, Oded Shimon wrote:
On Wed, Mar 01, 2006 at 03:19:40PM +0100, Michael Niedermayer CVS wrote:
comments, flames?
I'm not strongly against anything here, but it would've been better if you would have showed the patch (and resolved conflicts) before committing... :/
i did post a patch and adapted it based on comments ...
Yes but there was obviously still some controversy over some parts of the patch when you committed..
+file: + file_id_string + while(bytes_left > 8){
I'm a bit weirded out by this, In a very extreme and silly example, in a truncated NUT file you could loose the last frame because it (and the frame header) was smaller than 8 bytes...
cut randomly -> u very likely loose something as it has been cut in the middle cut after a frame -> why dont you just add 8 zero bytes then too if you already do parse things? anyway, if you and rich want we could add the thing back in the index but before the reserved bytes and store a index packet with 0 syncpoints and reserved_bytes always none at the end or do you have a alternative idea?
No real ideas, and I agree that my example was very silly. I just don't like special casing demuxing right before the end. The demuxer should always base demuxing on the next startcode/framecode ...
@@ -474,12 +508,15 @@ 1 is_key if set, frame is keyframe 2 end_of_relevance if set, stream has no relevance on presentation. (EOR) + 4 has_checksum if set then the frame header contains a checksum
Like I said, this should be a NUT flag...
and i disagree
You lost me on this one.. Is it because of coded_stream_flags ?.. It might be a good idea to modify that so it can accept NUT flags as well, but has_checksum is very obviously a NUT flag, not a stream flag..
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... - ods15