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