<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 31, 2013 at 7:22 AM, Steve Lhomme <span dir="ltr"><<a href="mailto:slhomme@matroska.org" target="_blank">slhomme@matroska.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi everyone, sorry being late to the party, I don't have much "me time" lately.</div>
</blockquote><div style>me time? Never heard of it.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Fri, Mar 22, 2013 at 10:24 PM, Frank Galligan <span dir="ltr"><<a href="mailto:frankgalligan@gmail.com" target="_blank">frankgalligan@gmail.com</a>></span> wrote:<br>

</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal"><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt">

<b style="font-weight:normal"></b></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt;display:inline!important"><b style="font-weight:normal"><span style="font-size:13px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">Open issues from [1] I want to address:</span></b></p>

<br><p></p>
<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">1. </span><span style="font-size:13px;font-family:Verdana;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">Seeking in Opus streams requires a pre-roll.</span></p>


<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">2. </span><span style="font-size:13px;font-family:Verdana;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">How does the OpusHead pre-skip field interact with the timestamps? </span></p>

</b></div></blockquote><div><br></div></div><div>First question that doesn't seem to be answered from past conversations: is the pre-roll a constant time, a contact packet of data or not even something constant ? It seems to be a constant time, given this but I want to make sure we're on the same page.</div>

<div><a href="http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-4.2" target="_blank">http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-4.2</a> </div></div></div></div></blockquote><div> </div><div style>
Pre-roll is a constant at least samples 3840. As Opus is only 48000Hz, this translates to at least 80 milliseconds.</div><div style>See <a href="http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-4.5">http://tools.ietf.org/html/draft-terriberry-oggopus-01#section-4.5</a></div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>Also pre-roll and pre-seek were mentioned. Are they actually the same thing ? I assume they are. (if not my following comments are only on pre-seek)</div></div></div></div></blockquote><div style>
No, they are different.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div><br></div><div>If it's a constant then all timecodes of the Opus track can be shifted of that value to have the data to "render" or to "decode" (so it renders properly at the time needed). I think for simplicity it's easier if that shift is not visible at the muxer/demuxer level. That will avoid all kinds of possible issues. While shifting time at the codec level is a very simple operation. So I think the cleanest way to do that is let the codec do its sample/timecode shift internally, by setting the pre-roll time in the CodecPrivate, with a format to decide.</div>
</div></div></div></blockquote><div style>It is a constant time that Opus in Ogg shifts each timestamp (granule pos). I agree with you that shifting all timecodes in a stream in Matroska at the muxer/demuxer level will lead to issues (IMO, I think I can make it work. But until you actually try to implement it, you are not going to know what the issues are)</div>
<div style><br></div><div style>If we decide to not shift all the timestamps by a constant time (I.e. pre-skip ), then the decoder/encoder does not need to re-write any timestamps. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal"><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt">

<b style="font-weight:normal"></b></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt;display:inline!important"><b style="font-weight:normal"><span style="font-size:13px;font-family:Arial;vertical-align:baseline;white-space:pre-wrap">2.2 The pre-skip data must be contained in the first audio Block (or maybe in the CodecPrivate) with non-pre-skip encoded data.</span></b></p>

<br><p></p></b></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal">
<br><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">Pros:</span></p>


<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- No demuxer changes to handle Opus audio. Only the decoder will need to know about the pre-skip data.</span></p>


<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- Block timestamps will match decoded timestamps for all time T.</span></p>


<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- No PreSkip element in the TrackHeader. The decoder will still have pke-skip from the CodecPrivate data.</span></p>


<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- No negative timestamps.</span></p><br><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt">


<span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">Cons:</span></p><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- Data may need to be added to all Opus Blocks to delimit the pre-skip data. </span></p>

</b></div></blockquote><div><br></div></div><div>If it's just a timecode shift there is no additional data (apart from when decoding starts) compared to the normal decoder flow.</div></div></div></div></blockquote><div style>
In 2.2 we are not talking about a timecode shift.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal">
<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- Does not help future formats that need a PreSkip.</span></p>

</b></div></blockquote><div><br></div></div><div>If a codec needs data pre-prended or non constant pre-skip then we may not have a generic enough solution anyway.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal">
<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">- Muxers may have to special case the pre-skip data.</span></p>

</b></div></blockquote><div><br></div></div><div>I don't see how. The timecode shift is transparent outside of the codec. The CodecPrivate data HAS to be passed to the codec, nothing is new here.</div></div></div></div>
</blockquote><div style>In 2.2 we don't have a timecode shift.  In a later email I referenced 2.2.2 as putting the pre-skip data in the CodecPrivate. This should work fine on initial playback, like other codecs, as the Opus decoder can decode the pre-skip data when it is initialized. But, unlike other codecs (as far a I know), the Opus decoder must decode the pre-skip data every time the player seeks to the first normal audio Block.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><b style="font-size:medium;font-family:'Times New Roman';font-weight:normal"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="margin-top:0pt;margin-bottom:0pt">

<span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">Questions:</span></p>
<p dir="ltr" style="margin-top:0pt;margin-bottom:0pt"><span style="font-size:13px;font-family:Arial;color:rgb(34,34,34);vertical-align:baseline;white-space:pre-wrap">Can the decoder assume that a packet of timestamp 0 will have to decode and throw out pre-skip samples? Then we wouldn’t need to delimit all of the Opus Blocks.</span></p>

</b></div></blockquote><div><br></div></div><div>I think the codec should not output the pre-skip samples, ie samples before 0.</div></div></div></div></blockquote><div style>I agree, but unless we change the Opus decoder (Opus experts, does the Opus decoder know it is decoding pre-skip data?). Or we implement something like 2.2.3, but then we could run into the issue that some decoders may be able to handle Opus data from Ogg files but not Mkv files, and vice versa.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div> After seeking the same should apply: samples that are in the pre-skip timeframe should not be sent to the renderer as they are just there to get the codec started internally and to avoid having garbage if decoding was started right away.</div>
</div></div></div></blockquote><div style>Right, how are you specifically advocating we lay out the pre-skip data in a Matroska file?</div><div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888">
<div><br></div></font></span></div><span class=""><font color="#888888">-- <br>Steve Lhomme<br>Matroska association Chairman
</font></span></div></div>
<br>_______________________________________________<br>
Matroska-devel mailing list<br>
<a href="mailto:Matroska-devel@lists.matroska.org">Matroska-devel@lists.matroska.org</a><br>
<a href="http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel" target="_blank">http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel</a><br>
Read Matroska-Devel on GMane: <a href="http://dir.gmane.org/gmane.comp.multimedia.matroska.devel" target="_blank">http://dir.gmane.org/gmane.comp.multimedia.matroska.devel</a><br></blockquote></div><br></div></div>