Re: [Ffmpeg-devel] Re: integrating AVS decoding into MPlayer
Hi On Sat, Jul 15, 2006 at 10:49:02PM +0200, Baptiste Coudurier wrote: [...]
[...]
Care to explain how these rules will cease to apply?
Like they changed in those years, when compression appeared, then VBR, who knows...
NUT system is the best one around. Still I persist to say that wraping specs are needed, and even more for ambiguous codecs wraping formats, and a fourcc for each codec recognized must be written in the specs, that means standardized.
for ambiguous cases we certainly should say something in the spec but most arent ambiguous, if you follow the spec of a codec and the nut spec and use a little common sense ... [...]
I persist to say that a container SHALL standardize a codec wraping (even just saying "default wraping rule applies" and its fourcc is ...) if it needs to support it. It should just be a matter of one line per codec, as NUT is very generic ;)
The one line would be the same for every codec so it's pointless.
IMHO not for H264,
what exactly is unclear in the h.264 spec?
What about timecode ? Subtitles ?
There is no specifications in NUT specs about wraping those kind of data. A stream type identifier is not sufficient IMHO.
I just read the specs again and I also do not see and decent standard to pack extradata for specific codec. Just put the MOV atoms in NUT ?
which codec spec is unclear about how to store it? ogg based codecs yes, that needs a line to clarify
Btw this thread now belongs to NUT devel IMHO.
yes [...] -- 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:
[...]
I persist to say that a container SHALL standardize a codec wraping (even just saying "default wraping rule applies" and its fourcc is ...) if it needs to support it. It should just be a matter of one line per codec, as NUT is very generic ;) The one line would be the same for every codec so it's pointless.
IMHO not for H264,
what exactly is unclear in the h.264 spec?
ISO/IEC specify bytestream NAL formating used in AVI. 1) Wraping in AVI IS NOT standardized. 2) Wraping in MOV IS standardized in ISO 14496-15. Problem will occur with "stream copy" and reformating. Im just saying that one way MUST be chosen, and clearly mentioned somewhere.
What about timecode ? Subtitles ? There is no specifications in NUT specs about wraping those kind of data. A stream type identifier is not sufficient IMHO.
I just read the specs again and I also do not see and decent standard to pack extradata for specific codec. Just put the MOV atoms in NUT ?
which codec spec is unclear about how to store it? ogg based codecs yes, that needs a line to clarify
AAC, QDM2, ALAC, MP3, basically everything that uses an extradata IMHO. Atm libavcodec assumes extradata is stored as MOV atoms. That is ugly IMHO and making NUT to forbid those format is needed. I think that we should mention wraping in order to be more specific and avoid "blind" stream copy for those codecs. For example, no extradata needed for AAC since it is stored as ADTS. or AAC must be stored as frame and ADTS header as extradata. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier <baptiste.coudurier@smartjog.com> writes:
Hi
Michael Niedermayer wrote:
[...]
I persist to say that a container SHALL standardize a codec wraping (even just saying "default wraping rule applies" and its fourcc is ...) if it needs to support it. It should just be a matter of one line per codec, as NUT is very generic ;) The one line would be the same for every codec so it's pointless.
IMHO not for H264,
what exactly is unclear in the h.264 spec?
ISO/IEC specify bytestream NAL formating used in AVI. 1) Wraping in AVI IS NOT standardized. 2) Wraping in MOV IS standardized in ISO 14496-15.
Problem will occur with "stream copy" and reformating. Im just saying that one way MUST be chosen, and clearly mentioned somewhere.
There is also the possibility of allowing both. It is easy enough for the decoder to detect which was used.
What about timecode ? Subtitles ? There is no specifications in NUT specs about wraping those kind of data. A stream type identifier is not sufficient IMHO.
I just read the specs again and I also do not see and decent standard to pack extradata for specific codec. Just put the MOV atoms in NUT ?
which codec spec is unclear about how to store it? ogg based codecs yes, that needs a line to clarify
AAC, QDM2, ALAC, MP3, basically everything that uses an extradata IMHO. Atm libavcodec assumes extradata is stored as MOV atoms. That is ugly IMHO and making NUT to forbid those format is needed.
I think that we should mention wraping in order to be more specific and avoid "blind" stream copy for those codecs.
For example, no extradata needed for AAC since it is stored as ADTS. or AAC must be stored as frame and ADTS header as extradata.
Don't forget about ADIF. -- Måns Rullgård mru@inprovide.com
Hi Måns Rullgård wrote: >>>> [...] >>>> IMHO not for H264, >>> what exactly is unclear in the h.264 spec? >> ISO/IEC specify bytestream NAL formating used in AVI. >> 1) Wraping in AVI IS NOT standardized. >> 2) Wraping in MOV IS standardized in ISO 14496-15. >> >> Problem will occur with "stream copy" and reformating. Im just saying >> that one way MUST be chosen, and clearly mentioned somewhere. > > There is also the possibility of allowing both. It is easy enough for > the decoder to detect which was used. Well, why not, but how to identify them ? IMHO that's not the decoder's job and it should not decided based on the extradata presence. 2 different fourcc's ? Well I don't know. IMHO only allowing one formating is better. >> [...] >> >> For example, no extradata needed for AAC since it is stored as ADTS. >> or AAC must be stored as frame and ADTS header as extradata. > > Don't forget about ADIF. > Hehe... headache... sleep. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
participants (3)
-
Baptiste Coudurier -
Michael Niedermayer -
Måns Rullgård