[NUT-devel] [nut]: r604 - docs/nutissues.txt

[Michael Niedermayer]

On Tue, Feb 12, 2008 at 01:32:00PM -0500, Rich Felker wrote:
> On Tue, Feb 12, 2008 at 01:42:33PM +0100, Michael Niedermayer wrote:
> > On Tue, Feb 12, 2008 at 12:12:52AM -0500, Rich Felker wrote:
> > > On Tue, Feb 12, 2008 at 05:51:44AM +0100, Michael Niedermayer wrote:
> > > > > I'm
> > > > > absolutely against any proposal that precludes implementations from
> > > > > performing zero-copy decoding from the stream buffer.
> > > > 
> > > > Well if you have a buffer in which the frame is, just write the header
> > > > before it. If not just write the header and then (f)read() the rest.
> > > 
> > > I'm envisioning a model where the demuxer directly exports frames from
> > > their original location in the stream buffer. It's likely that this
> > > buffer needs to be treated as read-only. It might be mmapped from a
> > > file (in which case writing would invoke COW) 
> > 
> > COW would be invoked only if the kernel tries to keep the pages in some
> > sort of cache, otherwise there is absolutely no need for COW.
> 
> Even if not a copy, there'd be a page fault, which is expensive in
> itself.

true


> 
> > > or the previous frame
> > > might not yet be released by the caller (in which case, writing the
> > > header would clobber the contents of the previous frame) -- imagine
> > > for instance that we need to decode the next audio frame to buffer it,
> > > but aren't ready to decode the previous video frame yet.
> > 
> > I wonder if anyone will ever implement such a mmap system, at least it
> > will fail with files larger than 2gb on x86-linux and other sizes for other
> > platforms.
> 
> Nope, you only map the section of the stream that's still in use.
> Normally this will be several megs at most.
> 
> > Also such a system would need carefull use of madvise() to ensure
> > the kernel doesnt read pages through (slow) page faults or uses random
> > guessing of what pages can be discarded.
> 
> Indeed.
> 
> > > The reason I'm against this whole header compression thing is that it
> > > puts lots of nasty restraints on the demuxer implementation that
> > > preclude efficient design. 
> > 
> > The header compression only puts restraints on a AFAIK hypothetic design
> > not one actually existing?
> > And its not just the demuxer but the whole surrounding API which would
> > have to be designed for such mmap zero copy.
> 
> Precluding the optimal design is bad practice even if the optimal
> design has not yet been implemented anywhere. 

> Also keep in mind that
> what I said does NOT only apply to the mmap design but to a nice clean
> read-based design with low copying that probably IS similar to various
> current implementations.

I dont see how
It wouldnt affect libavformat, also it wouldnt affect the simple:
x= malloc(size+header)
put header in x
fread into x+header


> 
> > > The nasty cases can be special-cased to
> > > minimize their cost, but the tradeoff is implementation size and
> > > complexity. The only options I'm willing to consider (and which I
> > > still dislike) are:
> > > 
> > 
> > > A. Only allow header elision (a more correct name than compression)
> > > for frames below a very small size limit (e.g. small enough that the
> > > compression makes at least a 1% difference to space requirements).
> > 
> > That would be a compromise though iam not happy about it at all, its another
> > one of these idiotic philosophical restrictions. If the person muxing
> > decides that 0.5% overhead is more important than 0.5% time spend in
> > an HYPOHETICAL demuxer implementation
> 
> No, I already told you the issue here is not just time but buffer
> size. Requiring an unboundedly large buffer in addition to the main
> stream buffer is a potentially huge burden leading to all sorts of
> robustness issues. As long as the buffer size is bounded and small, no
> one really cares.

Seriously, i dont think that having 2 compressed frames instead of one
in memory is a significant burden, the uncomperssed ones are so much
bigger ...
But iam not that much interrested in huge frames, a simple
"header elision with frames > 1024 shall be considered an error"
would probably be ok.


> 
> > in his specific situation. Than
> > this is his decission and i wonder from where you take the arogance to
> > think you know better what is best for everyone else. And these are
> 
> It's NOT the business of the person making the file to put
> restrictions on the process reading the file. This has been one of my
> key issues for NUT since the beginning. Just because
> idiot_who_makes_file thinks the only purpose of the file is to watch
> it with player_x doesn't mean they're exempt from the features of NUT
> that make the file nicely usable for editing, optimal seeking, etc.

True if the world was just a bunch of warez kids leeching pr0n of bittorrent.

But lets take a big internet provider who wants to offer TV to their
customers and for that purpose gives everyone a HW decoder (the PCs being
to slow maybe ...) Why should that ISP not be able to make the ideal
decission during encoding for the decoders which he know everyone will be
using?


> 
> > > > > > +Issue small-frames
> > > > > > +------------------
> > > > > > +The original intent of nut frames was that 1 container frame == 1 codec
> > > > > > +frame. Though this does not seem to be explicitly written in nut.txt.
> > > > > 
> > > > > It is.
> > > > 
> > > > I thought so too but i searched, and didnt find it so where is it?
> > > 
> > > It's at least in nut-english.txt :)
> > 
> > It should be in nut.txt as well ...
> 
> If it's not feel free to add it, but I think it belongs in the
> information about codecs, since the definition of a frame is pretty
> codec-specific. Expressing the abstract idea in the semantic
> requirements section of nut.txt would be nice though!

I will as soon as the RAW frame issue is decided, unless i forget, in which
case please flame me!


> 
> > > > > > +Also it is inefficient for very small frames, AMR-NB for example has 6-32
> > > > > > +bytes per frame.
> > > > > 
> > > > > I don't think anyone really cares that much about efficiency when
> > > > > storing 
> > > > 
> > > > I do, others likely care about 10% overhead as well.
> > > 
> > > Care about it for what applications? For storing a master file in some
> > > odd barely-compressed audio form, I wouldn't care. For streaming radio
> > > or movie rips, of course it would matter, but I think someone would
> > > choose an appropriate codec for such applications..
> > 
> > Which codec would that be? (we are talking about 5-10kbit/sec).
> 
> Vorbis.

5kbit/sec ?


> 
> > > > > shit codecs
> > > > 
> > > > I think this applies more to audio codes, if it limited to coding shit
> > > > i wont bother and gladly leave it alone. ;)
> > > > 
> > > > > in NUT. Obviously any good codec will use large
> > > > > frame sizes 
> > > > 
> > > > no
> > > 
> > > Is there any audio codec of real interest with such small frame sizes?
> > 
> > AMR-NB has 6-32 byte frames see libavcodec/libamr.c
> > qcelp has 4-35 byte frames see soc/qcelp/qcelp_parser.c
> 
> And is there any interest in these codecs aside from watching files
> generated by camera phones and transcoding them to something sane?

Theres no sense in transcoding the audio. It just will reduce the quality
and very significantly increate the bitrate because the codecs you call
sane are VERY bad at such low bitrate.


> 
> > Iam not vetoing the decisson of 1frame=1frame for normal sized frames,
> > which was what we decided upon. I dont think tiny frames have been considered.
> > And we never planned to enforce 1frame=1frame for PCM. which is maybe
> > the reason why its not in the spec? A carelessly written rule would have
> > fatal consequences for PCM.
> 
> For PCM, there's no seeking issue because one always knows how to seek
> to an arbitrary sample in PCM 'frames'. In this case I would just
> recommend having a SHOULD clause that PCM frames SHOULD be same or
> shorter duration than the typical frame durations for other streams in
> the file (as a way of keeping interleaving clean and aiding players
> that don't want to do sample-resolution seeking inside PCM frames).

Well ...
I do have a AVI with all audio in a single chunk (something like 10 or 20mb), 
do you want that
.... in nut? mplayers avi demuxer can even seek in that avi :)

so honestly i dont think a should requirement alone would be a good idea.


[...]
> If you really want this header-elision, I'm willing to consider it for
> SMALL frames. But please don't flame about wanting to support it for
> large frames where it's absolutely useless and has lots of practical
> problems for efficient implementations!

Fine ill add it for small frames only. Would a 1024 byte limit be ok?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080212/5218e814/attachment.pgp>