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

[Michael Niedermayer]

On Tue, Feb 12, 2008 at 08:37:21PM -0500, Rich Felker wrote:
> On Tue, Feb 12, 2008 at 08:24:21PM +0100, Michael Niedermayer wrote:
> > > 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
> 
> This design is highly inefficient for high bitrate streams. The
> efficient implementation is:

And why exactly is above inefficient? The kernel internally has its
own cache and prereads an appropriate amount, at least it should.
Duplicating the kernel cache seems rather the inefficient one. Also
its much more compelx ...
Also do you have some benchmarks, iam curious what the real difference
is.


[...]
> > 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.
> 
> That would make me happy. I would even be happy allowing sizes up to
> 4096 or so if you think it would help.

I think it would, especially with mpeg headers ... you know 00 00 01 blah
startcode shit ;)
Also see svn log, ive just added elision headers, comments welcome ...
Also time for nut to become a negative overhead container :)


[...]
> > > > 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!
> 
> PCM you mean?

yes


[...]
> > > > 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.
> 
> Well, until there's a free decoder there's a lot of interest in
> transcoding them, but maybe the free decoder will be done and ready
> for merge soon? :)

Well theres a AMR and QCELP decoder in SOC SVN, help finishing them is surely
welcome ...


> 
> > > 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.
> 
> Of course I don't want that in NUT. I suppose we should have a nice
> strong technical requirement to prevent it. How about just a limit to
> 4096 samples per frame? If one uses the maximum allowed frame size
> then, the overhead would be trivial (1 byte per 4096 bytes in the
> worst case, i.e. 0.025%, and much less with 16bit/stereo/etc.).

ok, ill add a 4096 sample limit


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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20080213/a4cbb8ea/attachment.pgp>