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

[Justin Ruggles]

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.

>>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).  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.

-Justin