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

[Roshantha Mendis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20151026/7ea5244e/attachment-0001.html>