Hi, While reading the spec, I noticed a few things that could improve readability IMHO: 1.) It would be handy to have the type mentioned after each tag in the tag description section. It is tiresome to have to scroll back each time. e.g. chapter_id (s) stream_class (v) fourcc (vb) et cetera 2.) The first column of the frame_flags table is called Bit, but there is no such thing as the 4096th bit of a 64-bit value. I suggest changing the column-heading to Mask or change the column-entries to represent the bit number (i.e. 0, 1, 3, 4, 5, 6, 7, 12, 13). 3.) There is no explanation of what EOR actually means. I could change 1.) and 2.) if nobody objects. For 3.) I need an explanation first :-) --Ivo
Hi On Fri, Nov 24, 2006 at 12:50:13PM +0100, Ivo wrote:
Hi,
While reading the spec, I noticed a few things that could improve readability IMHO:
1.) It would be handy to have the type mentioned after each tag in the tag description section. It is tiresome to have to scroll back each time. e.g. chapter_id (s) stream_class (v) fourcc (vb) et cetera
ok
2.) The first column of the frame_flags table is called Bit, but there is no such thing as the 4096th bit of a 64-bit value. I suggest changing the column-heading to Mask or change the column-entries to represent the bit number (i.e. 0, 1, 3, 4, 5, 6, 7, 12, 13).
ok
3.) There is no explanation of what EOR actually means.
end of relevance pretty much marks the start of a gap in a stream (no video or no audio or no subtitles until the next keyframe) it is (with the exception of a EOR after the very last frame) AFAIK relatively nut specific (= will probably never be used by anyone) * nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file * converting non nut to nut will not contain EOR except for marking the duration of the very last frame * lav* does not support it (and i dont plan to change that), for lav* gaps are not allowed, you will have to encode black/silence/no subs keyframes (which require only negligible storeage anyway) * EOR breaks the ability to cut and merge nut files by simply adding and removing headers personally i would drop EOR from nut for anything but the very last frame [...] -- 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
On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael Niedermayer wrote:
3.) There is no explanation of what EOR actually means.
end of relevance pretty much marks the start of a gap in a stream (no video or no audio or no subtitles until the next keyframe) it is (with the exception of a EOR after the very last frame) AFAIK relatively nut specific (= will probably never be used by anyone)
It's absolutely needed for subitles or seeking performance will be utterly abysmal. Consider a movie with 5 subtitles at 5minutes and 5 subtiles at 70 minutes and none in between (yes I actually have a movie like this). We wouldn't have added it if it weren't actually needed. I would personally prefer to forbid EOR for audio and video for the time being except as a marker of final frame duration. If we ever see a need we could later allow them but it was never my intention to create a system for ugly special nut-specific semantics.
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
* converting non nut to nut will not contain EOR except for marking the duration of the very last frame
It doesn't have to since these other containers suck and don't care about being able to synchronize subtitles on seeking.
* lav* does not support it (and i dont plan to change that), for lav* gaps are not allowed, you will have to encode black/silence/no subs keyframes (which require only negligible storeage anyway)
The nut muxer should automatically generate EOR for subtitles and not use it anywhere else (except perhaps eof). Just repeating an 'empty' subtitle every few seconds is an ugly hack.
* EOR breaks the ability to cut and merge nut files by simply adding and removing headers
personally i would drop EOR from nut for anything but the very last frame
I think you missed the whole part about it being absolutely essential for subtitles and seeking... Rich
On Friday 24 November 2006 17:14, Rich Felker wrote:
On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael Niedermayer wrote:
3.) There is no explanation of what EOR actually means.
end of relevance pretty much marks the start of a gap in a stream (no video or no audio or no subtitles until the next keyframe) it is (with the exception of a EOR after the very last frame) AFAIK relatively nut specific (= will probably never be used by anyone)
It's absolutely needed for subitles or seeking performance will be utterly abysmal. Consider a movie with 5 subtitles at 5minutes and 5 subtiles at 70 minutes and none in between (yes I actually have a movie like this). We wouldn't have added it if it weren't actually needed.
I would personally prefer to forbid EOR for audio and video for the time being except as a marker of final frame duration. If we ever see a need we could later allow them but it was never my intention to create a system for ugly special nut-specific semantics.
[...]
The nut muxer should automatically generate EOR for subtitles and not use it anywhere else (except perhaps eof). Just repeating an 'empty' subtitle every few seconds is an ugly hack.
How about this: Index: nut.txt =================================================================== --- nut.txt (revision 21193) +++ nut.txt (working copy) @@ -601,11 +601,16 @@ 12 FLAG_CODED if set, coded_flags are stored in the frame header. 13 FLAG_INVALID if set, frame_code is invalid. + A frame with FLAG_EOR set marks the beginning of a gap in a stream. EOR frames MUST be zero-length and must be set keyframe. All streams SHOULD end with EOR, where the pts of the EOR indicates the end presentation time of the final frame. An EOR set stream is unset by the first content frames. EOR can only be unset in streams with zero decode_delay . + A muxer SHOULD use EOR frames for subtitle streams to mark large periods + where subtitles are absent. + EOR frames for non-subtitle streams are only valid at the end of the + stream. FLAG_CHECKSUM MUST be set if the frame's data_size is strictly greater than 2*max_distance or the difference abs(pts-last_pts) is strictly greater than max_pts_distance (where pts represents this frame's pts and last_pts is
On Fri, Nov 24, 2006 at 06:37:33PM +0100, Ivo wrote:
How about this:
Index: nut.txt =================================================================== --- nut.txt (revision 21193) +++ nut.txt (working copy) @@ -601,11 +601,16 @@ 12 FLAG_CODED if set, coded_flags are stored in the frame header. 13 FLAG_INVALID if set, frame_code is invalid.
+ A frame with FLAG_EOR set marks the beginning of a gap in a stream. EOR frames MUST be zero-length and must be set keyframe. All streams SHOULD end with EOR, where the pts of the EOR indicates the end presentation time of the final frame. An EOR set stream is unset by the first content frames. EOR can only be unset in streams with zero decode_delay . + A muxer SHOULD use EOR frames for subtitle streams to mark large periods + where subtitles are absent.
s/large//
+ EOR frames for non-subtitle streams are only valid at the end of the + stream.
It would be nice to have a note that they are syntactically valid but that they need not be interpreted for compliance with the current version of NUT and that processes generating NUT files MUST NOT write EOR for non-subtitle streams. Rich
On Friday 24 November 2006 19:34, Rich Felker wrote:
On Fri, Nov 24, 2006 at 06:37:33PM +0100, Ivo wrote:
+ A muxer SHOULD use EOR frames for subtitle streams to mark large periods + where subtitles are absent.
s/large//
Changed locally.
+ EOR frames for non-subtitle streams are only valid at the end of the + stream.
It would be nice to have a note that they are syntactically valid but that they need not be interpreted for compliance with the current version of NUT and that processes generating NUT files MUST NOT write EOR for non-subtitle streams.
Perhaps: EOR frames for non-subtitle streams are syntactically valid, but, except for the last frame, they SHOULD be ignored by demuxers and MUST NOT be written by muxers. Or: EOR frames for non-subtitle streams MUST NOT be written by muxers and SHOULD be ignored by demuxers, except for the last frame. ? --Ivo
On Fri, Nov 24, 2006 at 09:26:00PM +0100, Ivo wrote:
+ EOR frames for non-subtitle streams are only valid at the end of the + stream.
It would be nice to have a note that they are syntactically valid but that they need not be interpreted for compliance with the current version of NUT and that processes generating NUT files MUST NOT write EOR for non-subtitle streams.
Perhaps:
EOR frames for non-subtitle streams are syntactically valid, but, except for the last frame, they SHOULD be ignored by demuxers and MUST NOT be written by muxers.
No, ignoring them is semantically incorrect. Interpreting them should just be completely outside the scope of the NUT 1.x spec. If we ever make a NUT 2.0, at that time it might or might not make sense to assign the natural meaning to them, but I'd be inclined against it still. In any case there's no reason to make any specification about what a demuxer should do when it encounters data that's forbidden by the requirements on the muxer. It's as stupid as the #1 spam-friendly contradiction in ESMTP RFC, which says that the sender must use a valid name in HELO, but also mandates that receiver must accept any syntactically correct name in HELO... Rich
On Saturday 25 November 2006 04:41, Rich Felker wrote:
On Fri, Nov 24, 2006 at 09:26:00PM +0100, Ivo wrote:
+ EOR frames for non-subtitle streams are only valid at the end of the + stream.
It would be nice to have a note that they are syntactically valid but that they need not be interpreted for compliance with the current version of NUT and that processes generating NUT files MUST NOT write EOR for non-subtitle streams.
Perhaps:
EOR frames for non-subtitle streams are syntactically valid, but, except for the last frame, they SHOULD be ignored by demuxers and MUST NOT be written by muxers.
No, ignoring them is semantically incorrect. Interpreting them should just be completely outside the scope of the NUT 1.x spec. If we ever make a NUT 2.0, at that time it might or might not make sense to assign the natural meaning to them, but I'd be inclined against it still.
I see. I misunderstood "need not be interpreted". Next try: + Muxers MUST NOT write EOR frames for non-subtitle streams, except for the + last frame. This implies that demuxers will never encounter EOR frames in the middle of non-subtitle streams, and hence need not to interpret them. --Ivo
Hi On Fri, Nov 24, 2006 at 11:14:58AM -0500, Rich Felker wrote:
On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael Niedermayer wrote:
3.) There is no explanation of what EOR actually means.
end of relevance pretty much marks the start of a gap in a stream (no video or no audio or no subtitles until the next keyframe) it is (with the exception of a EOR after the very last frame) AFAIK relatively nut specific (= will probably never be used by anyone)
It's absolutely needed for subitles or seeking performance will be utterly abysmal. Consider a movie with 5 subtitles at 5minutes and 5 subtiles at 70 minutes and none in between (yes I actually have a movie like this). We wouldn't have added it if it weren't actually needed.
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true? just try: Sub: K K Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF you can either A. ignore the subs and seek purely based on the video stream (will not display subs after seeking) B. seek to previous keyframe of all streams (will not allow you to seek into the 2 hour segment without sub keyframes
* lav* does not support it (and i dont plan to change that), for lav* gaps are not allowed, you will have to encode black/silence/no subs keyframes (which require only negligible storeage anyway)
The nut muxer should automatically generate EOR for subtitles and not use it anywhere else (except perhaps eof). Just repeating an 'empty' subtitle every few seconds is an ugly hack.
IMHO EOR is a ugly hack, puting keyframes where you want to seek to is the correct thing to do also if you have a special case for "whole screen transparent" then why not for black frames or no audio? or gray frames or white frames ... this does make at least as much sense as for subtitles, think of a audio stream with music, one with actors voices, one with commentary, one with special effects, ... having this split would be VERY nice, and these streams would have alot of large gaps which would benefit from EOR [...] -- 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
On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles. NUT's back_ptr is the mechanism by which NUT makes this possible, but without EOR it will ruin seeking in files without extremely frequent subtitles.
just try:
Sub: K K Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
you can either A. ignore the subs and seek purely based on the video stream (will not display subs after seeking) B. seek to previous keyframe of all streams (will not allow you to seek into the 2 hour segment without sub keyframes
Having the same subtitle displayed for 2 hours duration (or even more than 5-10 seconds duration) is nonsense. If you meant for the subtitle at the beginning in your example to only be briefly displayed, then no subs for the next 2 hours, EOR is what allows NUT to accomplish that! The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes. BTW, for subtitles, EOR is nothing more than a fake empty keyframe after every syncpoint. It's just a shorthand notation where they don't actually have to be stored, and it makes it easier (with index, at least) to find all the actual _real_ subtitle frames if you want to extract them.
* lav* does not support it (and i dont plan to change that), for lav* gaps are not allowed, you will have to encode black/silence/no subs keyframes (which require only negligible storeage anyway)
The nut muxer should automatically generate EOR for subtitles and not use it anywhere else (except perhaps eof). Just repeating an 'empty' subtitle every few seconds is an ugly hack.
IMHO EOR is a ugly hack, puting keyframes where you want to seek to is the correct thing to do
No, flooding the stream with a bunch of fake subtitle keyframes is the ugly hack. It's a huge waste of bandwidth and requires _more_ special casing by the muxer, not less. EOR is very simple to handle and fits in with all the existing semantics. That's why we were able to add it when the issue came up.
also if you have a special case for "whole screen transparent" then why not for black frames or no audio? or gray frames or white frames ... this does make at least as much sense as for subtitles, think of a audio stream with music, one with actors voices, one with commentary, one with special effects, ... having this split would be VERY nice, and these streams would have alot of large gaps which would benefit from EOR
They would, that's why I don't want to rule out supporting it in the future. But at this time it seems utterly incompatible with most player designs, and mandating support for it seems like a bad idea. I wouldn't mind offering support in an "advanced profile" or something, but I don't know if we want to go there yet... It seems like we could at least wait until the NUT 1.0 spec is out the door to start worrying about more advanced profiles that could be difficult for existing players to support... Rich
Hi On Fri, Nov 24, 2006 at 10:58:20PM -0500, Rich Felker wrote:
On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
NUT's back_ptr is the mechanism by which NUT makes this possible, but without EOR it will ruin seeking in files without extremely frequent subtitles.
just try:
Sub: K K Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
you can either A. ignore the subs and seek purely based on the video stream (will not display subs after seeking) B. seek to previous keyframe of all streams (will not allow you to seek into the 2 hour segment without sub keyframes
Having the same subtitle displayed for 2 hours duration (or even more than 5-10 seconds duration) is nonsense. If you meant for the subtitle at the beginning in your example to only be briefly displayed, then no subs for the next 2 hours, EOR is what allows NUT to accomplish that!
my example is about a non nut container, and what is displayed or not between the keyframes of the subtitle stream is NOT known to the demuxer (and neither to the nut muxer which should mux that, unless it parses the subtitle stream ...)
The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes.
yes, ~1000 small (<10byte) keyframes whos position in time matches the video keyframes would be the correct solution, needing 10kb for 2 hours is negligible its a mere ~ 0.01 kbit/sec if you have several streams with normal keyframe distances (10sec / 300frame) and the keyframes are not aligned relative to each other then you _CANNOT_ seek correctly, EOR does not help heres a example: vid1 KFF...10sec...FFKFF vid2 FF..5sec..FKF...10sec... to seek and display both streams you will have to _DECODE_ 5 seconds of video which with high resolution will need about 5seconds ... if one stream is a subtitle stream and one a video stream then the VERY same happens example: syncp S S S S S backptr v------/ / / v-------------------- vid KFKFFFFFFFFFFFFFFFFFFFFFFFFFFK sub K F F F K F F F seek target ^ for the seek target the last syncpoint is choosen, its back ptr points to the second sync point, decoding from there will give you a video keyframe after that there are maybe 10 seconds or longer until a subtitle keyframe you MUST decode these video frames without displaying them if you want correct seeking -> you CANNOT seek correctly if keyframes in a subtitle stream are not very frequent or aligned to the other keyframes, EOR has no effect on this if OTOH keyframes are frequent or aligned then EOR isnt needed, so what EOR seems to do is it affects only a case which doesnt work with and without EOR [...] -- 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
On Sat, Nov 25, 2006 at 11:53:16AM +0100, Michael Niedermayer wrote:
Hi
On Fri, Nov 24, 2006 at 10:58:20PM -0500, Rich Felker wrote:
On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
I'm quite sure mpeg-ps/ts make no provision for this. Maybe Måns would like to back me up though? DVD players and other devices that seek on mpeg streams generally have _horribly_ crappy behavior under seeking and don't seek at all except to chapter boundaries or via 'fast read and skip decoding of nonkey frames'. I've never seen one with seek-to-time, probably because mpeg does not even make seek-to-time possible due to meaningless resetting timestamps...
just try:
Sub: K K Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
you can either A. ignore the subs and seek purely based on the video stream (will not display subs after seeking) B. seek to previous keyframe of all streams (will not allow you to seek into the 2 hour segment without sub keyframes
Having the same subtitle displayed for 2 hours duration (or even more than 5-10 seconds duration) is nonsense. If you meant for the subtitle at the beginning in your example to only be briefly displayed, then no subs for the next 2 hours, EOR is what allows NUT to accomplish that!
my example is about a non nut container, and what is displayed or not between the keyframes of the subtitle stream is NOT known to the demuxer (and neither to the nut muxer which should mux that, unless it parses the subtitle stream ...)
I don't think it's unreasonable at all for the muxer to need to be passed durations for subtitles as well as starting timestamps. Without duration there's no way the demuxer could possibly support knowing whether the subtitle is still relevant when seeking. EOR is just a clean stream-oriented way to encode duration and prevent messing up the back_ptr system.
The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes.
yes, ~1000 small (<10byte) keyframes whos position in time matches the video keyframes would be the correct solution, needing 10kb for 2 hours is negligible its a mere ~ 0.01 kbit/sec
It's not correct! To do this the muxer has to manufacture data as well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle. PLEASE for the love of [insert deity here] stop bringing up old issues now; it's too late. It's easy to complain about these things now 1.5-2 years later when everyone's forgotten why the decisions were made the way they were and why they're essential to correct operation, but that doesn't mean we should go through the same process again now only to rediscover the same thing. :( Rich
Rich Felker said:
On Sat, Nov 25, 2006 at 11:53:16AM +0100, Michael Niedermayer wrote:
Hi
On Fri, Nov 24, 2006 at 10:58:20PM -0500, Rich Felker wrote:
On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael Niedermayer wrote:
[...]
* nut files with EOR cannot be converted to other containers or more correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
I'm quite sure mpeg-ps/ts make no provision for this.
The ISO MPEG PS/TS specs do not mention any subtitles. The DVD and DVB specs add their own subtitle formats to PS and TS, respectively.
DVD players and other devices that seek on mpeg streams generally have _horribly_ crappy behavior under seeking and don't seek at all except to chapter boundaries or via 'fast read and skip decoding of nonkey frames'. I've never seen one with seek-to-time, probably because mpeg does not even make seek-to-time possible due to meaningless resetting timestamps...
You haven't been looking hard enough then. The DVD metadata (IFO files) contains a time to byte offset index, usually with a granularity of around 2 seconds. This allows for reasonably accurate seeking without the index growing very large. DVB streams are normally broadcast and seeking is meaningless. DVR devices usually parse the elementary streams and create an external index while recording. The particulars ones I work with even have frame-accurate seeking, and continuously variable playback speed, both forwards and backwards. As for timestamp resets, you can't avoid them when broadcasting 24/7, unless you have infintely large timestamp fields. -- Måns Rullgård mru@inprovide.com
On Sun, Nov 26, 2006 at 05:37:25AM -0000, Måns Rullgård wrote:
> * nut files with EOR cannot be converted to other containers or more > correctly you cannot seek correctly in the resulting file
Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
I'm quite sure mpeg-ps/ts make no provision for this.
The ISO MPEG PS/TS specs do not mention any subtitles. The DVD and DVB specs add their own subtitle formats to PS and TS, respectively.
Well, do they provide any mechanism to ensure that you have the correct subtitle displayed after seeking?
As for timestamp resets, you can't avoid them when broadcasting 24/7, unless you have infintely large timestamp fields.
64bit is long enough to run without problem until well past the end of the solar system... provided you don't choose timebase idiotically. :) Unfortunately I think mpeg uses 33bit or something and also uses idiotic timebase. Rich
Rich Felker said:
On Sun, Nov 26, 2006 at 05:37:25AM -0000, Måns Rullgård wrote:
> > * nut files with EOR cannot be converted to other containers or more > > correctly you cannot seek correctly in the resulting file > > Not true.
wait, EOR is "absolutely needed" and it works in containers which dont have EOR, how can both be true?
Other containers don't support correct seeking with subtitles unless they have an index of all subtitles.
i dont think this is true, maybe someone who knows the details about subs in mpeg-ps/ts could clarify but my suspicion is that there are rules in the relevant specs which ensure that the correct subs are displayed after seeking, and most other containers which support subs have an index ...
I'm quite sure mpeg-ps/ts make no provision for this.
The ISO MPEG PS/TS specs do not mention any subtitles. The DVD and DVB specs add their own subtitle formats to PS and TS, respectively.
Well, do they provide any mechanism to ensure that you have the correct subtitle displayed after seeking?
DVB doesn't care about seeking at all. That is a problem for recorders to solve as they see fit. I'm not sure about DVD, and quite frankly, I don't care. If the subtitles for the first line of dialog after a seek are missing, so what?
As for timestamp resets, you can't avoid them when broadcasting 24/7, unless you have infintely large timestamp fields.
64bit is long enough to run without problem until well past the end of the solar system... provided you don't choose timebase idiotically. :) Unfortunately I think mpeg uses 33bit or something and also uses idiotic timebase.
Why is the MPEG time base idiotic? 90kHz is nicely divisible by all the allowed frame rates. -- Måns Rullgård mru@inprovide.com
On Sun, Nov 26, 2006 at 04:28:28PM -0000, Måns Rullgård wrote:
Well, do they provide any mechanism to ensure that you have the correct subtitle displayed after seeking?
DVB doesn't care about seeking at all. That is a problem for recorders to solve as they see fit. I'm not sure about DVD, and quite frankly, I don't care. If the subtitles for the first line of dialog after a seek are missing, so what?
Actually users seem to care about this a lot, and it's one of the immediately visible-by-stupid-users practical benefits ot NUT. I flamed a bit at one time about how insistent Michael was on it, but now I'm glad we made the decision we did.
As for timestamp resets, you can't avoid them when broadcasting 24/7, unless you have infintely large timestamp fields.
64bit is long enough to run without problem until well past the end of the solar system... provided you don't choose timebase idiotically. :) Unfortunately I think mpeg uses 33bit or something and also uses idiotic timebase.
Why is the MPEG time base idiotic? 90kHz is nicely divisible by all the allowed frame rates.
Not all of the NTSC ones... The only factors of 90k are 2^4, 3^2, and 5^4. That is, 24000 and 60000 do not divide it. I know 24000/1001 is legal in mpeg1 and I'm pretty sure 60000/1001 is legal in HD broadcast.. Rich
Hi On Sat, Nov 25, 2006 at 01:38:39PM -0500, Rich Felker wrote: [...]
The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes.
yes, ~1000 small (<10byte) keyframes whos position in time matches the video keyframes would be the correct solution, needing 10kb for 2 hours is negligible its a mere ~ 0.01 kbit/sec
It's not correct! To do this the muxer has to manufacture data as
my sugestion was not to make the muxer inject new frames but rather that you cannot seek to points where there are no keyframes (this is pretty much how things normally behave, ignoring subtitles ...) with gaps/EOR OTOH its possible to seek to keyframes and gaps but if so why disallow it for non subtitle streams? what extra computations would be needed on the demuxer side for non subtitle EOR? (a muxer could always choose not to support EOR)
well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle.
which will cause a few milliseconds of useless computations after a seek
PLEASE for the love of [insert deity here] stop bringing up old issues now; it's too late. It's easy to complain about these things now 1.5-2 years later when everyone's forgotten why the decisions were made the way they were and why they're essential to correct operation, but that doesn't mean we should go through the same process again now only to rediscover the same thing. :(
its a bad sign if you need to think about something for days to rediscover why it was needed, it means IMHO the thing is too complex already or the case which needs it is pretty obscure or the reasoning hasnt been documented, in which case disscussing the issue and documenting the reasoning seems like a good idea ... [...] -- 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
On Sun, Nov 26, 2006 at 06:30:28PM +0100, Michael Niedermayer wrote:
Hi
On Sat, Nov 25, 2006 at 01:38:39PM -0500, Rich Felker wrote: [...]
The only other possibilities are to give up on your correct seeking with subtitles (which you seemed to want the most of any of us) or throw in thousands of fake empty keyframes.
yes, ~1000 small (<10byte) keyframes whos position in time matches the video keyframes would be the correct solution, needing 10kb for 2 hours is negligible its a mere ~ 0.01 kbit/sec
It's not correct! To do this the muxer has to manufacture data as
my sugestion was not to make the muxer inject new frames but rather that you cannot seek to points where there are no keyframes (this is pretty much how things normally behave, ignoring subtitles ...)
Well the result of this is that _someone_ must inject new frames or else all movies with subtitles become completely unseekable...
with gaps/EOR OTOH its possible to seek to keyframes and gaps but if so why disallow it for non subtitle streams? what extra computations would be needed on the demuxer side for non subtitle EOR? (a muxer could always choose not to support EOR)
Nothing whatsoever on the demuxer side. The problem is on the player side. The player would either have to be able to either generate silence (for audio) or switch to a different sychronization system... Anyway the practical difference here is that EOR for subtitles is needed to implement in NUT something that is already existing practice: movies that do not constantly have a subtitle displayed. EOR for audio/video, while it could be nice, is not needed for any existing practice, only to add a new capability that did not exist before.
well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle.
which will cause a few milliseconds of useless computations after a seek
Depends on the behavior of the player, but hopefully yes. More fundamentally, the principle of "correct seeking" is violated, and if we're going to violate that we might as well not have put so much effort into ensuring that it works to begin with. You never cared much about it but I did...
PLEASE for the love of [insert deity here] stop bringing up old issues now; it's too late. It's easy to complain about these things now 1.5-2 years later when everyone's forgotten why the decisions were made the way they were and why they're essential to correct operation, but that doesn't mean we should go through the same process again now only to rediscover the same thing. :(
its a bad sign if you need to think about something for days to rediscover why it was needed,
If this is the case then all of NUT is a horrible horrible design. The point is that it's easy to satisfy all the conditions required on muxing and that it's easy to implement a demuxer. Understanding _why_ all the conditions are necessary was never intended to be easy, and IMO it's impossible to make a good set of conditions which are both easy to satisfy/interpret AND easy to understand the motivation behind. If not impossible, it would take us at least 6 more years...!
it means IMHO the thing is too complex already or the case which needs it is pretty obscure or the reasoning hasnt been documented, in which case disscussing the issue and documenting the reasoning seems like a good idea ...
OK if someone can come up with a list of requirements/features/etc. in NUT that seem unjustified, I will write up detailed documentation on what they're needed for. Maybe I'll be wrong and it will be easy to understand once I've written this... Rich
Hi On Sun, Nov 26, 2006 at 01:57:54PM -0500, Rich Felker wrote: [...]
well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle.
which will cause a few milliseconds of useless computations after a seek
Depends on the behavior of the player, but hopefully yes.
More fundamentally, the principle of "correct seeking" is violated, and if we're going to violate that we might as well not have put so much effort into ensuring that it works to begin with. You never cared much about it but I did...
yes btw, last time i checked 50% of the code in libnuts demuxer is for seeking and its O(n) or more precissely it will in some not unreasonable scenarios (watch middle to end of movie then watch begin) have to move O(n) data around for every demuxed frame, in the cache used for seeking ... so IMHO optimal seeking is pretty hard and considering the amount of code needed for it i think its not worth it, but its of course nice if its possible ... [...]
it means IMHO the thing is too complex already or the case which needs it is pretty obscure or the reasoning hasnt been documented, in which case disscussing the issue and documenting the reasoning seems like a good idea ...
OK if someone can come up with a list of requirements/features/etc. in NUT that seem unjustified, I will write up detailed documentation on what they're needed for. Maybe I'll be wrong and it will be easy to understand once I've written this...
ok, the following is a list of things which i think might look unjustified to at least some people (some people actually asked on nut devel about some of these) ... * the dts-pts ordering rule vs. strict dts ordering vs. one of the previous with a max latency in a stream header vs. unrestricted ordering * EOR * no info packet compression vs. deflate vs. a fixed table of strings vs. a table in the first info packet or main header * codec_id/fourcc stuff * single global header vs. several * lack of timestamp discontinuities * crcs on frame headers, other headers and length values but not frames [...] -- 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
On Sun, Nov 26, 2006 at 09:35:17PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Nov 26, 2006 at 01:57:54PM -0500, Rich Felker wrote: [...]
well! It also means seeking will be _incorrect_, in the sense that if you disable video and just enable audio and subs, seeks will go farther back than they need to in order to find the _useless_ blank subtitle.
which will cause a few milliseconds of useless computations after a seek
Depends on the behavior of the player, but hopefully yes.
More fundamentally, the principle of "correct seeking" is violated, and if we're going to violate that we might as well not have put so much effort into ensuring that it works to begin with. You never cared much about it but I did...
yes btw, last time i checked 50% of the code in libnuts demuxer is for seeking and its O(n) or more precissely it will in some not unreasonable scenarios (watch middle to end of movie then watch begin) have to move O(n) data around for every demuxed frame, in the cache used for seeking ...
yes, this is an implementation issue. if i were writing it (i might actually write a third implementation just to have several approaches) i would use a linked list instead of an array here, and linear search it when seeking. compared to media seeks, any search operation in memory is O(0) anyway; however, O(n) is very bad if it happens at times other than seeking (anything but O(1) is unacceptable there). btw, a quick fix would be to always just append new syncpoint entries when building the cache, and then move them into place only when it's time to seek. but i always prefer implementations that don't require special considerations like that.
it means IMHO the thing is too complex already or the case which needs it is pretty obscure or the reasoning hasnt been documented, in which case disscussing the issue and documenting the reasoning seems like a good idea ...
OK if someone can come up with a list of requirements/features/etc. in NUT that seem unjustified, I will write up detailed documentation on what they're needed for. Maybe I'll be wrong and it will be easy to understand once I've written this...
ok, the following is a list of things which i think might look unjustified to at least some people (some people actually asked on nut devel about some of these) ...
thanks, i'll take a look at writing some stuff about them. rich
Hi, On Friday 24 November 2006 13:34, Michael Niedermayer wrote:
On Fri, Nov 24, 2006 at 12:50:13PM +0100, Ivo wrote:
1.) It would be handy to have the type mentioned after each tag in the tag description section. It is tiresome to have to scroll back each time. e.g. chapter_id (s) stream_class (v) fourcc (vb) et cetera
ok
Done. Not every tag described in the tag section is an actual tag in the file, so I left those blank.
2.) The first column of the frame_flags table is called Bit, but there is no such thing as the 4096th bit of a 64-bit value. I suggest changing the column-heading to Mask or change the column-entries to represent the bit number (i.e. 0, 1, 3, 4, 5, 6, 7, 12, 13).
ok
Done. It would have been less work to just change the heading, but I dislike decimal bitmasks, so it lists the actual bitnumbers now. --Ivo
participants (4)
-
Ivo -
Michael Niedermayer -
Måns Rullgård -
Rich Felker