[NUT-devel] r21189 - trunk/DOCS/tech/nut.txt

Michael Niedermayer michaelni at gmx.at
Sat Nov 25 01:53:18 CET 2006


Hi

On Fri, Nov 24, 2006 at 03:49:25PM -0800, Ralph Giles wrote:
> On Fri, Nov 24, 2006 at 11:35:24PM +0100, Michael Niedermayer wrote:
> 
> > hmm, i see 3 possibilities for xiph codecs
> > 1. store the metadata packet as is
> > 2. dont store the metadata packet
> > 3. store a dummy (empty) metadata packet
> 
> I would vote for 1 or 3.
> 
> I disagreed with doing 2 in the RTP draft, but didn't insist because the 
> payload implementation already has to be codec-specific. For general 
> container use like this, I think it's important to require the metadata 
> packet where the codec requires it. This is less surprising for 
> implementors.
> 
> You do still have to know how the vorbis headers are packed, but for 
> playback there is still a difference between these two procedures:
> 
> # option 1 or 3
> for header in global_headers:
>   submit_packet_to_codec(header);
> 
> # option 2
> header_number = 0;
> for header in global_headers:
>   submit_packet_to_codec(header)
>   header_number += 1
>   if (header_number == 1):
>     header = construct_dummy_metadata_packet()
>     submit_packet_to_codec(header)

submit_packet_to_codec(header)
submit_packet_to_codec(dummy_defined_in_a_static_char_array)
submit_packet_to_codec(header)

but in reality the demuxer will likely pass the single global header
unchanged around, and the vorbis decoder (or wraper) would then

option 1 or 3
parse_header1();
skip_header2();
parse_header3();

vs.
option 2
parse_header1();
parse_header3();

your method might depening on API end up looking like

demuxer_open(){
    blah blah
    for all streams
        if stream is one of vorbis, theora, ...
            stream->xiph_glob= alloc(3)
            stream->xiph_glob_len= alloc(3)
            stream->xiph_glob_index=0;
            for i in 3
                find len of packet
                stream->xiph_glob_len[i]= len
                stream->xiph_glob[i]= alloc(len)
                read packet into stream->xiph_glob[i]
}

demuxer_get_packet()
    if(stream->xiph_glob_index<3 && stream->xiph_glob[stream->xiph_glob_index]){
        packet.dts= dunno has none
        packet.pts= dunno has none
        packet.duration= 0
        packet.flags= ?
        packet.len= stream->xiph_glob_len[stream->xiph_glob_index]
        memcpy(packet.data, stream->xiph_glob[stream->xiph_glob_index], packet.len);
        stream->xiph_glob_index++
        stream->xiph_glob_len[stream->xiph_glob_index]=0
        free(stream->xiph_glob[stream->xiph_glob_index])
        return
    }

considering that this would be needed for every non ogg demuxer i wouldnt 
implement it like that ...


[...]

> Therefore I'd propose, "The global headers MUST consist of the normal 
> sequence of header packets required for codec initialization, in the 
> order expected by the codec. An implementation MAY strip metadata and 
> other redundant information not necessary for correct playback from the 
> global headers to save space in the bitstream."

i would s/expected by the codec/defined in the codec spec/

otherwise its highly unclear, think about mpeg and its headers, the spec
is clear what is allowed and what not, specific implementations might be
more forgiving but still its the mpegvideo spec which we should follow
in that case


also i would rather say

An implementation MAY/SHOULD/MUST strip metadata and other redundant
information not necessary for correct playback from the global headers
as long as no incorrect values are stored and as long as the striped result
is not less valid per codec spec as before striping

(probably that could be improved too ...)

anyway after thinking about that a little option 3 with the encoder name
and version in the metadata packet seems like the best solution ...

[...]
-- 
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



More information about the NUT-devel mailing list