Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926 Modified: trunk/DOCS/tech/nut.txt Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Tue Nov 14 18:03:33 2006 @@ -187,11 +187,15 @@ packet_header, index_packet, packet_footer } if (!eof) while(next_code != main_startcode){ - if(next_code == syncpoint_startcode){ - packet_header, syncpoint, packet_footer - } - frame + packet_header, syncpoint, packet_footer + do{ + frame + }while(next_code == framecode); reserved_headers + while(next_code == info_startcode){ + packet_header, info_packet, packet_footer + reserved_headers + } } } @@ -883,9 +887,15 @@ Info: ----- -If a info packet is stored anywhere then a muxer MUST also store an identical +All info packets stored after a main header set MUST also have an identical info packet after every main-stream-header set +All info packets not stored after a main header set MUST have +chapter_id!=0 . + +Info packets SHOULD be written after main header sets in non realtime +streams. + If a demuxer has seen several info packets with the same chapter_id and stream_id then it MUST ignore all but the one with the highest position in the file
Hi On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926
Modified: trunk/DOCS/tech/nut.txt
Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams
reverse this at once! not a single person has agreed to this change except you you cannot just change the (frozen) spec at will, next time someone is pissed at the dts ordering rule and changes it to a SHOULD to have audio packets 1 sec before video [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926
Modified: trunk/DOCS/tech/nut.txt
Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams
reverse this at once! not a single person has agreed to this change except you
you cannot just change the (frozen) spec at will, next time someone is pissed at the dts ordering rule and changes it to a SHOULD to have audio packets 1 sec before video
Hmm... does NUT require strict monotony of DTS even between streams? That is not good. Many hardware MPEG decoders require video to be about 80ms ahead of audio. Guess I'll just have to stick with MPEG-TS for those then... -- Måns Rullgård mru@inprovide.com
Hi On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926
Modified: trunk/DOCS/tech/nut.txt
Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams
reverse this at once! not a single person has agreed to this change except you
you cannot just change the (frozen) spec at will, next time someone is pissed at the dts ordering rule and changes it to a SHOULD to have audio packets 1 sec before video
Hmm... does NUT require strict monotony of DTS even between streams?
not exactly but something similar: Pts of all frames in all streams MUST be bigger or equal to dts of all previous frames in all streams, compared in common timebase. (EOR frames are NOT exempt from this rule) why we ended up with this and not strict dts ordering is something i dont remember, but it doesnt seem like pts-dts vs dts-dts makes a big difference
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? 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) additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?) and specifying exactly what delay there should be would again not really change a thing or?
Guess I'll just have to stick with MPEG-TS for those then...
you will never use anything except mpeg no matter what advantages or disadvantages the formats have and iam not saying nut is better then mpeg in all cases, just in most :) more specifcially that is * smaller overhead * you can actually seek to a specific time (in mpeg thanks to timestamp discontinuities you cant) * you can seek to keyframes (in mpeg you MUST have many keyframes or live with several second delay for seeking on slow media) * 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 :)))))) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926
Modified: trunk/DOCS/tech/nut.txt
Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams
reverse this at once! not a single person has agreed to this change except you
you cannot just change the (frozen) spec at will, next time someone is pissed at the dts ordering rule and changes it to a SHOULD to have audio packets 1 sec before video
Hmm... does NUT require strict monotony of DTS even between streams?
not exactly but something similar: Pts of all frames in all streams MUST be bigger or equal to dts of all previous frames in all streams, compared in common timebase. (EOR frames are NOT exempt from this rule)
why we ended up with this and not strict dts ordering is something i dont remember, but it doesnt seem like pts-dts vs dts-dts makes a big difference
I'll have to think about that a bit...
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?
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.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
Guess I'll just have to stick with MPEG-TS for those then...
you will never use anything except mpeg no matter what advantages
I will use whatever works best for the problem at hand. Quite frequently, that happens to be MPEG.
or disadvantages the formats have and iam not saying nut is better then mpeg in all cases, just in most :)
more specifcially that is * smaller overhead
Yes, the overhead is smaller. That can't be argued. MPEG-TS was never intended to have a small overhead. The main goal was that it should work well for broadcast applications with frequent packet loss.
* you can actually seek to a specific time (in mpeg thanks to timestamp discontinuities you cant)
You obviously haven't seen the set top boxes we make at work.
* 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.
* 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. -- Måns Rullgård mru@inprovide.com
Hi On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@gmx.at> writes: [...]
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?
they dont, its just that hw which has been designed solely for the purpose of demuxing and decoding mpeg cant be expected to support non mpeg be it nut or something else
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.
dont these hw decoders need a few 100kb sized buffer to workaround the arificial vbv rules?
I wasn't aware that NUT was intended exclusively for software decoders with huge buffers.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
and a constant delay (which doesnt match _your_ decoder) would help? how? or should every nut file contain a arbitrary delay at the users discretion, mpeg doesnt do that either it specifies the vbv rules and decoders be it hw or sw are then designed to somehow demux and decode the result, if they need extra buffering to deal with it (every sw decoder i know of does) so be it [...]
* you can actually seek to a specific time (in mpeg thanks to timestamp discontinuities you cant)
You obviously haven't seen the set top boxes we make at work.
they can seek to a specific frame?
* 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.
10ms? for exact seeking in mpeg you need (assuming there are no timestamp discontinuiies) a binary search (10ms seek per step at least assuimg local storeage, if its a slow cdrom, LAN, or the internet that will be significantly slower, and you need 5-10 such steps) then you need a linear search to the next or previous keyframe (with the 12frame gops commonly used in mpeg thats <500ms with normal common 300frame gops that can take 5-10seconds if your channel is as fast as the bitrate of your stream) now with an index be it one in avi, mov,nut, matroska or anything else seeks are instantaneous the difference is in seconds to mpeg not milliseconds sure you can require 2 keyframes per second (like everyone who uses mpeg does) but still the difference should be on the order of >200ms not 10ms
* 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.
did you ever read any ITU or ISO mailinglists? there are plenty of disscussions of people both members of the standard comitees and outside who dont understand or missunderstand the specs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Hi Michael Niedermayer wrote:
[...]
* 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 :))))))
Is it broken ? What is needed ?
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.
did you ever read any ITU or ISO mailinglists? there are plenty of disscussions of people both members of the standard comitees and outside who dont understand or missunderstand the specs
Oh, how is it possible to access those mailing lists ? Are you subscribed to many of them ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier said:
Hi
Michael Niedermayer wrote:
[...]
* 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 :))))))
Is it broken ? What is needed ?
It's not working very well. A complete rewrite is probably the best solution.
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.
did you ever read any ITU or ISO mailinglists? there are plenty of disscussions of people both members of the standard comitees and outside who dont understand or missunderstand the specs
I've seen such discussions, even started some myself. The result is usually an amendment to the spec clarifying things.
Oh, how is it possible to access those mailing lists ? Are you subscribed to many of them ?
A couple of lists that can be useful: http://mailman.rwth-aachen.de/mailman/listinfo/jvt-experts http://lists.mpegif.org/mailman/listinfo/mp4-tech -- Måns Rullgård mru@inprovide.com
Michael Niedermayer said:
Hi
On Wed, Nov 15, 2006 at 02:45:04AM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@gmx.at> writes: [...]
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?
they dont, its just that hw which has been designed solely for the purpose of demuxing and decoding mpeg cant be expected to support non mpeg be it nut or something else
I was considering the possibility of future hardware supporting NUT.
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.
dont these hw decoders need a few 100kb sized buffer to workaround the arificial vbv rules?
Call it workarounds if you like. Yes, there are some buffers. That doesn't mean there are infinite amounts of memory available for more buffers.
I wasn't aware that NUT was intended exclusively for software decoders with huge buffers.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
and a constant delay (which doesnt match _your_ decoder) would help? how? or should every nut file contain a arbitrary delay at the users discretion, mpeg doesnt do that either it specifies the vbv rules and decoders be it hw or sw are then designed to somehow demux and decode the result, if they need extra buffering to deal with it (every sw decoder i know of does) so be it
These cheap hardware decoders will of course not be able to handle *any* stream. The difference between MPEG and NUT is that it is possible to create a valid MPEG stream with the necessary constraints. The data sheet for a decoder tells you what the requirements are, and you can then make sure that the streams meet those requirements, or choose a decoder that can handle your streams. MPEG is often used in closed systems, or in systems will very well defined constraints. I see no reason why (a future, complete) NUT wouldn't be suitable as a base format in such systems.
* you can actually seek to a specific time (in mpeg thanks to timestamp discontinuities you cant)
You obviously haven't seen the set top boxes we make at work.
they can seek to a specific frame?
Yes.
* 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.
10ms? for exact seeking in mpeg you need (assuming there are no timestamp discontinuiies) a binary search (10ms seek per step at least assuimg local storeage, if its a slow cdrom, LAN, or the internet that will be significantly slower, and you need 5-10 such steps) then you need a linear search to the next or previous keyframe (with the 12frame gops commonly used in mpeg thats <500ms with normal common 300frame gops that can take 5-10seconds if your channel is as fast as the bitrate of your stream)
now with an index be it one in avi, mov,nut, matroska or anything else seeks are instantaneous the difference is in seconds to mpeg not milliseconds sure you can require 2 keyframes per second (like everyone who uses mpeg does) but still the difference should be on the order of >200ms not 10ms
Oh, 200ms is a terribly long time. It would be really boring waiting all that time for a seek to finish.
* 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.
did you ever read any ITU or ISO mailinglists? there are plenty of disscussions of people both members of the standard comitees and outside who dont understand or missunderstand the specs
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is _______________________________________________ NUT-devel mailing list NUT-devel@mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
-- Måns Rullgård mru@inprovide.com
Hi On Wed, Nov 15, 2006 at 01:47:07PM -0000, Måns Rullgård wrote: [...]
I wasn't aware that NUT was intended exclusively for software decoders with huge buffers.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
and a constant delay (which doesnt match _your_ decoder) would help? how? or should every nut file contain a arbitrary delay at the users discretion, mpeg doesnt do that either it specifies the vbv rules and decoders be it hw or sw are then designed to somehow demux and decode the result, if they need extra buffering to deal with it (every sw decoder i know of does) so be it
These cheap hardware decoders will of course not be able to handle *any* stream. The difference between MPEG and NUT is that it is possible to create a valid MPEG stream with the necessary constraints. The data sheet for a decoder tells you what the requirements are, and you can then make sure that the streams meet those requirements, or choose a decoder that can handle your streams.
MPEG is often used in closed systems, or in systems will very well defined constraints. I see no reason why (a future, complete) NUT wouldn't be suitable as a base format in such systems.
well, is the dts ordering the only thing preventing use of nut in such a system? would addition of a delay field to each stream header which would then be added to all timestamps in that stream solve the issue? would a maximum 250ms on such a field be enough? and some additional rule like delay MUST be 0 unless the file is encoded for a specific specification requireing a larger delay? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Wed, Nov 15, 2006 at 01:47:07PM -0000, Måns Rullgård wrote: [...]
I wasn't aware that NUT was intended exclusively for software decoders with huge buffers.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
and a constant delay (which doesnt match _your_ decoder) would help? how? or should every nut file contain a arbitrary delay at the users discretion, mpeg doesnt do that either it specifies the vbv rules and decoders be it hw or sw are then designed to somehow demux and decode the result, if they need extra buffering to deal with it (every sw decoder i know of does) so be it
These cheap hardware decoders will of course not be able to handle *any* stream. The difference between MPEG and NUT is that it is possible to create a valid MPEG stream with the necessary constraints. The data sheet for a decoder tells you what the requirements are, and you can then make sure that the streams meet those requirements, or choose a decoder that can handle your streams.
MPEG is often used in closed systems, or in systems will very well defined constraints. I see no reason why (a future, complete) NUT wouldn't be suitable as a base format in such systems.
well, is the dts ordering the only thing preventing use of nut in such a system?
The answer to that obviously depends on the exact system, and on what other rules NUT has.
would addition of a delay field to each stream header which would then be added to all timestamps in that stream solve the issue? would a maximum 250ms on such a field be enough? and some additional rule like delay MUST be 0 unless the file is encoded for a specific specification requireing a larger delay?
That seems unnecessarily complicated. Simply allowing an offset between streams would be enough. A global header could give a maximum value for the offset in the file. There is no need to require a constant offset, even though I can't immediately think of a situation that would benefit from it being variable. Placing a reasonable hard upper bound would still make non-interleaved files invalid. -- Måns Rullgård mru@inprovide.com
On Wed, Nov 15, 2006 at 04:50:13PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Nov 15, 2006 at 01:47:07PM -0000, Måns Rullgård wrote: [...]
I wasn't aware that NUT was intended exclusively for software decoders with huge buffers.
additionally having audio and video with arbitrary delay will not reduce the problem but rather make it worse (i think you agree here?)
and specifying exactly what delay there should be would again not really change a thing or?
The spec could allow for a constant offset between streams, possibly specified in a header field. I can't think of a case where variable delay would make sense.
and a constant delay (which doesnt match _your_ decoder) would help? how? or should every nut file contain a arbitrary delay at the users discretion, mpeg doesnt do that either it specifies the vbv rules and decoders be it hw or sw are then designed to somehow demux and decode the result, if they need extra buffering to deal with it (every sw decoder i know of does) so be it
These cheap hardware decoders will of course not be able to handle *any* stream. The difference between MPEG and NUT is that it is possible to create a valid MPEG stream with the necessary constraints. The data sheet for a decoder tells you what the requirements are, and you can then make sure that the streams meet those requirements, or choose a decoder that can handle your streams.
MPEG is often used in closed systems, or in systems will very well defined constraints. I see no reason why (a future, complete) NUT wouldn't be suitable as a base format in such systems.
well, is the dts ordering the only thing preventing use of nut in such a system? would addition of a delay field to each stream header which would then be added to all timestamps in that stream solve the issue? would a maximum 250ms on such a field be enough? and some additional rule like delay MUST be 0 unless the file is encoded for a specific specification requireing a larger delay?
BTW, I'm against this - if nothing else, we spent a lot of time calculating and figuring out the syncpoint stuff to make sure exact seeking always works. If we did this, we'd have to revisit the issue and make sure nothing breaks. BTW, a fake large decode_delay for the audio stream causes an audio preload. but it is ofcourse illegal. - ods15
On Wed, Nov 15, 2006 at 09:22:05PM +0200, Oded Shimon wrote:
MPEG is often used in closed systems, or in systems will very well defined constraints. I see no reason why (a future, complete) NUT wouldn't be suitable as a base format in such systems.
well, is the dts ordering the only thing preventing use of nut in such a system? would addition of a delay field to each stream header which would then be added to all timestamps in that stream solve the issue? would a maximum 250ms on such a field be enough? and some additional rule like delay MUST be 0 unless the file is encoded for a specific specification requireing a larger delay?
BTW, I'm against this - if nothing else, we spent a lot of time calculating and figuring out the syncpoint stuff to make sure exact seeking always works. If we did this, we'd have to revisit the issue and make sure nothing breaks. BTW, a fake large decode_delay for the audio stream causes an audio preload. but it is ofcourse illegal.
Any nonzero offset between streams is absolutely totally out of the question for reasosn I described in other posts. There's no need to even consider this topic. Can we drop this useless thread? Rich
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
On Wed, Nov 15, 2006 at 02:50:35AM +0100, Michael Niedermayer wrote:
Hi
On Tue, Nov 14, 2006 at 11:42:40PM +0000, Måns Rullgård wrote:
Michael Niedermayer <michaelni@gmx.at> writes:
Hi
On Tue, Nov 14, 2006 at 06:03:37PM +0100, ods15 wrote:
Author: ods15 Date: Tue Nov 14 18:03:33 2006 New Revision: 20926
Modified: trunk/DOCS/tech/nut.txt
Log: allow info packets to appear in mid-stream, outside of main headers. these SHOULD NOT appear in non-realtime-streams
reverse this at once! not a single person has agreed to this change except you
you cannot just change the (frozen) spec at will, next time someone is pissed at the dts ordering rule and changes it to a SHOULD to have audio packets 1 sec before video
Hmm... does NUT require strict monotony of DTS even between streams?
not exactly but something similar: Pts of all frames in all streams MUST be bigger or equal to dts of all previous frames in all streams, compared in common timebase. (EOR frames are NOT exempt from this rule)
why we ended up with this and not strict dts ordering is something i dont remember, but it doesnt seem like pts-dts vs dts-dts makes a big difference
subtitle stream with b-frames and gaps. - ods15
participants (6)
-
Baptiste Coudurier -
Michael Niedermayer -
Måns Rullgård -
Oded Shimon -
ods15 -
Rich Felker