[x265] I would like to contribute to x265

dave dtyx265 at gmail.com
Tue Feb 11 02:44:06 CET 2014


On 02/10/2014 01:41 PM, Steve Borho wrote:
>
>
>
> On Mon, Feb 10, 2014 at 1:46 PM, dave <dtyx265 at gmail.com 
> <mailto:dtyx265 at gmail.com>> wrote:
>
>     On 02/10/2014 10:41 AM, Steve Borho wrote:
>>
>>
>>
>>     On Thu, Jan 30, 2014 at 12:31 PM, Steve Borho <steve at borho.org
>>     <mailto:steve at borho.org>> wrote:
>>
>>
>>
>>
>>         On Wed, Jan 29, 2014 at 5:13 PM, dave <dtyx265 at gmail.com
>>         <mailto:dtyx265 at gmail.com>> wrote:
>>
>>             Hi All,
>>
>>             I would like to offer my services and contribute to x265
>>             development.  From the wiki it looks like there are
>>             plenty things to do but I don't want to duplicate or
>>             interfere with the work of anyone else so if someone can
>>             give me something to do I would appreciate it.  I am open
>>             to anything needed by x265, both c/c++ and assembly work
>>             though I don't mind being given something simple just to
>>             get started.  You can find me in the x265 irc channel as
>>             dtyx265.
>>
>>
>>         Hi Dave.
>>
>>         I've been collecting the more pressing TODO items in the
>>         bitbucket repository's issue tracker:
>>         https://bitbucket.org/multicoreware/x265/issues?status=new&status=open
>>
>>
>>         #21 (enabling the VUI message) is the most pressing of the
>>         "simple" problems.  That would be a great place to start.
>>
>>
>>     Hi Dave,
>>
>>     How are things going on this front?
>>
>>     -- 
>>     Steve Borho
>>
>>
>>     _______________________________________________
>>     x265-devel mailing list
>>     x265-devel at videolan.org  <mailto:x265-devel at videolan.org>
>>     https://mailman.videolan.org/listinfo/x265-devel
>     I studied the VUI in the h265 spec, appendix E and have been
>     studying the x265 code from your suggested starting point,
>     setVuiParametersPresentFlag().  It looks like most fields are set
>     to spec defaults.  Some look like values that can be options
>     specified by the user, others look like values that are calculated
>     from encoding a video.
>
>     Can you tell me more about just what pts and dts are?  I
>     understand generally what they are but it seems like there are a
>     few places in the VUI where they might play a role in calculating
>     values.  I haven't had a chance yet to compare to x264 code yet so
>     if it all becomes obvious there then I will get it.
>
>
> pts is the presentation time stamp of a frame, the point at which it 
> is supposed to be displayed by the decoder.
>
> dts is the decode time stamp of a frame, the point when the decoder is 
> supposed to begin decoding it.
>
> Both are usually specified in units of the frame rate.  Since the pts 
> & dts are frame parameters and the VUI is a stream parameter, I don't 
> they are directly related, except that the denominator is likely 
> signaled in some way.
>
>     I tried to create a user account on bitbucket so I could have
>     issue 21 assigned to me but I keep getting
>
>
> BB might not allow issues to be assigned to users who don't have push 
> access anyway, so don't be too concerned about this.  You can add a 
> comment to the issue stating you are working on it.  Patches should go 
> through this mailing list anyway.
>
> --
> Steve
>
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
I think the denominator that you are looking for is already set in class 
TimingInfo.  vui_num_units_in_tick(confusingly named, if I understand it 
correctly) and vui_time_scale are set based on frame rate.  The other 
TimingInfo members that are not set depend on the consistency of timing 
of the frames.

One other possibility is the hrd parameter m_tickDivisorMinus2.  It is 
set to 100 - 2 in TComSPS::setHrdParameters though given the description 
of tic_divisor_minus2 in the spec I am not sure if this is an accurate 
or useful value.

Since it looks like currently no VUI is generated, perhaps I should just 
add what's needed so a VUI can optionally be added to an encoded video 
along with filling out the rest of the VUI's fields.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140210/de2e0d61/attachment.html>


More information about the x265-devel mailing list