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