Re: [Nico Sabbi] Re: [MPlayer-users] converting .rm video stream to .ogg

[email protected] wrote:

> On 3/23/07, Charles philip Chan <[email protected]> wrote:
>
>> OK, aacording to one mplayer developer, this is the problem:
>>
>> ,----
>> | to make a long story short: with ogg files you can't make _anything_
>> | unless you know well the inner working of the audio, video and 
>> subtitle
>> | streams contained therein; this is exactly the opposite approach that
>> | should be followed when designing a container because every single 
>> codec
>> | type requires special handling; if you want to know how nice is 
>> handling
>> | an ogg file read libmpdemux/demux_ogg.c, but be warned that it drives
>> | people insane
>> `----
>>
>> Can someone comment on this?
>
>
> Sure.
>
> Ogg allows a codec to define (in the codec spec, not runtime) how
> timestamps are implemented out of a desire to allow the most efficient
> possible implementation of positioning information.  Timestamps eat a
> substantial portion of total stream overhead (or you have to use
> really few of them, ala an AVI file with a single keyframe), and this
> is a mechanism to squeeze more performace out of the bitstream, but
> still give very fine grained timestamping.


timestamps can be coded with little space with some sane form of vlc coding

>
> When you install a codec, you also need to install a 'granpos' shim
> into the muxer to interpret that timestamp type.  The magic for a
> stream type is associated with the granpos shim type.  We're talking a
> half page of code.  It does not require the whole codec, just the
> shim.  Or you could just build all the known shims into your muxer
> (and release a new muxer when new streamtypes pop up; some projects,
> eg liboggz, do this).  New ones don't pop up all that often.
>
> If you don't have that mux shim, you don't have the codec either, so
> you'd not be able to do anything with that specific stream anyway.
> You can perfectly well handle an Ogg stream with a stream type that's
> unknown.  You just won't be able to do forward mux operations on that
> specific internal stream without that shim.  You will still be able to
> stream, demux, etc.
>
> But... Since this approach doesn't fit into their design, and their
> way is bordering on religious revelation at this point ("God said so!
> Don't question it!"), they use Ogg as an excuse to do all the swearing
> they'd be doing anyway.
>
> Monty


what you describe is the tiniest of problem; the real ones I encountered 
are:
- 1) total lack of headers as headers are carried as ordinary payload data;
since headers carry configuration parameters for the decoders (e.g. 
codebooks for vorbis,
resolution,framerate & co for video) treating them as ordinary data 
doesn't make much sense
because they are not associated to time/granulepos.
If you don't know the internals of the compression format used you don't 
even know
how many packets you have to consider as header rather than as configurator
- 2) granulepos are per-page rather than per-packet, thus not all frames
have a timestamp; this forces decoders and framers to extrapolate real 
frame timestamps,
but again: if you don't know the internals of the codec you can't 
extrapolate
(and this also prevents remuxing to another format because you can't 
have precise timestamps)
- 3) pages have only 1 granulepos,  so by design it must be a dts, 
consequently
pages don't even have a real pts (again, decoder help required); even in 
this respect ogg is no better than avi
- 4) packets may span multiple pages, thus requiring buffering in the 
demuxer and
consequent slow-down
- 5) for all the above problems precise seeking is next to impossible

I had to stop because I coulnd't stand anymore coding to cope with ogg 
extravaganza.


BTW, this list lacks a reply-to header, forcing to send messages to N 
targets.
Anything against adding it?
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Problemi di Liquidità? Con Logos Finanziaria 30.000 € in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi, clicca qui
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2911&d=23-3