<div dir="ltr">Okay thank you for clearing that. Someone in the doom9 forum said its legal, but not efficient, so had to check. Thank you !<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 October 2015 at 08:47, Deepthi Nandakumar <span dir="ltr"><<a href="mailto:deepthi@multicorewareinc.com" target="_blank">deepthi@multicorewareinc.com</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">Mario - Yes, and P slices use only I-slices or other P-slices as reference.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 2:04 PM, Mario *LigH* Rohkrämer <span dir="ltr"><<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The question was about P slices.<br>
<br>
I would be surprised if P slices were allowed to have B slices as reference, which are below in hierarchy. From what I know (which may be partially limited to AVC), usually only more dependent types can reference less dependent types, to avoid error accumulation (quality reduction and even possible data errors with decoding artefacts in slices used as a reference will remain in all dependent slices):<br>
<br>
I(ntra) slices are independent, have no references (prediction generation 0).<br>
<br>
P(redicted) slices can have I slices as reference (prediction generation 1), possibly also previous P slices (not sure about this).<br>
<br>
B(idirectionally predicted) slices can have I and P slices as reference (prediction generation 2), and in a pyramid hierarchy even B slices which have no other B slices as possible reference.<br>
<br>
The more dependent a slice is, the more loss of quality may accumulate with each further prediction generation, therefore it should only be visible for a short time and less likely be used as reference for even more dependent slices and even more accumulation of quality loss. Because P slices could potentially be a reference of many dependent slices, it wouldn't make sense to allow them to have references in B slices which are already predicted in second or even third generation, compared to an original I(DR) slice of the current GOP.<br>
<br>
Disclaimer: I may not yet know about exceptions in HEVC. The statement above is based on knowledge from MPEG-1/2 to AVC.<div><div><br>
<br>
<br>
Am 26.10.2015, 04:31 Uhr, schrieb Aarthi Priya Thirumalai <<a href="mailto:aarthi@multicorewareinc.com" target="_blank">aarthi@multicorewareinc.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
When b-pyramid is on, then b slices can refer to both B , P and I slices.<br>
We are creating a hierarchy among B frames, that is some B frames can be<br>
used as reference for other b frames.<br>
<br>
Regards<br>
Aarthi<br>
On Oct 26, 2015 3:23 AM, "Roshantha Mendis" <<a href="mailto:hrm506@york.ac.uk" target="_blank">hrm506@york.ac.uk</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
When --b-pyramid  is set to true, can P-SLICES refer to B-SLICES ?<br>
<br>
I haven't come across a video sequence that this happens, but just want to<br>
know if this can happen.<br>
<br>
Also if this situation can occur, then is it valid according to the HEVC<br>
specs ?<br>
<br>
Many thanks<br>
<br>
--<br>
Rosh Mendis<br>
Research Student - EngD in LSCITS<br>
Dept. of Computer Science<br>
University of York<br>
<br>
Disclaimer: <a href="http://www.york.ac.uk/docs/disclaimer/email.htm" rel="noreferrer" target="_blank">http://www.york.ac.uk/docs/disclaimer/email.htm</a><br>
<br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br>
<br>
</blockquote></blockquote>
<br>
<br></div></div><span><font color="#888888">
-- <br>
<br>
Fun and success!<br>
Mario *LigH* Rohkrämer<br>
mailto:<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a></font></span><div><div><br>
<br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div>Deepthi Nandakumar<br></div>Engineering Manager, x265<br></div>Multicoreware, Inc<br></div></div>
</font></span></div>
<br>_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Rosh Mendis<div>Research Student - EngD in LSCITS</div><div>Dept. of Computer Science</div><div>University of York<br><br><span><font color="#888888">Disclaimer: <a href="http://www.york.ac.uk/docs/disclaimer/email.htm" target="_blank">http://www.york.ac.uk/docs/disclaimer/email.htm</a></font></span><br></div></div>
</div>