<div dir="ltr"><div><div>It is true that from an HEVC standard point of view, P frames referencing B-Refs are not forbidden. However, x265 makes sure that the DPB is big enough that the preceding P-frame always stays available. <br><br></div>Mario's point of accumulating errors for each layer of reference is also perfectly true. In x265, this comes by way of ratecontrol (QpB >= QpBRef >= QpP >= QpI). This being the case, the cost of a P frame referencing a (lower quality) B-ref is higher, and therefore less likely. <br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 10:28 PM, Roshantha Mendis <span dir="ltr"><<a href="mailto:hrm506@york.ac.uk" target="_blank">hrm506@york.ac.uk</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"><div><div><div>Thank you for your informative replies. <br></div><div><br></div>Is there logic in x265 to somehow calculate the best candidate reference frame from the DPB ? some sort of calculation perhaps ? Like Joshua said does x265 enforce a 'strict hierarchical encoding' ? Blu-ray encoding for example I think enforces that no P-frames refer to B-frames.<br><br></div>Because I have never seen a P-frame referencing a B-frame in any of the videos I've encoded. Maybe some sort of parameter might trigger this I guess. Of course I am only using a max of 2 ref frames in encoder settings. Maybe a higher ref frame count might trigger this..<br><br></div><br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 26 October 2015 at 16:33, Hoang Dzung <span dir="ltr"><<a href="mailto:Dzung.Hoang@freescale.com" target="_blank">Dzung.Hoang@freescale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What Joshua said is correct. I'd like to add a use case where a P slice might be better than a B slice. Consider a scene change where the forward and backward references are in different scenes. Using a P slice with a reference from the same scene is likely better than using a B slice where the two references are in different scenes. With a B slice, it is possible to observe "bleed-through" artifacts where some content from the other scene is blended in with content from the current scene.<br>
<br>
With that said, it is possible to use a B slice and improve upon the P slice if both list 0 and list 1 references were chosen from the same scene as the current picture.<br>
<br>
If not already supported, I encourage the x265 development team to optimize the reference list based upon scene change information.<br>
<br>
Best regards,<br>
- Dzung Hoang<br>
@Freescale<br>
<div><div><br>
<br>
<br>
-----Original Message-----<br>
From: x265-devel [mailto:<a href="mailto:x265-devel-bounces@videolan.org" target="_blank">x265-devel-bounces@videolan.org</a>] On Behalf Of Joshua Bowman<br>
Sent: Monday, October 26, 2015 5:50 AM<br>
To: <a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
Subject: Re: [x265] x265-devel Digest, Vol 29, Issue 69<br>
<br>
On Mon, 26 Oct 2015 09:34:33 +0100, Mario *LigH* Rohkr?mer <<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a>> wrote:<br>
> P(redicted) slices can have I slices as reference (prediction<br>
> generation 1), possibly also previous P slices (not sure about this).<br>
><br>
> B(idirectionally predicted) slices can have I and P slices as<br>
> reference (prediction generation 2), and in a pyramid hierarchy even B<br>
> slices which have no other B slices as possible reference.<br>
On Mon, 26 Oct 2015 14:17:13 +0530, Deepthi Nandakumar <<a href="mailto:deepthi@multicorewareinc.com" target="_blank">deepthi@multicorewareinc.com</a>> wrote:<br>
> Mario - Yes, and P slices use only I-slices or other P-slices as reference.<br>
<br>
This is incorrect. P-blocks may reference any one previously encoded frame in the DPB, while B-blocks may reference any two previously encoded frames, that's the only difference between them. (No frame is explicitly marked reference or non-reference, but they fall out of the DPB if they are unreferenced.) A P-frame may only have I- and P-blocks, a B-frame may have I-, P-, and B-blocks. Each frame has two lists of a practically unlimited number of references frames (2^16 short-term, 2^24 long-term) for each block to use, P-frames getting one list and B-frames two, but realistic DPB limits and usefulness mean lists are rarely more than a few frames long. A strict hierarchical encoding will enforce that no P references a B and no B-ref references a throwaway B, but the spec allows much more flexibility than that; strict hierarchical is just a poor-man's temporal scaling, and there's no need to emulate MPEG-1 with HEVC.<br>
<br>
Reference list management is easily one of the most complex parts of the spec. That's why simplifications are usually used, but it's absolutely possible to do more.<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>
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>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>
</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"><div dir="ltr"><div><div>Deepthi Nandakumar<br></div>Engineering Manager, x265<br></div>Multicoreware, Inc<br></div></div>
</div>