<div dir="ltr"><span style="color:rgb(33,33,33);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13.1999998092651px;line-height:19.7999992370605px">Hey all, friendly ping :) Any help is much appreciated. </span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 6:56 PM, Chris Cunningham <span dir="ltr"><<a href="mailto:chcunningham@chromium.org" target="_blank">chcunningham@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Vorbis-Dev,<div><br></div><div>I'm investigating various WebM/Vorbis bugs in chromium. AFAIK muxing Vorbis inside of WebM does not have an official specification, so I'm using ffmpeg's implementation to try to answer 2 questions:</div><div><ol><li>Under what circumstances is it valid to find WebM Blocks containing Vorbis data with zero duration? (This would mean the next Block in the Cluster has the exact same timecode).<br><br></li><li>FFmpeg seems to use granulepos for presentation timestamp - is this correct? See here:<br><a href="https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvorbisenc.c#L345l" target="_blank">https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvorbisenc.c#L345l</a></li></ol></div><div><div>To me it seems the breakdown of ffmpeg's libvorbis_encode_frame is:</div><div><ul><li>get an ogg_packet from libvorbis (I think this contains a *single* vorbis block, right?)</li><li>store just the data from that packet (no header) in ffmpeg's own AVPacket struct</li><li>eventually this AVPacket data will be inserted as the contents of a WebM (Matroska) block:<br> <a href="https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1584" target="_blank">https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1584</a><br></li></ul><div>Starting with question 1, some important context comes from this excerpt of the vorbis spec:</div><div><br></div><div><i>Data is not returned from the first frame; it must be used to ’prime’ the decode engine. The encoder accounts for this priming when calculating PCM offsets; after the first frame, the proper PCM output offset is ’0’ - <a href="http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-190001.3.1" target="_blank">http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-190001.3.1</a><br></i></div><div><br></div><div>Am I right that "frame" and "block" are interchangable in the vorbis spec? If so, I would then expect the granulepos of the first ogg_packet processed by ffmpeg to be 0. I'm using this definition of granulepos:</div><div><br></div><div><i>This is the last sample, frame or other unit of information ('granule') that can be completely decoded from this packet - <a href="https://xiph.org/ogg/doc/libogg/ogg_packet.html" target="_blank">https://xiph.org/ogg/doc/libogg/ogg_packet.html</a></i><br></div><div><br></div><div>IIUC, we can derive duration from granulepos by simply scaling the count of samples up by the number of samples / time unit. So my answer to question 1 would be: the first block could / should have 0 duration. And my answer to question 2 would be: they should not use granulepos for presentation time - they will always be off by the duration of a packet. </div><div><br></div><div>What do you guys think? What am I missing?</div></div></div><div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888"><div>Chris</div></font></span></div>
</blockquote></div><br></div>