[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec oggvorbis.c,1.20,1.21

[Rich Felker]

On Sat, Sep 03, 2005 at 10:15:36PM -0400, Justin Ruggles wrote:
> Rich Felker wrote:
> >>The vorbis encoder actually produces ogg packets, then strips the vorbis
> >>packets from them to pass to the muxer.  The vorbis encoder stores the
> > 
> > 
> > Uhg!!
> 
> Yeah, pretty sucky.  I couldn't for the life of me figure out any way to
> have libvorbisenc produce a raw vorbis stream without wrapping it in ogg
> packets.  Right now the vorbis encoder does a rough decode (more of a
> dewrapping) and sends however many vorbis packets are in the next ogg
> packet.

...

> >>granule position from the ogg packets received by libvorbis to the
> >>vorbis frame->pts field.  The granulepos is given in samples. From what
> > 
> > 
> > Then how the hell do we get pts for any packets except the first/last
> > one in a page?
> 
> It's not necessarily per page (that would be horrendous). It's just per
> ogg packet (which is still not good).  I think there is something in the
> ogg packet that tells how many vorbis packets are in it.  But still,
> this would pretty much require a full decoding of the ogg stream
> produced by libvorbisenc to fully recover each individual vorbis packet.

One ogg packet contains one vorbis packet. It's always that way. Pages
are the only larger unit of data in the crack-induced xiph world.

> >>So, you are right that the ogg issue is somewhat separate.  But if
> >>vorbis doesn't set the codec time_base to the samplerate, the ogg
> >>encoder should be modified to not scale the pkt->pts so it gives correct
> >>output.  Or maybe scale it by the actual codec time_base instead of
> >>assuming it's 1/samplerate.
> > 
> > 
> > Now I'm really confused what you mean..
> 
> Sorry.  I'll try to be more clear.  The vorbis encoder sets the frame
> pts value as the granulepos of the ogg packet it's contained in (the
> sucky part).

Ogg packets do not have granule pos. Only pages do.

> FFmpeg scales the pts value from the codec timebase to the
> stream timebase when setting the packet pts value.  The ogg encoder
> reads the packet pts value and currently tries to scale back to the
> codec timebase to get the correct granulepos.  But it assumes the codec
> timebase is 1/samplerate which isn't the case.  This produces incorrect
> granule positions.

:(

Rich