Hi On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so [...] -- Michael
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze
Well, I suggested it so rather obviously I'm OK with it... I just finished going over the spec line by line, I'm OK...
* cosmetic changes are ok
One cosmetic change I would like, I don't quite like the explanation of placement of index_ptr.. A few lines above it it is explictly said reserved_bytes must not be written...
* minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Rich, your turn... - ods15
Hi On Tue, Mar 14, 2006 at 06:45:17AM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze
Well, I suggested it so rather obviously I'm OK with it... I just finished going over the spec line by line, I'm OK...
* cosmetic changes are ok
One cosmetic change I would like, I don't quite like the explanation of placement of index_ptr.. A few lines above it it is explictly said reserved_bytes must not be written...
feel free to change it ... [...] -- Michael
On Tue, Mar 14, 2006 at 01:16:26PM +0100, Michael Niedermayer wrote:
Hi
On Tue, Mar 14, 2006 at 06:45:17AM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze
Well, I suggested it so rather obviously I'm OK with it... I just finished going over the spec line by line, I'm OK...
* cosmetic changes are ok
One cosmetic change I would like, I don't quite like the explanation of placement of index_ptr.. A few lines above it it is explictly said reserved_bytes must not be written...
feel free to change it ...
Committed. - ods15
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Commit? - ods15
Hi On Wed, Mar 15, 2006 at 06:47:31PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Commit?
iam ok with it [...] -- Michael
On Thu, Mar 16, 2006 at 12:20:58PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Mar 15, 2006 at 06:47:31PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Commit?
iam ok with it
Give me a chance to read through the spec as it is again, but I think I'll be ok with it. Rich
On Thu, Mar 16, 2006 at 11:03:15AM -0500, Rich Felker wrote:
On Thu, Mar 16, 2006 at 12:20:58PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Mar 15, 2006 at 06:47:31PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Commit?
iam ok with it
Give me a chance to read through the spec as it is again, but I think I'll be ok with it.
Reviewing now. A couple issues: - It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity. - Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other. - version 2 must be incremented for freeze/final. - reserved_count can only be specified in the framecode, not explicitly in the frame header. - We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc? - The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too. - Michael's guidelines about what a demuxer should do for reading info do not seem to have been committed in full. Otherwise it looks very good! Rich
Hi On Sat, Mar 18, 2006 at 12:19:33AM -0500, Rich Felker wrote:
On Thu, Mar 16, 2006 at 11:03:15AM -0500, Rich Felker wrote:
On Thu, Mar 16, 2006 at 12:20:58PM +0100, Michael Niedermayer wrote:
Hi
On Wed, Mar 15, 2006 at 06:47:31PM +0200, Oded Shimon wrote:
On Fri, Mar 10, 2006 at 03:43:04PM +0100, Michael Niedermayer wrote:
Hi
On Fri, Mar 10, 2006 at 02:16:41PM +0200, Oded Shimon wrote:
$subj
oded, rich, please each of you read through the spec and see if you notice any issues, if no and we have agreed on something for the remaining ones i have no objections to a freeze * cosmetic changes are ok * minor fixes like changed thresholds or added info packet names are ok * everything else needs unfreezing or so
Commit?
iam ok with it
Give me a chance to read through the spec as it is again, but I think I'll be ok with it.
Reviewing now. A couple issues:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
A. file_id_string at the begin B. no file_id_string at the begin B has slightly lower complexity, A will help identifying the file if you are an idiot and open it in a text editor iam _slightly_ in favor of B
- version 2 must be incremented for freeze/final.
agree
- reserved_count can only be specified in the framecode, not explicitly in the frame header.
wither we: reserved_count -> reserved_count_plus1 and if(reserved_count_plus1[frame_code]==0) reserved_count_plus1[frame_code] v or we add a flag a flag seems better but inconsistant with how stream_id is coded ill post a suggested solution soon
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
i dont care, a fourcc -> codec_id map is not that hard to add to a player
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
hmm, now if i could only remember it ... [...] -- Michael
On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
OK. Any preference which way? I can make a patch addressing these issues if you like but it won't be for a couple days.
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
A. file_id_string at the begin B. no file_id_string at the begin
B has slightly lower complexity, A will help identifying the file if you are an idiot and open it in a text editor iam _slightly_ in favor of B
OK, so maybe change this.
- version 2 must be incremented for freeze/final.
agree
OK, adding this to the list of things to change.
- reserved_count can only be specified in the framecode, not explicitly in the frame header.
wither we: reserved_count -> reserved_count_plus1 and if(reserved_count_plus1[frame_code]==0) reserved_count_plus1[frame_code] v or we add a flag a flag seems better but inconsistant with how stream_id is coded ill post a suggested solution soon
I'm happy with the flags changes that were made, except that maybe more unlikely flags should be moved to above bit 6.
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
i dont care, a fourcc -> codec_id map is not that hard to add to a player
Hmm, I'm undecided on what's best...
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
hmm, now if i could only remember it ...
My version said something to the effect that decode_delay is not a derived property of the pts sequence but a property defined by the compression specification or a relevant supplement (if we acknowledge that some ill-specified formats like Xiph codecs might require supplemental specs for storage in non-incestuous containers), and that the value of decode_delay in the NUT file MUST match the codec's idea of delay. Rich
On Sun, Mar 19, 2006 at 03:22:56PM -0500, Rich Felker wrote:
On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
OK. Any preference which way? I can make a patch addressing these issues if you like but it won't be for a couple days.
Patch attached. Hopefully the wording is sufficiently precise without being too pedantic. In particular I updated max_distance to refer to startcodes rather than syncpoints since otherwise it is incorrect in the presence of duplicated headers (it was impossible to satisfy...) Rich
Hi On Wed, Mar 22, 2006 at 08:54:26PM -0500, Rich Felker wrote:
On Sun, Mar 19, 2006 at 03:22:56PM -0500, Rich Felker wrote:
On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
OK. Any preference which way? I can make a patch addressing these issues if you like but it won't be for a couple days.
Patch attached. Hopefully the wording is sufficiently precise without being too pedantic. In particular I updated max_distance to refer to startcodes rather than syncpoints since otherwise it is incorrect in the presence of duplicated headers (it was impossible to satisfy...)
yeah, the wording is a little harder to understand (actually i reminds me of h.264 where later drafts had more and more precisse wording and where less and less understandable, the end result was so complex that it often needs to be read 3-4 times before you figure out what is acually meant from a high level point of view but here i think your version is better then what is in cvs ATM ... [...] -- Michael
On Fri, Mar 24, 2006 at 03:25:54AM +0100, Michael Niedermayer wrote:
Hi
On Wed, Mar 22, 2006 at 08:54:26PM -0500, Rich Felker wrote:
On Sun, Mar 19, 2006 at 03:22:56PM -0500, Rich Felker wrote:
On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
OK. Any preference which way? I can make a patch addressing these issues if you like but it won't be for a couple days.
Patch attached. Hopefully the wording is sufficiently precise without being too pedantic. In particular I updated max_distance to refer to startcodes rather than syncpoints since otherwise it is incorrect in the presence of duplicated headers (it was impossible to satisfy...)
yeah, the wording is a little harder to understand (actually i reminds me of h.264 where later drafts had more and more precisse wording and where less and less understandable, the end result was so complex that it often needs to be read 3-4 times before you figure out what is acually meant from a high level point of view
but here i think your version is better then what is in cvs ATM ...
Committed. Spec can use a cleaning up in regards to understandiblity anyway. - ods15
On Sat, Mar 18, 2006 at 12:19:33AM -0500, Rich Felker wrote:
Reviewing now. A couple issues:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
fixed
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
I'm leaning both ways. It's slightly more complex, but it allows for ex. mplayer to probe without having to seek back after probing (mplayer is very dumb about this...)
- version 2 must be incremented for freeze/final.
IMO 2 for freeze, 3 for final. By the time spec is finalized should be about same time nutmerge can give 100% compliant nut files. Also, is there any rule about if a certaion version number means it is non backwards compatible? Like, if version is 4 then the demuxer should not even bother trying demuxing the file?
- reserved_count can only be specified in the framecode, not explicitly in the frame header.
fixed
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
send a patch?
- Michael's guidelines about what a demuxer should do for reading info do not seem to have been committed in full.
I didn't quite follow that whole discussion so not sure whats missing. - ods15
On Sat, Mar 25, 2006 at 03:45:43PM +0200, Oded Shimon wrote:
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
I'm leaning both ways. It's slightly more complex, but it allows for ex. mplayer to probe without having to seek back after probing (mplayer is very dumb about this...)
Umm, reading main header startcode will work just as well for probing.
- version 2 must be incremented for freeze/final.
IMO 2 for freeze, 3 for final. By the time spec is finalized should be
IMO 3 for freeze. 2 has been all the constantly-changing versions for the past year and we need a way to distinguish them and reject the old files during the freeze while people are testing. Also if there are no changes (no unfreeze) then we can keep 3 after final too!
about same time nutmerge can give 100% compliant nut files. Also, is there any rule about if a certaion version number means it is non backwards compatible? Like, if version is 4 then the demuxer should not even bother trying demuxing the file?
After final, nut will ALWAYS be compatible, forever. This is why freeze/final is so important! New version numbers will just indicate new additional semantics, etc. Maybe they're not even needed at all..
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
send a patch?
OK..
- Michael's guidelines about what a demuxer should do for reading info do not seem to have been committed in full.
I didn't quite follow that whole discussion so not sure whats missing.
OK I'll check.. Rich
On Sat, Mar 25, 2006 at 10:52:20AM -0500, Rich Felker wrote:
On Sat, Mar 25, 2006 at 03:45:43PM +0200, Oded Shimon wrote:
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
I'm leaning both ways. It's slightly more complex, but it allows for ex. mplayer to probe without having to seek back after probing (mplayer is very dumb about this...)
Umm, reading main header startcode will work just as well for probing.
Yes, but you need to rewind after that, MPlayer sucks for not always allowing this (non seekable streams), I'm actually not completely sure about all this, but I do know that if you don't do 'stream_seek' after probing, you will have lost the initial data you used for probing. Fine for native demuxers, trouble for library demuxers (libnut).
- version 2 must be incremented for freeze/final.
IMO 2 for freeze, 3 for final. By the time spec is finalized should be
IMO 3 for freeze. 2 has been all the constantly-changing versions for the past year and we need a way to distinguish them and reject the old files during the freeze while people are testing.
Also if there are no changes (no unfreeze) then we can keep 3 after final too!
OK. But I suppose until nutmerge is fixed it should only use 2?
about same time nutmerge can give 100% compliant nut files. Also, is there any rule about if a certaion version number means it is non backwards compatible? Like, if version is 4 then the demuxer should not even bother trying demuxing the file?
After final, nut will ALWAYS be compatible, forever. This is why freeze/final is so important! New version numbers will just indicate new additional semantics, etc. Maybe they're not even needed at all..
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
OK... Start writing then.
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
send a patch?
OK..
Well?
- Michael's guidelines about what a demuxer should do for reading info do not seem to have been committed in full.
I didn't quite follow that whole discussion so not sure whats missing.
OK I'll check..
Well? - ods15
On Tue, Mar 28, 2006 at 11:05:55AM +0200, Oded Shimon wrote:
On Sat, Mar 25, 2006 at 10:52:20AM -0500, Rich Felker wrote:
On Sat, Mar 25, 2006 at 03:45:43PM +0200, Oded Shimon wrote:
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
I'm leaning both ways. It's slightly more complex, but it allows for ex. mplayer to probe without having to seek back after probing (mplayer is very dumb about this...)
Umm, reading main header startcode will work just as well for probing.
Yes, but you need to rewind after that, MPlayer sucks for not always allowing this (non seekable streams), I'm actually not completely sure about all this, but I do know that if you don't do 'stream_seek' after probing, you will have lost the initial data you used for probing. Fine for native demuxers, trouble for library demuxers (libnut).
Umm, just put code that looks for the main startcode in mplayer too... It's just as simple as the code that looks for the string..
Also if there are no changes (no unfreeze) then we can keep 3 after final too!
OK. But I suppose until nutmerge is fixed it should only use 2?
Can you just add code to disable nutmerge except for formats that work? BTW I suppose the fourcc issue also needs to be resolved before freeze..
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
OK... Start writing then.
_< Do you have thoughts on which way we should go with it?
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
send a patch?
OK..
Well?
I sent an email with a sort of draft wording. Comments on it? Rich
On Tue, Mar 28, 2006 at 11:55:31AM -0500, Rich Felker wrote:
On Tue, Mar 28, 2006 at 11:05:55AM +0200, Oded Shimon wrote:
On Sat, Mar 25, 2006 at 10:52:20AM -0500, Rich Felker wrote:
On Sat, Mar 25, 2006 at 03:45:43PM +0200, Oded Shimon wrote:
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
I'm leaning both ways. It's slightly more complex, but it allows for ex. mplayer to probe without having to seek back after probing (mplayer is very dumb about this...)
Umm, reading main header startcode will work just as well for probing.
Yes, but you need to rewind after that, MPlayer sucks for not always allowing this (non seekable streams), I'm actually not completely sure about all this, but I do know that if you don't do 'stream_seek' after probing, you will have lost the initial data you used for probing. Fine for native demuxers, trouble for library demuxers (libnut).
Umm, just put code that looks for the main startcode in mplayer too... It's just as simple as the code that looks for the string..
I think you misunderstand.. step 1: mplayer probe - read N bytes, check if it matches startcode/id. step 2: call libnut and start demuxing The problem is, mplayer's probe sucks, and it _discards_ the N bytes you just read. you will either have to seek back to begginning of stream (I'm not 100% if this requires a seekable stream) or use your own caching hacks for them (or just ignore them and start at byte position after the probe). I know currently demux_lavf does: probe, seek back, demux. Starting after a probe of 'file_id' is fine, because libnut doesn't need it, but if you "eat up" the main startcode from begginning of file, libnut will choke looking for it.
Also if there are no changes (no unfreeze) then we can keep 3 after final too!
OK. But I suppose until nutmerge is fixed it should only use 2?
Can you just add code to disable nutmerge except for formats that work?
I might as well reject everything, I'm working on a decent framer api for nutmerge, we'll see how that goes.
BTW I suppose the fourcc issue also needs to be resolved before freeze..
Yeah, hence me asking you to start doing it...
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
OK... Start writing then.
_< Do you have thoughts on which way we should go with it?
Uhh.... No idea. More or less same as current formats, not be a pain in the ass. As in, I wouldn't mind using MP4S if players actually support it. If not, I say just use XVID... (Though it would be weird for a spec strictly saying to use something like "XVID")
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
send a patch?
OK..
Well?
I sent an email with a sort of draft wording. Comments on it?
You mean this? - My version said something to the effect that decode_delay is not a derived property of the pts sequence but a property defined by the compression specification or a relevant supplement (if we acknowledge that some ill-specified formats like Xiph codecs might require supplemental specs for storage in non-incestuous containers), and that the value of decode_delay in the NUT file MUST match the codec's idea of delay. - No objections... - ods15
On Tue, Mar 28, 2006 at 07:09:02PM +0200, Oded Shimon wrote:
I think you misunderstand..
step 1: mplayer probe - read N bytes, check if it matches startcode/id. step 2: call libnut and start demuxing
The problem is, mplayer's probe sucks, and it _discards_ the N bytes you just read. you will either have to seek back to begginning of stream
No, mplayer's stream layer handles this. Otherwise all probing for all formats would be broken.
Starting after a probe of 'file_id' is fine, because libnut doesn't need it, but if you "eat up" the main startcode from begginning of file, libnut will choke looking for it.
If libnut doesn't need it then libnut is not compliant to the spec. :)
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
OK... Start writing then.
_< Do you have thoughts on which way we should go with it?
Uhh.... No idea. More or less same as current formats, not be a pain in the ass. As in, I wouldn't mind using MP4S if players actually support it. If not, I say just use XVID... (Though it would be weird for a spec strictly saying to use something like "XVID")
Using XVID for everything is absolutely wrong. There's no need to maintain compatibility with the expectations of stupid hardware players since they don't even support NUT yet. IMO the options are: 1. Use the same mess as AVI & friends with 10-20 fourcc's for each codec. 2. Require a single fourcc per codec, using an existing common name for the standard (like MP4S or H264) if available and never using vendor-specific names. 3. Require a single fourcc (or more generally, codec id) per codec, using our own nomenclature. One past proposal I made was to use the official name of the document that specifies the compression format, and in the case of reverse-engineered proprietary formats this would be the name of the DLL file. :) Of course I'm open to other options too. IMO 3 is the cleanest and most format, while 2 is probably more pradmatic. In some senses 1 is probably the most pragmatic but also disgusting, and it certainly isn't appropriate for audio..
I sent an email with a sort of draft wording. Comments on it?
You mean this?
- My version said something to the effect that decode_delay is not a derived property of the pts sequence but a property defined by the compression specification or a relevant supplement (if we acknowledge that some ill-specified formats like Xiph codecs might require supplemental specs for storage in non-incestuous containers), and that the value of decode_delay in the NUT file MUST match the codec's idea of delay. -
No objections...
OK, I'll try to write up a version for inclusion in the spec.. Rich
On Tue, Mar 28, 2006 at 01:14:14PM -0500, Rich Felker wrote:
On Tue, Mar 28, 2006 at 07:09:02PM +0200, Oded Shimon wrote:
I think you misunderstand..
step 1: mplayer probe - read N bytes, check if it matches startcode/id. step 2: call libnut and start demuxing
The problem is, mplayer's probe sucks, and it _discards_ the N bytes you just read. you will either have to seek back to begginning of stream
No, mplayer's stream layer handles this. Otherwise all probing for all formats would be broken.
CPLAYER: Playing -. OPEN: Reading from stdin... STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed Win32 LoadLibrary failed to load: avisynth.dll, /usr/local/lib/codecs/avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed DEMUXER: MPEG-PS file format detected. <plays fine...> I'm actually not sure about all this, but IMO MPlayer stream layer just sucks beyond belief regardless, it can't even update end of file position for growing files (but it can read past it). (You can't find out the new filesize)
Starting after a probe of 'file_id' is fine, because libnut doesn't need it, but if you "eat up" the main startcode from begginning of file, libnut will choke looking for it.
If libnut doesn't need it then libnut is not compliant to the spec. :)
Ahem, error handling. It does check for file_id string, but if not found, it just starts linear searching for startcode.
> - We need a spec for what goes in the fourcc field, especially for > audio, but it may also be an issue for video. Are XVID, DIVX, DX50, > etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
seperate from freeze/finalizing...
No it's not.
OK... Start writing then.
_< Do you have thoughts on which way we should go with it?
Uhh.... No idea. More or less same as current formats, not be a pain in the ass. As in, I wouldn't mind using MP4S if players actually support it. If not, I say just use XVID... (Though it would be weird for a spec strictly saying to use something like "XVID")
Using XVID for everything is absolutely wrong. There's no need to maintain compatibility with the expectations of stupid hardware players since they don't even support NUT yet. IMO the options are:
1. Use the same mess as AVI & friends with 10-20 fourcc's for each codec. 2. Require a single fourcc per codec, using an existing common name for the standard (like MP4S or H264) if available and never using vendor-specific names.
I'm generally OK with this...
3. Require a single fourcc (or more generally, codec id) per codec, using our own nomenclature. One past proposal I made was to use the official name of the document that specifies the compression format, and in the case of reverse-engineered proprietary formats this would be the name of the DLL file. :) Of course I'm open to other options too.
So, divx fourcc would be "ISO/IEC 14496-2" ?... I was actually considering maybe just using ffmpeg's CODEC_ID stuff :)
IMO 3 is the cleanest and most format, while 2 is probably more pradmatic. In some senses 1 is probably the most pragmatic but also disgusting, and it certainly isn't appropriate for audio..
I wasn't actually refferring to hardware plays at all, I was actually thinking of mplayer. mplayer currently works "out of the box" with nut. Adding _more_ mappings to the mess would be... silly. But I don't really care about all this. Whatever works, I'm fine with it... - ods15
On Tue, Mar 28, 2006 at 08:23:24PM +0200, Oded Shimon wrote:
On Tue, Mar 28, 2006 at 01:14:14PM -0500, Rich Felker wrote:
On Tue, Mar 28, 2006 at 07:09:02PM +0200, Oded Shimon wrote:
I think you misunderstand..
step 1: mplayer probe - read N bytes, check if it matches startcode/id. step 2: call libnut and start demuxing
The problem is, mplayer's probe sucks, and it _discards_ the N bytes you just read. you will either have to seek back to begginning of stream
No, mplayer's stream layer handles this. Otherwise all probing for all formats would be broken.
CPLAYER: Playing -. OPEN: Reading from stdin... STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed Win32 LoadLibrary failed to load: avisynth.dll, /usr/local/lib/codecs/avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed STREAM: Cannot seek backward in linear streams! STREAM: Seek failed DEMUXER: MPEG-PS file format detected. <plays fine...>
I'm actually not sure about all this, but IMO MPlayer stream layer just sucks beyond belief regardless, it can't even update end of file position for growing files (but it can read past it). (You can't find out the new filesize)
IMO it's a bug in some of the demuxers which causes them to read past the max stream buffer length when probing.
Starting after a probe of 'file_id' is fine, because libnut doesn't need it, but if you "eat up" the main startcode from begginning of file, libnut will choke looking for it.
If libnut doesn't need it then libnut is not compliant to the spec. :)
Ahem, error handling. It does check for file_id string, but if not found, it just starts linear searching for startcode.
OK, never mind. :)
1. Use the same mess as AVI & friends with 10-20 fourcc's for each codec. 2. Require a single fourcc per codec, using an existing common name for the standard (like MP4S or H264) if available and never using vendor-specific names.
I'm generally OK with this...
Yeah me too. Just wondering if we could/should do better.
3. Require a single fourcc (or more generally, codec id) per codec, using our own nomenclature. One past proposal I made was to use the official name of the document that specifies the compression format, and in the case of reverse-engineered proprietary formats this would be the name of the DLL file. :) Of course I'm open to other options too.
So, divx fourcc would be "ISO/IEC 14496-2" ?... I was actually considering
Yes.
maybe just using ffmpeg's CODEC_ID stuff :)
You mean the numbers? Or the strings CODEC_ID_*? Using the numbers is a bad idea IMO since they're just arbitrary implementation-internal constants.
IMO 3 is the cleanest and most format, while 2 is probably more pradmatic. In some senses 1 is probably the most pragmatic but also disgusting, and it certainly isn't appropriate for audio..
I wasn't actually refferring to hardware plays at all, I was actually thinking of mplayer. mplayer currently works "out of the box" with nut. Adding _more_ mappings to the mess would be... silly. But I don't really care about all this. Whatever works, I'm fine with it...
If we designed NUT around mplayer's brokenness, NUT would be complete shit... :) In fact it would be AVI. :)))))))) Rich
participants (3)
-
Michael Niedermayer -
Oded Shimon -
Rich Felker