[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

[Oded Shimon]

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