Muxing vorbis in WebM

--===============1618944224==
Content-Type: multipart/alternative; boundary=e89a8fb1f60e7446400518d53ddc

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

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 using
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#L=
345l

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#L=
1584

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=99pri=
me=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=990=
=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 processed
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

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

<div dir=3D"ltr">Hi Vorbis-Dev,<div><br></div><div>I&#39;m investigating va=
rious 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 implemen=
tation to try to answer 2 questions:</div><div><ol><li>Under what circumsta=
nces is it valid to find WebM Blocks containing Vorbis data with zero durat=
ion? (This would mean the next Block in the Cluster has the exact same time=
code).<br><br></li><li>FFmpeg seems to use granulepos for presentation time=
stamp - is this correct? See here:<br><a href=3D"https://github.com/FFmpeg/=
FFmpeg/blob/master/libavcodec/libvorbisenc.c#L345l" target=3D"_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&#39;s libv=
orbis_encode_frame=C2=A0is:</div><div><ul><li>get an ogg_packet from libvor=
bis (I think this contains a *single* vorbis block, right?)</li><li>store j=
ust the data from that packet (no header) in ffmpeg&#39;s own AVPacket stru=
ct</li><li>eventually this AVPacket data will be inserted as the contents o=
f a WebM (Matroska) block:<br>=C2=A0<a href=3D"https://github.com/FFmpeg/FF=
mpeg/blob/master/libavformat/matroskaenc.c#L1584" target=3D"_blank">https:/=
/github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1584</a><b=
r></li></ul><div>Starting with question 1, some important context comes fro=
m 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 t=
he decode engine. The encoder accounts for this priming when calculating PC=
M offsets; after the first frame, the proper PCM output offset is =E2=80=99=
0=E2=80=99 -=C2=A0<a href=3D"http://www.xiph.org/vorbis/doc/Vorbis_I_spec.h=
tml#x1-190001.3.1" target=3D"_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 t=
hat &quot;frame&quot; and &quot;block&quot; are interchangable in the vorbi=
s spec? If so, I would then expect the granulepos of the first ogg_packet p=
rocessed by ffmpeg to be 0. I&#39;m using this definition of granulepos:</d=
iv><div><br></div><div><i>This is the last sample, frame or other unit of i=
nformation (&#39;granule&#39;) that can be completely decoded from this pac=
ket -=C2=A0<a href=3D"https://xiph.org/ogg/doc/libogg/ogg_packet.html" targ=
et=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 sim=
ply scaling the count of samples up by the number of samples / time unit. S=
o my answer to question 1 would be: the first block could / should have 0 d=
uration. And my answer to question 2 would be: they should not use granulep=
os for presentation time - they will always be off by the duration of a pac=
ket.=C2=A0</div><div><br></div><div>What do you guys think? What am I missi=
ng?</div></div></div><div><br></div><div>Thanks!</div><div>Chris</div></div=
>

--e89a8fb1f60e7446400518d53ddc--

--===============1618944224==
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

--===============1618944224==--