On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård
wrote:
> >> That is not good. Many hardware MPEG decoders
require video to be
> >> about 80ms ahead of audio.
> >
> > since when does a _MPEG_ decoder support nut
streams?
>
> Since when do the NUT goals exclude certain
applications domains
> entirely?
It doesn't, but NUT is not for making device-specific files.
Any
particular delay/offset between streams is a DEVICE-SPECIFIC
hack that
does not belong in a device-independent format.
> > now if it doesnt then what relevance has that
comment? none?
> > and if you meant that demuxing is done in software
and than the ES are
> > sent to the HW then you can just buffer these 80ms
audio (it just needs
> > a 4kb buffer assuming ~200kbit audio)
>
> In the chips I'm talking about demuxing is done in
hardware. If
> someone wanted to make a hardware decoder with NUT
demuxer, there
> could be trouble because of this restriction. The
reason for the
> offset is that the audio and video decoders have
different delays, and
> buffers have to be kept to a minimum. Even 4kB can be
a lot of space
> in these devices.
>
> I wasn't aware that NUT was intended exclusively for
software decoders
> with huge buffers.
It's not. Just make your hardware decoder correctly without
delay and
you have no problem. 0 delay is the only natural value.
Anything else
is device-dependent. Again, NUT files are not
device-dependent. Even
if NUT did support having an offset between audio/video
times, only
files created with the "correct" offset for the
particular device
would be playable on the device. Other files would fail to
play. This
is a hopelessly broken situation.
The solution is to simply require that the offset be 0. It
is
_possible_ to make hardware that operates like this with no
buffer.
Any other arbitrarily-chosen offset aside from 0 would be
wrong
because it would be linked to a particular real-world
timescale with
units rather than a unitless quantity (0).
> > * you can seek to keyframes (in mpeg you MUST have
many keyframes or
> > live with several second delay for seeking on
slow media)
>
> You seem to be very concerned about seeking.
Personally, I use seek
> functions less than once per hour of video. When I do
use seeking, I
> don't really care if it takes 10ms longer to find the
right spot, or
> exactly where it lands.
When you do seek, you usually do it several times to get to
the exact
spot you want. And we're not talking 10ms longer but several
seconds!!
> > * you can store any codec, mpeg limits you to
mpeg1/mpeg2/h264/ac3
> > and a few other standard ones
> > * muxing is MUCH easier (btw if you disagree
please help me fix the broken
> > mpeg-ts muxer in ffmpeg  )))))
>
> A prerequisite of muxing is understanding the spec. As
far as anyone
> knows, this has never happened for NUT. You and Oded
arguing over
> what things mean are proof of this.
...
Rich
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|