Hi,
Can you take a look at what the following does? Does the decoder actually
detect HRD parameters?
# HG changeset patch
# User Deepthi Nandakumar <deep...@multicorewareinc.com>
# Date 1387524067 -19800
# Node ID 3e794e059f7ffe0edaaf5432df5297631a0f44f6
# Parent 8133378e225020dbdd747d42a021588bef679ec3
Enable VUI
diff -r 8133378e2250 -r 3e794e059f7f source/encoder/encoder.cpp
--- a/source/encoder/encoder.cpp Thu Dec 19 17:47:16 2013 +0530
+++ b/source/encoder/encoder.cpp Fri Dec 20 12:51:07 2013 +0530
@@ -1367,13 +1367,13 @@
m_bUseASR = false; // adapt search range based on temporal distances
m_recoveryPointSEIEnabled = 0;
m_bufferingPeriodSEIEnabled = 0;
- m_pictureTimingSEIEnabled = 0;
+ m_pictureTimingSEIEnabled = 1;
m_displayOrientationSEIAngle = 0;
m_gradualDecodingRefreshInfoEnabled = 0;
m_decodingUnitInfoSEIEnabled = 0;
m_useScalingListId = 0;
m_activeParameterSetsSEIEnabled = 0;
- m_vuiParametersPresentFlag = false;
+ m_vuiParametersPresentFlag = true;
m_minSpatialSegmentationIdc = 0;
m_aspectRatioIdc = 0;
m_sarWidth = 0;
diff -r 8133378e2250 -r 3e794e059f7f source/encoder/frameencoder.cpp
--- a/source/encoder/frameencoder.cpp Thu Dec 19 17:47:16 2013 +0530
+++ b/source/encoder/frameencoder.cpp Fri Dec 20 12:51:07 2013 +0530
@@ -136,7 +136,7 @@
m_sps.setNumLongTermRefPicSPS(0);
if (m_cfg->getPictureTimingSEIEnabled() ||
m_cfg->getDecodingUnitInfoSEIEnabled())
{
- m_sps.setHrdParameters(m_cfg->param.frameRate, 0,
m_cfg->param.rc.bitrate, m_cfg->param.bframes > 0);
+ m_sps.setHrdParameters(m_cfg->param.frameRate, 1,
m_cfg->param.rc.bitrate, m_cfg->param.bframes > 0);
}
if (m_cfg->getBufferingPeriodSEIEnabled() ||
m_cfg->getPictureTimingSEIEnabled() ||
m_cfg->getDecodingUnitInfoSEIEnabled())
{
Thanks,
Deepthi
On Tue, Feb 11, 2014 at 7:14 AM, dave <dtyx...@gmail.com> wrote:
> On 02/10/2014 01:41 PM, Steve Borho wrote:
>
>
>
>
> On Mon, Feb 10, 2014 at 1:46 PM, dave <dtyx...@gmail.com> wrote:
>
>> On 02/10/2014 10:41 AM, Steve Borho wrote:
>>
>>
>>
>>
>> On Thu, Jan 30, 2014 at 12:31 PM, Steve Borho <st...@borho.org> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jan 29, 2014 at 5:13 PM, dave <dtyx...@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
>> listx265-devel@videolan.orghttps://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
> listx265-devel@videolan.orghttps://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.
>
> _______________________________________________
> x265-devel mailing list
> x265-devel@videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
