[x265] [Quesiton] Bitrate control problem when use CRF mode with set rc-lookhead is 0
zxy at rock-chips.com
zxy at rock-chips.com
Tue Feb 11 09:27:06 CET 2014
hi,x265-devel at videolan.org
I have test the case for foreman.yuv with paras
1. --no-wpp --psnr --ssim --rc-lookahead 0 --bframes 0 --b-adapt 1 --ref 1 --no-weightp --aq-mode 1 --no-cutree --threads 1 --output foreman_test1.h265 --input-res 352x288 --fps 25 --frame-skip 0 --frames 0 --input-depth 8 --input foreman.yuv --log 3 -f 20
2. --no-wpp --psnr --ssim --rc-lookahead 1 --bframes 0 --b-adapt 1 --ref 1 --no-weightp --aq-mode 1 --no-cutree --threads 1 --output foreman_test2.h265 --input-res 352x288 --fps 25 --frame-skip 0 --frames 0 --input-depth 8 --input foreman.yuv --log 3 -f 20
when set "rc-lookhead" to 0 ,the QP is too low then bitrate is too large.[1146.33 kb/s vs 186.31 kb/s]
I think it's better to initialize the QP with proper value with last frame QP, it can avoid the bitrate peak and keep PNSR to be acceptable.
the result log just below.
Thanks for you reply.
zxy at AlgorithmServer65:~/hevc/x265/test$ ./x265_exe --no-wpp --psnr --ssim --rc-lookahead 0 --bframes 0 --b-adapt 1 --ref 1 --no-weightp --aq-mode 1 --no-cutree --threads 1 --output foreman_test1.h265 --input-res 352x288 --fps 25 --frame-skip 0 --frames 0 --input-depth 8 --input foreman.yuv --log 3 -f 20
yuv [info]: 352x288 25Hz C420, frames 0 - 19 of 300
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2
x265 [info]: HEVC encoder version 0.7+74-1776b9a58585
x265 [info]: build info [Linux][GCC 4.4.3][64 bit] 8bpp
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: Parallelism disabled, single thread mode
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 0 / 0 / 1
x265 [info]: b-pyramid / weightp / refs : 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 0
x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide
POC 0 ( I-SLICE, nQP 25 QP 25) 63576 bits [Y: 39.60 U: 42.91 V: 45.11][SSIM: 0.955]
POC 1 ( P-SLICE, nQP 30 QP 30) 2808 bits [Y: 36.79 U: 42.57 V: 44.62][SSIM: 0.940] [L0 0 ]
POC 2 ( P-SLICE, nQP 27 QP 27) 8976 bits [Y: 37.13 U: 42.52 V: 44.51][SSIM: 0.940] [L0 1 ]
POC 3 ( P-SLICE, nQP 25 QP 25) 13136 bits [Y: 37.63 U: 42.42 V: 44.36][SSIM: 0.942] [L0 2 ]
POC 4 ( P-SLICE, nQP 22 QP 22) 29816 bits [Y: 39.01 U: 43.01 V: 45.25][SSIM: 0.951] [L0 3 ]
POC 5 ( P-SLICE, nQP 21 QP 21) 27744 bits [Y: 39.22 U: 43.07 V: 45.37][SSIM: 0.954] [L0 4 ]
POC 6 ( P-SLICE, nQP 19 QP 19) 49280 bits [Y: 40.98 U: 43.87 V: 46.50][SSIM: 0.953] [L0 5 ]
POC 7 ( P-SLICE, nQP 18 QP 18) 60680 bits [Y: 41.72 U: 44.56 V: 47.09][SSIM: 0.955] [L0 6 ]
POC 8 ( P-SLICE, nQP 18 QP 18) 45232 bits [Y: 41.66 U: 44.71 V: 47.10][SSIM: 0.956] [L0 7 ]
POC 9 ( P-SLICE, nQP 17 QP 17) 56856 bits [Y: 41.82 U: 44.77 V: 47.10][SSIM: 0.961] [L0 8 ]
POC 10 ( P-SLICE, nQP 17 QP 17) 56272 bits [Y: 41.90 U: 44.82 V: 47.18][SSIM: 0.959] [L0 9 ]
POC 11 ( P-SLICE, nQP 17 QP 17) 51240 bits [Y: 41.82 U: 44.78 V: 47.39][SSIM: 0.959] [L0 10 ]
POC 12 ( P-SLICE, nQP 17 QP 17) 61392 bits [Y: 41.99 U: 44.82 V: 47.33][SSIM: 0.961] [L0 11 ]
POC 13 ( P-SLICE, nQP 17 QP 17) 63944 bits [Y: 41.95 U: 44.81 V: 47.52][SSIM: 0.961] [L0 12 ]
POC 14 ( P-SLICE, nQP 17 QP 17) 59936 bits [Y: 41.86 U: 44.87 V: 47.37][SSIM: 0.964] [L0 13 ]
POC 15 ( P-SLICE, nQP 17 QP 17) 59024 bits [Y: 41.84 U: 44.78 V: 47.42][SSIM: 0.962] [L0 14 ]
POC 16 ( P-SLICE, nQP 17 QP 17) 54680 bits [Y: 41.67 U: 44.63 V: 47.33][SSIM: 0.961] [L0 15 ]
POC 17 ( P-SLICE, nQP 17 QP 17) 52816 bits [Y: 41.63 U: 44.58 V: 47.29][SSIM: 0.963] [L0 16 ]
POC 18 ( P-SLICE, nQP 17 QP 17) 50056 bits [Y: 41.57 U: 44.57 V: 47.33][SSIM: 0.963] [L0 17 ]
POC 19 ( P-SLICE, nQP 17 QP 17) 49600 bits [Y: 41.65 U: 44.61 V: 47.35][SSIM: 0.965] [L0 18 ]
x265 [info]: frame I: 1 kb/s: 1589.40 PSNR Mean: Y:39.601 U:42.914 V:45.110 SSIM Mean: 0.955334
x265 [info]: frame P: 19 kb/s: 1123.01 PSNR Mean: Y:40.728 U:44.147 V:46.600 SSIM Mean: 0.956271
x265 [info]: global : 20 kb/s: 1146.33 PSNR Mean: Y:40.672 U:44.085 V:46.526 SSIM Mean: 0.956224
encoded 20 frames in 3.08s (6.50 fps), 1146.33 kb/s, Global PSNR: 41.830, SSIM Mean Y: 0.9562239 (13.588 dB)
zxy at AlgorithmServer65:~/hevc/x265/test$ ./x265_exe --no-wpp --psnr --ssim --rc-lookahead 1 --bframes 0 --b-adapt 1 --ref 1 --no-weightp --aq-mode 1 --no-cutree --threads 1 --output foreman_test2.h265 --input-res 352x288 --fps 25 --frame-skip 0 --frames 0 --input-depth 8 --input foreman.yuv --log 3 -f 20
yuv [info]: 352x288 25Hz C420, frames 0 - 19 of 300
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2
x265 [info]: HEVC encoder version 0.7+74-1776b9a58585
x265 [info]: build info [Linux][GCC 4.4.3][64 bit] 8bpp
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: Parallelism disabled, single thread mode
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 1 / 0 / 1
x265 [info]: b-pyramid / weightp / refs : 0 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 0
x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide
POC 0 ( I-SLICE, nQP 25 QP 25) 63576 bits [Y: 39.60 U: 42.91 V: 45.11][SSIM: 0.955]
POC 1 ( P-SLICE, nQP 32 QP 32) 2176 bits [Y: 36.46 U: 42.55 V: 44.60][SSIM: 0.938] [L0 0 ]
POC 2 ( P-SLICE, nQP 31 QP 31) 4232 bits [Y: 35.89 U: 42.33 V: 44.00][SSIM: 0.931] [L0 1 ]
POC 3 ( P-SLICE, nQP 31 QP 31) 4160 bits [Y: 35.22 U: 41.98 V: 43.42][SSIM: 0.924] [L0 2 ]
POC 4 ( P-SLICE, nQP 31 QP 31) 4968 bits [Y: 35.36 U: 41.77 V: 43.44][SSIM: 0.924] [L0 3 ]
POC 5 ( P-SLICE, nQP 31 QP 31) 4304 bits [Y: 35.04 U: 41.46 V: 43.03][SSIM: 0.938] [L0 4 ]
POC 6 ( P-SLICE, nQP 30 QP 30) 5264 bits [Y: 35.19 U: 41.38 V: 43.24][SSIM: 0.929] [L0 5 ]
POC 7 ( P-SLICE, nQP 30 QP 30) 4592 bits [Y: 34.96 U: 41.31 V: 43.08][SSIM: 0.925] [L0 6 ]
POC 8 ( P-SLICE, nQP 30 QP 30) 5312 bits [Y: 35.01 U: 41.17 V: 43.00][SSIM: 0.921] [L0 7 ]
POC 9 ( P-SLICE, nQP 30 QP 30) 5240 bits [Y: 34.75 U: 41.11 V: 43.08][SSIM: 0.917] [L0 8 ]
POC 10 ( P-SLICE, nQP 30 QP 30) 5392 bits [Y: 34.72 U: 40.99 V: 42.93][SSIM: 0.929] [L0 9 ]
POC 11 ( P-SLICE, nQP 30 QP 30) 5232 bits [Y: 34.68 U: 41.06 V: 42.93][SSIM: 0.923] [L0 10 ]
POC 12 ( P-SLICE, nQP 31 QP 31) 4400 bits [Y: 34.20 U: 40.93 V: 42.87][SSIM: 0.919] [L0 11 ]
POC 13 ( P-SLICE, nQP 31 QP 31) 5568 bits [Y: 34.05 U: 40.79 V: 42.75][SSIM: 0.916] [L0 12 ]
POC 14 ( P-SLICE, nQP 31 QP 31) 5608 bits [Y: 33.90 U: 40.51 V: 42.54][SSIM: 0.913] [L0 13 ]
POC 15 ( P-SLICE, nQP 31 QP 31) 5216 bits [Y: 33.89 U: 40.54 V: 42.62][SSIM: 0.922] [L0 14 ]
POC 16 ( P-SLICE, nQP 31 QP 31) 3408 bits [Y: 33.29 U: 40.42 V: 42.63][SSIM: 0.916] [L0 15 ]
POC 17 ( P-SLICE, nQP 31 QP 31) 3272 bits [Y: 33.09 U: 40.31 V: 42.45][SSIM: 0.912] [L0 16 ]
POC 18 ( P-SLICE, nQP 30 QP 30) 3976 bits [Y: 33.26 U: 40.38 V: 42.47][SSIM: 0.910] [L0 17 ]
POC 19 ( P-SLICE, nQP 30 QP 30) 3152 bits [Y: 33.07 U: 40.32 V: 42.32][SSIM: 0.906] [L0 18 ]
x265 [info]: frame I: 1 kb/s: 1589.40 PSNR Mean: Y:39.601 U:42.914 V:45.110 SSIM Mean: 0.955334
x265 [info]: frame P: 19 kb/s: 112.46 PSNR Mean: Y:34.528 U:41.122 V:43.021 SSIM Mean: 0.921697
x265 [info]: global : 20 kb/s: 186.31 PSNR Mean: Y:34.782 U:41.212 V:43.126 SSIM Mean: 0.923379
encoded 20 frames in 1.54s (12.95 fps), 186.31 kb/s, Global PSNR: 36.629, SSIM Mean Y: 0.9233790 (11.157 dB)
zxy at AlgorithmServer65:~/hevc/x265/test$
zxy at rock-chips.com
From: x265-devel-request
Date: 2014-02-11 11:02
To: x265-devel
Subject: x265-devel Digest, Vol 9, Issue 39
Send x265-devel mailing list submissions to
x265-devel at videolan.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.videolan.org/listinfo/x265-devel
or, via email, send a message with subject or body 'help' to
x265-devel-request at videolan.org
You can reach the person managing the list at
x265-devel-owner at videolan.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of x265-devel digest..."
Today's Topics:
1. Re: I would like to contribute to x265 (dave)
2. Re: I would like to contribute to x265 (Deepthi Nandakumar)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Feb 2014 17:44:06 -0800
From: dave <dtyx265 at gmail.com>
To: Development for x265 <x265-devel at videolan.org>
Subject: Re: [x265] I would like to contribute to x265
Message-ID: <52F98066.7010105 at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
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-0001.html>
------------------------------
Message: 2
Date: Tue, 11 Feb 2014 08:32:39 +0530
From: Deepthi Nandakumar <deepthi at multicorewareinc.com>
To: Development for x265 <x265-devel at videolan.org>
Subject: Re: [x265] I would like to contribute to x265
Message-ID:
<CAAEo3uiSdFneptWqs8b01UxWUm5fzMGp4t-Jr0uxjDYqr36_6w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Can you take a look at what the following does? Does the decoder actually
detect HRD parameters?
# HG changeset patch
# User Deepthi Nandakumar <deepthi at 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 <dtyx265 at gmail.com> wrote:
> On 02/10/2014 01:41 PM, Steve Borho wrote:
>
>
>
>
> On Mon, Feb 10, 2014 at 1:46 PM, dave <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> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jan 29, 2014 at 5:13 PM, dave <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 listx265-devel at 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 at 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 at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140211/eee98c0b/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
x265-devel mailing list
x265-devel at videolan.org
https://mailman.videolan.org/listinfo/x265-devel
------------------------------
End of x265-devel Digest, Vol 9, Issue 39
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140211/7b251425/attachment-0001.html>
More information about the x265-devel
mailing list