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