Re: Muxing vorbis in WebM

--===============0114525768==
Content-Type: multipart/alternative; boundary=089e013d0b24ce0e4d051946f206

--089e013d0b24ce0e4d051946f206
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey all, friendly ping :) Any help is much appreciated.

On Thu, Jun 18, 2015 at 6:56 PM, Chris Cunningham <[email protected]=
g
> wrote:

> Hi Vorbis-Dev,
>
> I'm investigating various WebM/Vorbis bugs in chromium. AFAIK muxing
> Vorbis inside of WebM does not have an official specification, so I'm usi=
ng
> ffmpeg's implementation to try to answer 2 questions:
>
>    1. 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).
>
>    2. FFmpeg seems to use granulepos for presentation timestamp - is this
>    correct? See here:
>
>    https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvorbisenc.c=
#L345l
>
> To me it seems the breakdown of ffmpeg's libvorbis_encode_frame is:
>
>    - get an ogg_packet from libvorbis (I think this contains a *single*
>    vorbis block, right?)
>    - store just the data from that packet (no header) in ffmpeg's own
>    AVPacket struct
>    - eventually this AVPacket data will be inserted as the contents of a
>    WebM (Matroska) block:
>
>    https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c=
#L1584
>
> Starting with question 1, some important context comes from this excerpt
> of the vorbis spec:
>
>
> *Data is not returned from the first frame; it must be used to =E2=80=99p=
rime=E2=80=99 the
> decode engine. The encoder accounts for this priming when calculating PCM
> offsets; after the first frame, the proper PCM output offset is =E2=80=99=
0=E2=80=99
> - http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-190001.3.1
> <http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-190001.3.1>*
>
> 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 process=
ed
> by ffmpeg to be 0. I'm using this definition of granulepos:
>
> *This is the last sample, frame or other unit of information ('granule')
> that can be completely decoded from this packet
> - https://xiph.org/ogg/doc/libogg/ogg_packet.html
> <https://xiph.org/ogg/doc/libogg/ogg_packet.html>*
>
> 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.
>
> What do you guys think? What am I missing?
>
> Thanks!
> Chris
>

--089e013d0b24ce0e4d051946f206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"color:rgb(33,33,33);font-family:&#39;Helvet=
ica Neue&#39;,Helvetica,Arial,sans-serif;font-size:13.1999998092651px;line-=
height:19.7999992370605px">Hey all, friendly ping :) Any help is much appre=
ciated.=C2=A0</span><br></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Thu, Jun 18, 2015 at 6:56 PM, Chris Cunningham <span dir=3D=
"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">ch=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Hi Vorbis-Dev,<div><br></div><div>I&#39;m investigati=
ng various WebM/Vorbis bugs in chromium. AFAIK muxing Vorbis inside of WebM=
 does not have an official specification, so I&#39;m using ffmpeg&#39;s imp=
lementation to try to answer 2 questions:</div><div><ol><li>Under what circ=
umstances 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=3D"https://github.com/FF=
mpeg/FFmpeg/blob/master/libavcodec/libvorbisenc.c#L345l" target=3D"_blank">=
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvorbisenc.c#L345=
l</a></li></ol></div><div><div>To me it seems the breakdown of ffmpeg&#39;s=
 libvorbis_encode_frame=C2=A0is:</div><div><ul><li>get an ogg_packet from l=
ibvorbis (I think this contains a *single* vorbis block, right?)</li><li>st=
ore just the data from that packet (no header) in ffmpeg&#39;s own AVPacket=
 struct</li><li>eventually this AVPacket data will be inserted as the conte=
nts of a WebM (Matroska) block:<br>=C2=A0<a href=3D"https://github.com/FFmp=
eg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1584" target=3D"_blank">ht=
tps://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1584<=
/a><br></li></ul><div>Starting with question 1, some important context come=
s 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 =E2=80=99prime=E2=80=
=99 the decode engine. The encoder accounts for this priming when calculati=
ng PCM offsets; after the first frame, the proper PCM output offset is =E2=
=80=990=E2=80=99 -=C2=A0<a href=3D"http://www.xiph.org/vorbis/doc/Vorbis_I_=
spec.html#x1-190001.3.1" target=3D"_blank">http://www.xiph.org/vorbis/doc/V=
orbis_I_spec.html#x1-190001.3.1</a><br></i></div><div><br></div><div>Am I r=
ight that &quot;frame&quot; and &quot;block&quot; are interchangable in the=
 vorbis spec? If so, I would then expect the granulepos of the first ogg_pa=
cket processed by ffmpeg to be 0. I&#39;m using this definition of granulep=
os:</div><div><br></div><div><i>This is the last sample, frame or other uni=
t of information (&#39;granule&#39;) that can be completely decoded from th=
is packet -=C2=A0<a href=3D"https://xiph.org/ogg/doc/libogg/ogg_packet.html=
" target=3D"_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 u=
nit. So my answer to question 1 would be: the first block could / should ha=
ve 0 duration. And my answer to question 2 would be: they should not use gr=
anulepos for presentation time - they will always be off by the duration of=
 a packet.=C2=A0</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=3D"=
HOEnZb"><font color=3D"#888888"><div>Chris</div></font></span></div>
</blockquote></div><br></div>

--089e013d0b24ce0e4d051946f206--

--===============0114525768==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Vorbis-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/vorbis-dev

--===============0114525768==--