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

Tue Oct 27 07:58:44 CET 2015

So this is indeed surprising to me that it is possible; nevertheless it is  
relieving to know that it is unlikely. And somehow satisfying to know that  
I am still learning new facts, being taught by experts who care, thank you  
all!

Am 26.10.2015, 18:21 Uhr, schrieb Deepthi Nandakumar  
<deepthi at multicorewareinc.com>:

> 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
>>
>>
>
>

-- 

Fun and success!
Mario *LigH* Rohkrämer
mailto:contact at ligh.de