remember that action does NOT differ your calculations for pulldown meaning the removal delay of the p-frame of the first GOP could be 2 while the removal delay for the p of the next gop could be 3.<br><br><div class="gmail_quote">
On Sun, Sep 20, 2009 at 1:13 PM, Trahald <span dir="ltr"><<a href="mailto:wewk584@gmail.com">wewk584@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
the cpb_removal_delay should be the same as if the frame were not an IDR. ie should not reset. The frame after that IDR however should act as tho the IDR DID reset.<br>ie<br>CPB REMOVAL DELAY<br>idr p b b b p p IDR p b b<br>
0 2 4 6 8 10 12 14 2 4 6<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Sun, Sep 20, 2009 at 2:55 AM, Alex Giladi <span dir="ltr"><<a href="mailto:alex.giladi@gmail.com" target="_blank">alex.giladi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Trahald,<br>
In case we use cpb=0 only after the first buffering SEI, what should<br>
be happening in case of a random access point, i.e. starting a<br>
playback from an arbitrary IDR (assuming that we repeat headers in<br>
front of each IDR)?<br>
<font color="#888888">Alex.<br>
</font><div><div></div><div><br>
On Sat, Sep 19, 2009 at 10:23 AM, Trahald <<a href="mailto:wewk584@gmail.com" target="_blank">wewk584@gmail.com</a>> wrote:<br>
> Elecard buffer analyser gives the message<br>
><br>
> "Can't continue the analysis.<br>
><br>
> The value of cpb_removal_delay equals 0 in the fist access unit of a<br>
> buffering period that does not initialise the HRD. It will ause invalid<br>
> timings of coded picture removal"<br>
><br>
> On Sat, Sep 12, 2009 at 10:47 PM, Jason Garrett-Glaser<br>
> <<a href="mailto:darkshikari@gmail.com" target="_blank">darkshikari@gmail.com</a>> wrote:<br>
>><br>
>> On Sat, Sep 12, 2009 at 7:36 PM, Alex Giladi <<a href="mailto:alex.giladi@gmail.com" target="_blank">alex.giladi@gmail.com</a>><br>
>> wrote:<br>
>> > All,<br>
>> > The attached patch adds support for buffering and picture timing<br>
>> > SEI's, allowing use of pulldown or/and writing NAL HRD.<br>
>> > The patch borrows a lot from two earlier patches, by Alex Izvorski and<br>
>> > by an unknown author (patch found on <a href="http://x264.nl" target="_blank">x264.nl</a>).<br>
>> > Hope you'll find it useful.<br>
>> > Alex.<br>
>><br>
>> This patch is probably slightly wrong due to the fact that, like<br>
>> Trahald's, it ignores NAL escape bytes, which do count as part of NAL<br>
>> HRD.<br>
>><br>
>> I am working on a fix for this.<br>
>><br>
>> Dark Shikari<br>
>> _______________________________________________<br>
>> x264-devel mailing list<br>
>> <a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
>> <a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> x264-devel mailing list<br>
> <a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
> <a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
><br>
><br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>