[x265] x265-devel Digest, Vol 29, Issue 69

[Deepthi Nandakumar]

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.

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.



On Mon, Oct 26, 2015 at 10:28 PM, Roshantha Mendis <hrm506 at york.ac.uk>
wrote:

> Thank you for your informative replies.
>
> 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.
>
> 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..
>
>
>
> On 26 October 2015 at 16:33, Hoang Dzung <Dzung.Hoang at freescale.com>
> wrote:
>
>> 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.
>>
>> 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.
>>
>> If not already supported, I encourage the x265 development team to
>> optimize the reference list based upon scene change information.
>>
>> Best regards,
>> - Dzung Hoang
>> @Freescale
>>
>>
>>
>> -----Original Message-----
>> From: x265-devel [mailto:x265-devel-bounces at videolan.org] On Behalf Of
>> Joshua Bowman
>> Sent: Monday, October 26, 2015 5:50 AM
>> To: x265-devel at videolan.org
>> Subject: Re: [x265] x265-devel Digest, Vol 29, Issue 69
>>
>> On Mon, 26 Oct 2015 09:34:33 +0100, Mario *LigH* Rohkr?mer <
>> contact at ligh.de> wrote:
>> > P(redicted) slices can have I slices as reference (prediction
>> > generation 1), possibly also previous P slices (not sure about this).
>> >
>> > 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.
>> On Mon, 26 Oct 2015 14:17:13 +0530, Deepthi Nandakumar <
>> deepthi at multicorewareinc.com> wrote:
>> > Mario - Yes, and P slices use only I-slices or other P-slices as
>> reference.
>>
>> 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.
>>
>> 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.
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>
>
>
> --
> Rosh Mendis
> Research Student - EngD in LSCITS
> Dept. of Computer Science
> University of York
>
> Disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>


-- 
Deepthi Nandakumar
Engineering Manager, x265
Multicoreware, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20151026/e7b778cd/attachment.html>