Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

Thanks!

- Derek

On 11/15/2021 12:01 PM, Mahesh Pittala wrote:
> Sincere apologies for taking more time than expected, pushing it to the 
> master branch.
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
>
> On Sun, Nov 14, 2021 at 7:41 PM Derek Buitenhuis  
> wrote:
>
> On 11/1/2021 4:09 PM, Derek Buitenhuis wrote:
> > Ping.
>
> Ping. I've provided a definitive reference document, and this has been in 
> prod,
> and made it through Dolby's bitsteam verifier. It's an extremely simple 
> change.
>
> - Derek
> ___
> 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

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

On 11/1/2021 4:09 PM, Derek Buitenhuis wrote:
> Ping.

Ping. I've provided a definitive reference document, and this has been in prod,
and made it through Dolby's bitsteam verifier. It's an extremely simple change.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

On 10/12/2021 1:53 PM, Derek Buitenhuis wrote:
> 8.4 is the same as the other profile 8s, except with an HLG base layer,
> that is, CICP codepoint 18 (ARIB-STD-B67), as noted, for example, here
> (embeds + contains PDF link):
> 
> https://professionalsupport.dolby.com/s/article/What-is-Dolby-Vision-Profile?language=en_US
> 
> Section 2.1 is probably what you want.
> 
> It's worth noting this patch is what we use for our (Vimeo's) 8.4 support.
> Not sure what I can officially say, but you can draw your own conclusions :).

Ping.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

Hello,

Reply below.

On 10/12/2021 1:13 PM, Siva Viswanathan wrote:
> We already started looking at it and we realized that we need 8.4 profile 
> spec to validate the implementation, hence the delay here
> 
> Please share the relevant info

8.4 is the same as the other profile 8s, except with an HLG base layer,
that is, CICP codepoint 18 (ARIB-STD-B67), as noted, for example, here
(embeds + contains PDF link):

https://professionalsupport.dolby.com/s/article/What-is-Dolby-Vision-Profile?language=en_US

Section 2.1 is probably what you want.

It's worth noting this patch is what we use for our (Vimeo's) 8.4 support.
Not sure what I can officially say, but you can draw your own conclusions :).

- Derek

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

On 10/10/2021 11:51 AM, Derek Buitenhuis wrote:
> Ping again - it is a very simple patch, an we've had it in production
> for a while now.

Third ping.

I see that quite significant patches from MCW get OKed and pushed
within minutes of hitting the mailing list.

What I surmise from this is that x265 is now only nominally open
source; the mailing list being just performative?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

On 10/1/2021 11:36 AM, Derek Buitenhuis wrote:
> Ping.

Ping again - it is a very simple patch, an we've had it in production
for a while now.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

On Tuesday, September 28, 2021, Derek Buitenhuis 
wrote:

> Signed-off-by: Derek Buitenhuis 
> ---
>  doc/reST/cli.rst   | 2 +-
>  source/common/param.cpp| 8 
>  source/encoder/encoder.cpp | 3 ++-
>  3 files changed, 7 insertions(+), 6 deletions(-)


Ping.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH] Add Dolby Vision 8.4 Profile Support

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
 doc/reST/cli.rst   | 2 +-
 source/common/param.cpp| 8 
 source/encoder/encoder.cpp | 3 ++-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/doc/reST/cli.rst b/doc/reST/cli.rst
index b24fa72a9..56a94593a 100755
--- a/doc/reST/cli.rst
+++ b/doc/reST/cli.rst
@@ -2567,7 +2567,7 @@ Bitstream options
 The value is specified as a float or as an integer with the profile times 
10,
 for example profile 5 is specified as "5" or "5.0" or "50".
 
-Currently only profile 5, profile 8.1 and profile 8.2 enabled, Default 0 
(disabled)
+Currently only profile 5, profile 8.1, profile 8.2 and profile 8.4  
enabled, Default 0 (disabled)
 
 .. option:: --dolby-vision-rpu 
 
diff --git a/source/common/param.cpp b/source/common/param.cpp
index 6751e0aa7..dd9eb83e2 100755
--- a/source/common/param.cpp
+++ b/source/common/param.cpp
@@ -1834,15 +1834,15 @@ int x265_check_params(x265_param* param)
 "Invalid refine-ctu-distortion value, must be either 0 or 1");
 CHECK(param->maxAUSizeFactor < 0.5 || param->maxAUSizeFactor > 1.0,
 "Supported factor for controlling max AU size is from 0.5 to 1");
-CHECK((param->dolbyProfile != 0) && (param->dolbyProfile != 50) && 
(param->dolbyProfile != 81) && (param->dolbyProfile != 82),
-"Unsupported Dolby Vision profile, only profile 5, profile 8.1 and 
profile 8.2 enabled");
+CHECK((param->dolbyProfile != 0) && (param->dolbyProfile != 50) && 
(param->dolbyProfile != 81) && (param->dolbyProfile != 82) && 
(param->dolbyProfile != 84),
+"Unsupported Dolby Vision profile, only profile 5, profile 8.1, 
profile 8.2 and profile 8.4 enabled");
 CHECK(param->dupThreshold < 1 || 99 < param->dupThreshold,
 "Invalid frame-duplication threshold. Value must be between 1 and 
99.");
 if (param->dolbyProfile)
 {
 CHECK((param->rc.vbvMaxBitrate <= 0 || param->rc.vbvBufferSize <= 0), 
"Dolby Vision requires VBV settings to enable HRD.\n");
-CHECK((param->internalBitDepth != 10), "Dolby Vision profile - 5, 
profile - 8.1 and profile - 8.2 is Main10 only\n");
-CHECK((param->internalCsp != X265_CSP_I420), "Dolby Vision profile - 
5, profile - 8.1 and profile - 8.2 requires YCbCr 4:2:0 color space\n");
+CHECK((param->internalBitDepth != 10), "Dolby Vision profile - 5, 
profile - 8.1, profile - 8.2 and profile - 8.4 are Main10 only\n");
+CHECK((param->internalCsp != X265_CSP_I420), "Dolby Vision profile - 
5, profile - 8.1, profile - 8.2 and profile - 8.4 requires YCbCr 4:2:0 color 
space\n");
 if (param->dolbyProfile == 81)
 CHECK(!(param->masteringDisplayColorVolume), "Dolby Vision profile 
- 8.1 requires Mastering display color volume information\n");
 }
diff --git a/source/encoder/encoder.cpp b/source/encoder/encoder.cpp
index dee8fd85d..ec95de012 100644
--- a/source/encoder/encoder.cpp
+++ b/source/encoder/encoder.cpp
@@ -72,7 +72,8 @@ DolbyVisionProfileSpec dovi[] =
 {
 { 1, 1, 1, 1, 1, 5, 1,  2, 2, 2, 50 },
 { 1, 1, 1, 1, 1, 5, 0, 16, 9, 9, 81 },
-{ 1, 1, 1, 1, 1, 5, 0,  1, 1, 1, 82 }
+{ 1, 1, 1, 1, 1, 5, 0,  1, 1, 1, 82 },
+{ 1, 1, 1, 1, 1, 5, 0, 18, 9, 9, 84 }
 };
 
 typedef struct
-- 
2.32.0

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Fix for build error in ffmpeg

[Derek Buitenhuis]

On 25/07/2018 10:00, as...@multicorewareinc.com wrote:
> --- a/source/x265.h   Mon Jul 23 15:36:44 2018 +0530
> +++ b/source/x265.h   Wed Jul 25 11:27:46 2018 +0530
> @@ -169,7 +169,7 @@
>   uint32_t log2WeightDenom;
>   int  inputWeight;
>   int  inputOffset;
> -bool bPresentFlag;
> +int  wtPresent;
>   }x265_weight_param;

I think this needs a build number bump.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Fix: Build error in VS 11

[Derek Buitenhuis]

On 24/07/2018 18:48, Ashok Kumar Mishra wrote:
> We have decided to back out the latest commit "Fix: Build error in VS 11", so 
> that it can solve the building issue in ffmpeg.
> We are not going to support MSVC 11 anymore.

Hi,

As noted in my reply to j-b, my 2 cents is that this is still problematic.

No C, C++, or ABI (C or otherwise) standard, to my knowledge, guarantees
sizeof(bool), so passing a struct around which contains one may lead to
ABI problems, as far as I can tell.

Whether we think it's real or theoretical, though, is up for debate.

I do know at least one (oddball) compiler that used to set bool==int,
while most set bool==char.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Fix: Build error in VS 11

[Derek Buitenhuis]

On 23/07/2018 23:17, Jean-Baptiste Kempf wrote:
> Proper fix is to use a correct toolchain, not a 5+ years one.
> And if toolchain is broken, add a header there to work-around.

You can argue that, but I think for a commercial thing like x265,
it's a non-starter to require C99.

Further, I am not sure it is even kosher to mix C99 bool and C++
bool like this; I am not sure they are even comptible - at least,
I don't think there are any guarantees.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Fix: Build error in VS 11

[Derek Buitenhuis]

On 23/07/2018 13:19, Ashok Kumar Mishra wrote:
> Pushed.

This broke a lot of applications by now requiring users include stdbool.h
before x265.h if they are using anything but MSVC.

AKA it broke all non-MSVC builds.

Proper fix is to not use bool in the header in the first place.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Add support for customizing logging

[Derek Buitenhuis]

On 3/18/2018 10:29 PM, Andrey Semashev wrote:
> Normally, there is only one _application_. There may be multiple 
> _libraries_ using libx265 but none of them should be configuring its 
> logging, unless it is supposed to be the only one using libx265 in the 
> application (and generic libraries cannot make that assumption). It is 
> the application that should configure logging in every component it uses.

That's a lot of 'should' that relies on different API users doing the
'right thing'...

> 
> That said, I myself would prefer to configure logging on per-encoder 
> basis, although for different reasons. But the way x265 is currently 
> written does not allow this because in many places logging is done 
> without any encoder context. I'm not willing to rewrite x265 to support 
> this as global logging customization is "good enough" for me. It 
> certainly is much better than unconditionally logging to stdout.

It is indeed a lot of work to do properly. It is up to x265 whether they
prefer this amount of work, or to add the implementation as it currently
is and support that API for however long they need to.

>> Further, defining user types ending in _t is not allowed in C (which this
>> header is, and is used from), and x265 does not do this.
> 
> I'm not aware of this limitation. In particular, C11 section 7.1.3 
> contains no such restriction. Can you provide a reference to the part of 
> the C standard that says this?

Sorry, I meant POSIX, see: B.2.12 Data Types. Yes, POSIX is quite relevant
still.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Add support for customizing logging

[Derek Buitenhuis]

On 3/16/2018 3:28 PM, Andrey Semashev wrote:
> +/* x265_set_log:
> + *   Sets a custom logger function */
> +void x265_set_log(x265_log_t log);

I would like to voice my distaste for this implementation.

This is a global callback, and will introduce problems with e.g. multiple
libraries or dependencies in a program have libx265 as a dependency, or even
with multiple encoders in the same program are used.

Consider program A that has B as a dependency, both of which use libx265:

A - libx265
  - B
  - libx265

Either A or B could set the log callback for x265, and it would take
over for both. This is not ideal, and it is the same design mistake
we at FFmpeg made a long time ago, which has been haunting us for years.

Further, defining user types ending in _t is not allowed in C (which this
header is, and is used from), and x265 does not do this.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] unsigned promotion prevents encoding frames with negative strides

[Derek Buitenhuis]

On 1/17/2018 4:31 PM, chen wrote:
> Thank you report this bug.
> I think the root cause is not sizeof(), the negative stride is invalid in 
> encoder/decoder core.
> To avoid these invalid input parameters, the x264 insert a middle-layer that 
> convert color space and images, but x265 doesn't it.
> 
> Of course, crash is worst way to report invalid input parameters, we will fix 
> it soon.

Hi,

Negative strides are quite standard in the image processing world, and I think
x265 would be better off properly supporting them (as it does in its API 
currently)
than rejecting them

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] x265.h: change references into pointers for C compatibility

[Derek Buitenhuis]

On 11/12/2017 8:30 PM, Ma0 wrote:
> # HG changeset patch
> # User Ma0 
> # Date 1510517111 -3600
> #  Sun Nov 12 21:05:11 2017 +0100
> # Node ID 06d89671aec95337c3b458985bd1f5361bf61bb0
> # Parent  563cbe1f4a21dcfe2117ccaa874b713d94434f92
> x265.h: change references into pointers for C compatibility
> 
> Commit 563cbe1 'api: move csv and dither functions into api structure'
> inserts to x265.h C++ only specific code (references) that broke
> compatibility with C compilers. This patch fixes this by changing
> code style only.

Ping on this. All code calling libx265 from C, such as FFmpeg, is currently 
broken.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Proposed solution to mixed 8/10 bit libraries

[Derek Buitenhuis]

On 3/31/2015 8:33 PM, Steve Borho wrote:

 /* fill in provided x265_api structure with methods suited for
  * the provided encoder parameters. If 'p' is NULL you will get
  * the system default libx265 library methods */
 void x265_get_api(x265_api* api, x265_param* p);

Relevant chat from IRC:

[21:29]  Daemon404 i think the general approach seems sane
[21:29]  Daemon404 i assume the API pointer returned would be static
[21:29]  Daemon404 i.e. not alloc'd
[21:31]  muggs user allocated, you're passing in a struct you alloc
[21:31]  muggs I'm not sure if that's important
[21:32]  Daemon404 hmm
[21:32]  muggs it could be static, save a bit of work
[21:33]  Daemon404 
https://github.com/vapoursynth/vapoursynth/blob/master/src/core/vsapi.cpp#L636
[21:33]  Daemon404 i was thinking like that
[21:33]  Daemon404 (struct is above it)
[21:33]  Daemon404 and below
[21:36]  muggs yeah, something similar could work
[21:37]  muggs the build number could be an argument
[21:37]  Daemon404 its a matter of opinion/taste i suppose
[21:38]  muggs a little bike-shedding doesn't hurt


 This could be used for more than just selecting between Main and Main10
 builds, it could also select between PGO builds targeted for different
 use cases (file transcode vs real-time, etc).

I find it hard to believe this could provide a tangible speed benefit. Wouldn't
it be saner to profile everything for one build?

 The user applications don't have to be aware of the multi-lib details,
 and they should be able to use 8bpp and 16bpp encoders simultaneously
 within the same process, if they need to.

+1

- Derek

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Fwd: Encoding question

[Derek Buitenhuis]

On 1/20/2015 7:04 AM, Mario *LigH* Rohkrämer wrote:
 Encoding of partially covered motion is a pretty tough issue. MPEG-7 tries  
 to model layers of shapes, but that's the next generation... For current  
 encoders, more bitrate may be one of the best recommendations.

I think what Sebastian was asking for is something like a quantizer
offset mask similar to what libx264 offers. It is not exposed in
the x264 cli, but it is in the API.

See: https://mailman.videolan.org/pipermail/x264-devel/2010-June/007336.html

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Basic support for tweaking rate control using zones

[Derek Buitenhuis]

On 12/23/2014 6:03 AM, Deepthi Nandakumar wrote:
 Thanks for your patch. I'm not quite sure any of our regular users need this 
 as of now. We will keep this on standby though - until any requests come in.

Zones are fairly popular on e.g. Doom9 and within the the anime
community.

I don't really understand the point of keeping it on ice until
you get a request — is it going to hurt?

Cheers,
- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] x265 ignores SAR (derived from Y4M header or as CLI flag)

[Derek Buitenhuis]

On 11/4/2014 7:26 AM, Mario *LigH* Rohkrämer wrote:
 MPC-HC will probably rely on internal MediaInfo analysis results, so I'll  
 have a look at their bug tracker.

Out of curiosity, have you checked what ffmpeg or ffprobe say?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] x265 ignores SAR (derived from Y4M header or as CLI flag)

[Derek Buitenhuis]

On 11/4/2014 1:36 PM, Mario *LigH* Rohkrämer wrote:
 ffprobe recognizes AR flags correctly, both in raw output and multiplexed  
 into MP4 by MP4Box.

[...]

 Some tools (like VLC) may prefer container flags and don't find any if  
 MP4Box doesn't use any, possibly because it doesn't analyze HEVC streams  
 detailed enough. VLC can't play raw HEVC anyway. MPC-HC respects raw HEVC  
 AR flags, but reports SAR 1.0 always for MP4, so MP4Box is probably  
 another factor here. MediaInfo reports SAR 1.0 for both HEVC raw and in  
 MP4.

It's possible that MP4Box writes a broken (1.0) par box, or a broken display 
res.

Maybe you can try muxing to MP4 with libavformat (ffmpeg) or L-SMASH?

I'll probably try tomorrow and see.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] use std::swap() for readability

[Derek Buitenhuis]

On 7/9/2014 11:16 AM, Deepthi Nandakumar wrote:
 We spent a bunch of effort last year to remove STL dependencies, since they 
 cause serious trouble between different compilers (even between different 
 compiler versions).  This is especially since a lot of users will use x265 as 
 a static library.

I tried to ask about this before to no avail: What compilers and how?

STL portability has not been an issue for a very long time.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] api: allow lambda tables to be user-specified via a text file

[Derek Buitenhuis]

On 7/2/2014 11:22 PM, Steve Borho wrote:
 # HG changeset patch
 # User Steve Borho st...@borho.org
 # Date 1404339662 18000
 #  Wed Jul 02 17:21:02 2014 -0500
 # Node ID 6da77093c4b2db20dfafa7ff5994294ba3773f24
 # Parent  b90fdc3ffb962ddd4baf1309a5d6ffa3908f0486
 api: allow lambda tables to be user-specified via a text file
 
 This change allows easy experimentation with the lambda tables. One can
 cut-paste the existing tables from TComRom.cpp into a text file and hash(#)
 comment the C constructs (variable names and braces) and arrive at a 
 functional
 lambda file, then edit to taste.

I assume this is intended to be removed at a later date?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] api: allow lambda tables to be user-specified via a text file

[Derek Buitenhuis]

On 7/3/2014 6:49 PM, Steve Borho wrote:
 Perhaps.  It's mostly harmless when unused; but I imagine someone
 doing rate control / mode decision research would find it quite handy.
 At some point it'll probably get yanked, but there's no hurry for it.

Cool.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] optimize and remove Pow() in processRowEncoder() to avoid VS2008 build error 'ambiguous...'

[Derek Buitenhuis]

On 7/3/2014 7:40 PM, Min Chen wrote:
 -double scale = pow((double)2, g_maxCUSize / 16);
 +static const uint32_t scaleTable[] = {2, 4, 16};
 +uint32_t scaleIndex = (g_convertToBit[g_maxCUSize] + 2 - 4);
 +double scale = (double)scaleTable[scaleIndex];
 +X265_CHECK(pow((double)2, (int)(g_maxCUSize  4)) == scale, 
 Failed on scale!\n);

Any reason you cant just use 1N ?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] optimize and remove Pow() in processRowEncoder() to avoid VS2008 build error 'ambiguous...'

[Derek Buitenhuis]

On 7/3/2014 8:29 PM, chen wrote:
 At 2014-07-04 03:00:31,Derek Buitenhuis derek.buitenh...@gmail.com wrote:
 On 7/3/2014 7:40 PM, Min Chen wrote:
  -double scale = pow((double)2, g_maxCUSize / 16);
  +static const uint32_t scaleTable[] = {2, 4, 16};
  +uint32_t scaleIndex = (g_convertToBit[g_maxCUSize] + 2 - 4);
  +double scale = (double)scaleTable[scaleIndex];
  +X265_CHECK(pow((double)2, (int)(g_maxCUSize  4)) == scale, 
 Failed on scale!\n);

 Any reason you cant just use 1N ?
 In here, you need (1  (1  N)), it is more operators

Uh? Do yo perhaps mean:

double scale = (double)(1  (g_maxCUSize / 16)); // Yes, every compiler 
can figure out that /16 is 4. Seriously.

So, two operations one var access.

Yous has one operation, two table accesses, one var access.
My money is that it is *possibly* slower due to cache misses, but that is
just wild speculation by me.

Just my 1 cents on micro-optimzation via obfuscation.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] simplify: getLumaIntraDir()[x] - getLumaIntraDir(x)

[Derek Buitenhuis]

On 7/2/2014 11:55 PM, Min Chen wrote:
 # HG changeset patch
 # User Min Chen chenm...@163.com
 # Date 1404341698 25200
 # Node ID c239de820501daf4438a884f6bb6b30fff340789
 # Parent  e236f39a4293056fab686e0af76bb19748f4cef1
 simplify: getLumaIntraDir()[x] - getLumaIntraDir(x)

Looks reasonable if it can be accessed like this.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] TComDataCU: remove redundant functions

[Derek Buitenhuis]

On 7/3/2014 3:24 PM, as...@multicorewareinc.com wrote:
 # HG changeset patch
 # User Ashok Kumar Mishraas...@multicorewareinc.com
 # Date 1404283815 -19800
 #  Wed Jul 02 12:20:15 2014 +0530
 # Node ID b546653344ca4f81845d44b2f0b86d56dcb853d3
 # Parent  e3f9acd4ff88eee82b7554baaab512bc1fd8e840
 TComDataCU: remove redundant functions

\o/

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] improve count_nonzero by SSSE3

[Derek Buitenhuis]

On 6/27/2014 4:05 PM, chen wrote:
 I can't understand what's your means. could you tell me more?
 
 I use some SSSE3 instruction and process 16 pixels every loop.

I meant keep both sse2 and ssse3 variants. Not sure if x86inc.asm macros
help with this or not.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] improve count_nonzero by SSSE3

[Derek Buitenhuis]

On 6/27/2014 6:08 PM, chen wrote:
 I use ssse3 instruction PSHUFB to replace 3 SSE2 instructions, the x86inc 
 macro can't handle it.
 
 After patch, this function is faster ~20% and codeCoeffNxN ~7% speedup, so I 
 don't worry about old CPU's performance.

I guess SSSE3 is very prevalent nowadays -- though I am still not a fan
of throwing away variants, I guess it's reasonable in this case.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

[Derek Buitenhuis]

On 6/26/2014 6:35 AM, BugMaster wrote:
 That is separate --psy (--no-psy) option in x264 and not --psy-rd

Yeah, that was my point. :)

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] cli: add --ipratio and --pbratio

[Derek Buitenhuis]

On 6/26/2014 8:22 AM, Satoshi Nakagawa wrote:
 # HG changeset patch
 # User Satoshi Nakagawa nakagawa...@oki.com
 # Date 1403706071 -32400
 #  Wed Jun 25 23:21:11 2014 +0900
 # Node ID 3ca045895945f0afc6b4d1b1868feb00382796a3
 # Parent  09450ac6dc7d0f495582bf327488612755df1719
 cli: add --ipratio and --pbratio

OK patch-wise.

I'm not entirely sure of the value of exposing such options myself,
since usually it's a case of please don't touch these options anyway,
but it's already an API option anyway, so, OK.

Cheers,
- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

[Derek Buitenhuis]

On 6/25/2014 1:22 AM, deep...@multicorewareinc.com wrote:
 +/* In 444, chroma gets twice as much resolution, so halve quality when 
 psy-rd is enabled */
 +if (p-internalCsp == X265_CSP_I444  p-psyRd)
 +{
 +p-cbQpOffset += 6;
 +p-crQpOffset += 6;
 +}

I dont really understand what the reasoning is for this? Is it just to make it
fit with the model psy-rd is currently using?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

[Derek Buitenhuis]

On 6/25/2014 3:45 PM, Deepthi Nandakumar wrote:
 In a sense, psy-rd encapsulates all those r-d algorithms/tweaks/hacks that 
 improve visual quality but may hurt objective metrics like psnr/ssim.
 In 444, this qp hack is likely to hurt objective metrics, hence it's turned 
 on only if psychovisual improvement is desired.

OK.

Was curious, since these are not lumped in with psy-rd in x264.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] encoder: disable rdoq when psyrd is enabled

[Derek Buitenhuis]

On 6/21/2014 2:16 AM, Deepthi Nandakumar wrote:
 Yes, it is. psy-rdoq is being developed, but in the meantime our tests show 
 rdoq deteriorates quality when psy-rd is enabled.

OK.

- Derek

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] encoder: disable rdoq when psyrd is enabled

[Derek Buitenhuis]

On 6/20/2014 8:00 AM, sumala...@multicorewareinc.com wrote:
 # HG changeset patch
 # User Sumalatha Polureddysumala...@multicorewareinc.com
 # Date 1403247577 -19800
 # Node ID 3ba3a6ab5df6e140ce1c829e091dc5b2386d122d
 # Parent  57f26a8b7ecbf943ea54b656b2d868d51073a4db
 encoder: disable rdoq when psyrd is enabled

Wouldn't the proper fix be to have RDOQ take psy into account?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Encoder::encode(): don't return 0 while flushing.

[Derek Buitenhuis]

On 6/17/2014 8:03 AM, Satoshi Nakagawa wrote:
 using ffmpeg, when input sequence is shorter than lookahead, empty stream is
 encoded.

Should be fixed on my (FFmpeg's) end, using something akin to what
libx264 does:

https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=5d1e203a7fed11fd8160e31eec04a2e152117a5e;hb=HEAD#l265

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Problem with linking x265 and ffmpeg

[Derek Buitenhuis]

On 4/22/2014 4:49 PM, 宮村 公男 wrote:
 $ ./configure --prefix=${TARGET} --as=yasm --enable-gpl --enable-libx265 
 --pkg-config-flags=—static
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
 --with-gxx-include-dir=/usr/include/c++/4.2.1
 Package —static was not found in the pkg-config search path.
 Perhaps you should add the directory containing `—static.pc'
 to the PKG_CONFIG_PATH environment variable
 No package '—static' found
 Package —static was not found in the pkg-config search path.
 Perhaps you should add the directory containing `—static.pc'
 to the PKG_CONFIG_PATH environment variable
 No package '—static' found
 ERROR: x265 not found

Uh wtf?

Why the heck are you passing a '—', (em-dash) instead of two '-' (en-dash). That
is seriously wrong. This is user error on your end.

 Have you read his comment carefully?
 He say -lstdc++” compiler flag should be passed to ffmpeg via pkg-config 
 (x265.pc) when ffmpeg asks for the -cflags of x265.  But current x265 does 
 not provide it.

Incorrect on two levels for you.

1. Your compiler is using libc++, not libstdc++. This is the C++ runtime that
   it uses. Using libstdc++ is *incorrect*.
2. pkg-config should only report -lc++ or -lstdc++ with --cflags when --static
   is given. This is correct behavior. The runtime only needs to be given 
explicitly
   when statically linking, and if you are statically linking, pkg-config needs 
the
   --static argument. End of story.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Problem with linking x265 and ffmpeg

[Derek Buitenhuis]

On 4/22/2014 6:13 PM, 宮村 公男 wrote:
 I have 2 question.
 1.Why x265.pc have line which is not need?  Or in other word, why there is a 
 line which may cause an error?

I think this is a bug in x265. It shouldn't be prefixing an absolute path with 
'-l'.

 2.Even though other third party libraries does not require to be add 
 --pkg-config-flags=—static” option, why x265 only need to be added?

Most other software either is not C++, and thus does not
need the C++ runtime, or work around it by adding the C++
runtime explicitly to the returned CFLAGS, even though it
is technically wrong to do so.

I suppose it is a judgement call Steve has made?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL

[Derek Buitenhuis]

On 3/27/2014 1:08 PM, Tim Walker wrote:
 FWIW, the Libav/FFmpeg wrapper already checks for return values  0 (x265.h 
 claims x265_encoder_headers returns negative on error, even before your 
 patch).

It will continue to work even with the change, indeed.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL

[Derek Buitenhuis]

On 3/27/2014 3:42 PM, Tim Walker wrote:
 It's actually broken right now because the function returns 0 on error, 
 contrary to what the documentation says.

Oh... FFFS. That'll teach me to trust documentation.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] primitives: added C primitives for upShift/downShift input pixels

[Derek Buitenhuis]

On 3/12/2014 8:45 AM, Steve Borho wrote:
  -for (int c = 0; c  width; c++)
  +y += lumaWidth;
  +Y += lumaWidth;
  +v += chromaWidth;
  +V += chromaWidth;
  +u += chromaWidth;
  +U += chromaWidth;
 
 blech. the destination buffer has loads of padding (stride is much
 wider than width), writing past the right edge is perfectly safe but
 you do need to be careful about reading beyond the input stride.

I'd just like to note that using one letter variables that differ only by case
is *insane*, and renders the code unreadable.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] param: add more validation checks

[Derek Buitenhuis]

On 2/26/2014 11:01 AM, sa...@multicorewareinc.com wrote:
 +#define atoi(str) x265_atoi(str, bError)

WTF? Why? This seems like a bad idea on many levels...

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] param: add more validation checks

[Derek Buitenhuis]

On 2/26/2014 7:07 PM, Tim Walker wrote:
 x264 devs seem to think it's fine:

x264 devs also think it's fine to violate the C99 spec.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] refine MC

[Derek Buitenhuis]

On 2/24/2014 9:58 AM, Satoshi Nakagawa wrote:
 # HG changeset patch
 # User Satoshi Nakagawa nakagawa...@oki.com
 # Date 1393235720 -32400
 #  Mon Feb 24 18:55:20 2014 +0900
 # Node ID 8b5df2e11af069ceae450f20b7a637e40be9b5db
 # Parent  80caa9f00d7c24da67d6b24e7bf339fe74752ced
 refine MC

An actual description of the change would be nice.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Who washed my video? x264 vs x265 'placebo' comparison

[Derek Buitenhuis]

On 2/23/2014 10:22 PM, Tom Vaughan wrote:
 Does the MKV contain video that was ripped straight from the Blu-ray Disc?
 The video in the MKV is only 14 Mbps... I would have expected a higher bit
 rate (and more detail) if this was not re-encoded.  It would be best to
 start with the highest quality source possible.

This is a red herring argument. The vast, *vast* majority of actual use cases
will be recompressing existing content. Also, 14 mbps is hardly low. I would
almost argue it's not interesting to compress from ridiculously high quality or
lossless sources, except to test pure improvement changes (i.e. devs).

 Notice that prova.h264 is twice the size (12 MB) of prova.h265 (6 MB).  This
 explains some of the difference in quality.  It's hard to hit a bit rate
 target with such a short clip.  You may need to use CRF, experimenting with
 different values until you get close.  I think that your test method is
 valid, and the results are very interesting, but you have to make sure that
 you end up with identical bit rates.

Answered by Niccolò elsewhere.

 To be fair, we want to compare encoded frames to the original incoming
 frames.  We don't want to consider more compression artifacts to be more
 detail.

So you completely discount the notion of psychovisual optimization... ?

 There are definitely some areas where your x264 encode preserved
 more detail, such as in the waves on the water, or the green areas in the
 landscape.  I noticed that even at half the bit rate, the x265 encode
 provides much more accurate edge definition of objects in motion and far
 lower noise than the x264 encode.  Notice how you can see the individual
 feathers in the close-up shots of the birds flying.

As noted in Niccolò's email, it's not half the bitrate.

I must say, as a viewer, similar complexity  blur, always. You see this sort
of thing almost all the time in PSNR-optimized ratecontrol, and it's sad.

[...]

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] rc: bug fix for encoder crash

[Derek Buitenhuis]

On 2/24/2014 12:56 PM, aar...@multicorewareinc.com wrote:
 # HG changeset patch
 # User Aarthi Thirumalai
 # Date 1393244587 -19800
 #  Mon Feb 24 17:53:07 2014 +0530
 # Node ID 3abef12d5b47106005c813bfd60ea49c31048f12
 # Parent  dce74082c20eea1f7ef9eb10f9a9addc5e7c7bb7
 rc: bug fix for encoder crash

Please state *what* was fixed. It's not obvious from the commit.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] reduce set*SubParts()

[Derek Buitenhuis]

On 2/23/2014 5:42 AM, Satoshi Nakagawa wrote:
 # HG changeset patch
 # User Satoshi Nakagawa nakagawa...@oki.com
 # Date 1393133917 -32400
 #  Sun Feb 23 14:38:37 2014 +0900
 # Node ID 2f62117d39440c1d7d0360205fbdf14d6c892d9d
 # Parent  734f106295df911edb41b5c54e795decdcdb4f04
 reduce set*SubParts()

What?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Added command line options to generate a VUI and add it to the coded bitstream

[Derek Buitenhuis]

On 2/19/2014 6:01 PM, dtyx...@gmail.com wrote:
 +bool getTilesFixedStructureFlag() { return m_tilesFixedStructureFlag; }
 +
 +void setTilesFixedStructureFlag(bool i) { m_tilesFixedStructureFlag = i; 
 }

I know this patch is pushed, but I feel it's a good time to say:

This is stupid. This isn't early 2000s Java.

Just make them public members -- this is needless java-style boilerplate cruft.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Poor Development Practices

[Derek Buitenhuis]

So.

https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389

This introduced an API change with NO version bump.

People complained stuff no longer builds.

https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0

Fixed it in the worst possible way.

It is not OK to re-purpose things like this, silently. It means code will keep
compiling, but do the wrong thing.

So please, bump the X265_BUILD number next time and no silently change
behavior in the background, which was previously correct. It's not
amateur hour.

Thanks,
- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Poor Development Practices

[Derek Buitenhuis]

On 2/18/2014 6:00 PM, Steve Borho wrote:
 I disagree; any program that used the old API can use the new one without any 
 change because before that commit internal and input bit depth were always 
 the same.  Both before and after that commit that particular field has only 
 served to validate that the user was aware of whether the library was 
 compiled for 16bpp or not.

If it really is this, then the API was documented wrong, and it does
some weird things.

e.g. x265_picture_init() copies it over into the x265_picture.bitDepth field,
which sure does look like *input* depth...

 Let's keep this polite.  I'll err on the side of bumping the build number in 
 the future.

I may be somewhat grumpy due to coming back with my inbox full of people
blaming me.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Poor Development Practices

[Derek Buitenhuis]

On 2/18/2014 6:36 PM, Steve Borho wrote:
 So when I bump X265_BUILD, ffmpeg will no longer try to compile against x265 
 until it is patched?  How does this work in practice?  Should I be sending 
 patches for ffmpeg/libav when we change API?

I can currently lock it into a version range. Right now it just checks
for X265_BUILD = 5.

The way so far with libx264 has been to bump the minimum required build.

I hope the x265 API is not too volatile -- I don't think people over at Libav
and FFmpeg will like me submitting weekly patches for API breakage.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Default GOP range: 25-250 frames or 1-10 seconds?

[Derek Buitenhuis]

On 2/13/2014 1:40 PM, Mario *LigH* Rohkrämer wrote:
 Will you prefer a fixed number of frames as defaults for the min/max GOP  
 length, or rather calculate the number from the framerate (rounded up,  
 probably)?

IMHO, the better idea is to calculate based on timestamps (not framerate,
per se, allowing for future VFR ratecontrol.)

This is was x264 does, AFAIK.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Default GOP range: 25-250 frames or 1-10 seconds?

[Derek Buitenhuis]

On 2/13/2014 8:11 PM, Steve Borho wrote:
 I'm missing some detail.  Our default keyint min and max currently match 
 x264's (24/250), as far as I know, and scenecut detection actually places I 
 frames, independent of pts (also AFAIK).

In x264, min is generated from the framerate:

http://mewiki.project357.com/wiki/X264_Settings#min-keyint

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] SONAME and shared lib install

[Derek Buitenhuis]

On 2/12/2014 5:30 AM, i...@sina.com wrote:
 *Can you add parameters option like --x264opts into your patch, for that we 
 can pass the x265's parameters from the cmd line, thanks!*

Indeed if you look at the patch, I have done this.

ffmpeg -i input.avi -c:v libx265 -x265-params crf=18:me=4 -preset placebo 
output.hevc

Will work just fine.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] SONAME and shared lib install

[Derek Buitenhuis]

On 2/11/2014 1:05 PM, Derek Buitenhuis wrote:
 1) Shared library is never install.
 2) No pkg-config file is generated or installed, despite
x265.pc.in existing.
 3) No SONAME on the shared library.

Via Anton:

4) No timestamps / way to get frame output order in the API.

- Derek

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] SONAME and shared lib install

[Derek Buitenhuis]

On 2/11/2014 5:05 PM, Steve Borho wrote:
 re: the timestamps, the dts and pts are both in the output x265_picture 
 returned by x265_encoder_encode() 

Nope. I missed that.

Thanks!

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] SONAME and shared lib install

[Derek Buitenhuis]

On 2/11/2014 5:16 PM, Steve Borho wrote:
 Am I missing something?

Isn't working on Debian for me.

One sec, I'll poke you on IRC.

- Derek

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Libav/FFmpeg Wrapper

[Derek Buitenhuis]

On 2/10/2014 6:47 PM, Tom Vaughan wrote:
 Hi Derek,
 We have looked at this, and we have done some work for internal test
 frameworks.  We will reach out to directly to coordinate and to support
 you.

There's no reason this has to be private. In fact, it shouldn't be. It's
writing an open source wrapper for an open source library.

Also, can you please tone down the corporate speak. This is an engineering
list.

 As I mentioned on the dev mailing list, our team has taken a look at x265
 FFMPEG integration.  We are having an internal conversation about how best
 to proceed.  We definitely would like to see this get done, and we
 appreciate your offer to do the work.

It's a very minimal amount of work to add a wrapper on my part, for something
likely useful; no thanks needed.

 Steve and I will try to get a more definitive answer on how we can work
 together to get this done ASAP.  Some of the MCW developers involved are
 in China, and they are just getting back from the Chinese New Year
 holiday, and so it may take a day or two to figure out who is doing what,
 what has already been done, etc.

... What? There already exists code to add it to Libav, and it would be maybe
40 minutes of work for me to finish it. This is a tiny effort, and does not
require more than one person. Since it seems nothing has been done internally,
I will write and submit it tomorrow (I am in GMT, so it is night here right 
now).
I'm not going to waste my time doing corporate style convoluted
too-many-people-for-one-task coordination... There's no who does what, just
who writes it.

Patches will show up tomorrow on ffmpeg-devel and libav-devel for review.

Cheers,
- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] Libav/FFmpeg Wrapper

[Derek Buitenhuis]

I will be adding such a wrapper this week to both projects.

But before I do, I would like to know if anyone inside MCW is
already working on such a patch, to avoid duplicated effort.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] New entropy coding - faster than Huffman, compression rate like arithmetic

[Derek Buitenhuis]

On 12/30/2013 12:50 AM, Jarosław Duda wrote:
 I would like to propose a discussion about the possibility of applying it in 
 video compression, maybe adding to h.265 - it should be about 10 times faster 
 than CABAC, providing similar compression rate.

This bit seems like it would perhaps be better suited to an ITU or IETF list,
where standard are developed.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH 0 of 2] Fix Linux Build

[Derek Buitenhuis]

See topic.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH 1 of 2] TEncSearch: Fix parameter type of xEstimateResidualQT

[Derek Buitenhuis]

# HG changeset patch
# User Derek Buitenhuis derek.buitenh...@gmail.com
# Date 1384350763 0
# Node ID 1c8e8f6f66657bd09807707728b42689d571f881
# Parent  c4ca80d19105ccf1ba2ec14dd65915f2820a660d
TEncSearch: Fix parameter type of xEstimateResidualQT

Fixes compilation with g++.

diff -r c4ca80d19105 -r 1c8e8f6f6665 source/Lib/TLibEncoder/TEncSearch.cpp
--- a/source/Lib/TLibEncoder/TEncSearch.cpp Tue Nov 12 19:10:23 2013 +0530
+++ b/source/Lib/TLibEncoder/TEncSearch.cpp Wed Nov 13 13:52:43 2013 +
@@ -2809,7 +2809,7 @@
 
 //  Residual coding.
 int qp, qpBest = 0;
-UInt64  cost, bcost = MAX_INT64;
+uint64_t cost, bcost = MAX_INT64;
 
 uint32_t trLevel = 0;
 if ((cu-getWidth(0)  cu-getSlice()-getSPS()-getMaxTrSize()))
@@ -3042,7 +3042,7 @@
  uint32_t   absTUPartIdx,
  TShortYUV* resiYuv,
  const uint32_t depth,
- UInt64rdCost,
+ uint64_trdCost,
  uint32_t  outBits,
  uint32_t  outDist,
  uint32_t * outZeroDist,
@@ -3634,7 +3634,7 @@
 }
 uint32_t subdivDist = 0;
 uint32_t subdivBits = 0;
-UInt64 subDivCost = 0;
+uint64_t subDivCost = 0;
 
 const uint32_t qPartNumSubdiv = cu-getPic()-getNumPartInCU()  
((depth + 1)  1);
 for (uint32_t i = 0; i  4; ++i)
diff -r c4ca80d19105 -r 1c8e8f6f6665 source/Lib/TLibEncoder/TEncSearch.h
--- a/source/Lib/TLibEncoder/TEncSearch.h   Tue Nov 12 19:10:23 2013 +0530
+++ b/source/Lib/TLibEncoder/TEncSearch.h   Wed Nov 13 13:52:43 2013 +
@@ -250,7 +250,7 @@
 
 void xEncodeResidualQT(TComDataCU* cu, uint32_t absPartIdx, uint32_t 
depth, bool bSubdivAndCbf, TextType ttype);
 void xEstimateResidualQT(TComDataCU* cu, uint32_t absPartIdx, uint32_t 
absTUPartIdx, TShortYUV* resiYuv, uint32_t depth,
- UInt64 rdCost, uint32_t outBits, uint32_t 
outDist, uint32_t *puiZeroDist, bool curUseRDOQ = true);
+ uint64_t rdCost, uint32_t outBits, uint32_t 
outDist, uint32_t *puiZeroDist, bool curUseRDOQ = true);
 void xSetResidualQTData(TComDataCU* cu, uint32_t absPartIdx, uint32_t 
absTUPartIdx, TShortYUV* resiYuv, uint32_t depth, bool bSpatial);
 
 void setWpScalingDistParam(TComDataCU* cu, int refIdx, int picList);
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH 2 of 2] Reindent after last commit

[Derek Buitenhuis]

# HG changeset patch
# User Derek Buitenhuis derek.buitenh...@gmail.com
# Date 1384350793 0
# Node ID 28475a460f963f3481f2a68626093fdd6c98ade3
# Parent  1c8e8f6f66657bd09807707728b42689d571f881
Reindent after last commit

diff -r 1c8e8f6f6665 -r 28475a460f96 source/Lib/TLibEncoder/TEncSearch.cpp
--- a/source/Lib/TLibEncoder/TEncSearch.cpp Wed Nov 13 13:52:43 2013 +
+++ b/source/Lib/TLibEncoder/TEncSearch.cpp Wed Nov 13 13:53:13 2013 +
@@ -2808,7 +2808,7 @@
 }
 
 //  Residual coding.
-int qp, qpBest = 0;
+int  qp, qpBest = 0;
 uint64_t cost, bcost = MAX_INT64;
 
 uint32_t trLevel = 0;
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] TEncSearch: Fix parameter type of xEstimateResidualQT

[Derek Buitenhuis]

On 11/13/2013 1:55 PM, Derek Buitenhuis wrote:
 - UInt64rdCost,
 + uint64_trdCost,

If you apply it, fix this indentation too.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] recon : reconstructed image write frame position calculation logic modified

[Derek Buitenhuis]

On 10/23/2013 12:26 PM, Gopu Govindaswamy wrote:
 -ofs.seekp(pic.poc * 3 * (width * height * pixelbytes) / 2);
 -
 +uint64_t size = (pic.poc * 3);
 +size *= (width * height * pixelbytes);
 +size /= 2;
 +ofs.seekp(size);

Why?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] recon : reconstructed image write frame position calculation logic modified

[Derek Buitenhuis]

On 10/23/2013 12:33 PM, Gopu Govindaswamy wrote:
 (pic.poc * 3 * (width * height * pixelbytes) / 2) this statement is giving us 
 wrong result if width and height is big 

So cast it properly instead of making a new stack variable?

Or at the very least, explain that you are doing this to obtain 64-bit
precision.

A commit message saying X is modified with no reason as to *why* is
completely useless.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] cmake: generate and install pkgconfig file

[Derek Buitenhuis]

On 10/22/2013 11:59 PM, Rafaël Carré wrote:
 For static linking to work, this also needs:
 
 Libs.private: -lstdc++ -lm -lpthread

That only makes sense on GNU systems.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] cmake: add uninstall rule for non-Windows platforms

[Derek Buitenhuis]

On 10/12/2013 10:52 PM, Steve Borho wrote:
 # HG changeset patch
 # User Steve Borho st...@borho.org
 # Date 1381613400 18000
 #  Sat Oct 12 16:30:00 2013 -0500
 # Node ID c18a09b9d2d3c7b249701afedd4e09cf2933312d
 # Parent  ec98f30c518556476e1ba2acd6c79e38f3b2b137
 cmake: add uninstall rule for non-Windows platforms
 
 CMake on Windows doesn't appear to generate an install manifest file

As I stare into the ever increasing black hole of custom written crap to
provide basic functionality that cmake lacks...

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH RFC] cpu-a: remove unused safe_intel_cpu_indicator_init routine

[Derek Buitenhuis]

On 10/4/2013 12:22 AM, Derek Buitenhuis wrote:
 Queued to test tomorrow morn.

Findings:
t
Lib links via:

/usr/bin/c++  -fPIC  -fPIC -O3 -DNDEBUG  -shared -Wl,-soname,libx265.so -o 
libx265.so CMakeFiles/x265.dir/dllmain.cpp.o common/libcommon.a 
encoder/libencoder.a common/vec/libPrimitivesVec.a 
common/x86/libPrimitivesASM.a -lpthread -lm -lrt

x265 links via:

/usr/bin/c++-fPIC -O3 -DNDEBUG  -fPIC CMakeFiles/cli.dir/input/input.cpp.o 
CMakeFiles/cli.dir/input/y4m.cpp.o CMakeFiles/cli.dir/input/yuv.cpp.o 
CMakeFiles/cli.dir/output/output.cpp.o CMakeFiles/cli.dir/output/y4m.cpp.o 
CMakeFiles/cli.dir/output/yuv.cpp.o CMakeFiles/cli.dir/x265.cpp.o 
CMakeFiles/cli.dir/compat/msvc/getopt.c.o  -o x265 -rdynamic libx265.so 
-lpthread -lm -lrt common/libcommon.a encoder/libencoder.a 
common/vec/libPrimitivesVec.a common/x86/libPrimitivesASM.a 
-Wl,-rpath,/mnt/tc/dev/b

Obviously wrong, since it includes the .a files.

Also libx265.so doesn't link to third party libs properly.

I tested with my patch to Libav and got:

check_func x265_encoder_encode -lx265 -lstdc++
check_ld -lx265 -lstdc++
check_cc
BEGIN /tmp/ffconf.TrwduATY.c
1   extern int x265_encoder_encode();
2   int main(void){ x265_encoder_encode(); }
END /tmp/ffconf.TrwduATY.c
clang -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -std=c99 -fomit-frame-pointer 
-pthread -c -o /tmp/ffconf.eeq38c5j.o /tmp/ffconf.TrwduATY.c
clang -Wl,--as-needed -o /tmp/ffconf.nF7C6wIq /tmp/ffconf.eeq38c5j.o -lx265 
-lstdc++ -lm -pthread -lbz2 -lz
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSampleAdaptiveOffset::m_numClass'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::setLumaIntraDirSubParts(unsigned int, unsigned int, unsigned 
int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSlice::getWpAcDcParam(x265::wpACDCParam*)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::setTransformSkipSubParts(unsigned int, x265::TextType, 
unsigned int, unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::getCoefScanIdx(unsigned int, unsigned int, bool, bool)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComYuv::copyToPicYuv(x265::TComPicYuv*, unsigned int, unsigned int, 
unsigned int, unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComTrQuant::invtransformNxN(bool, unsigned int, short*, unsigned int, 
int*, unsigned int, unsigned int, int, bool, int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::ThreadPool::getThreadPool()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TShortYUV::copyPartToPartChroma(x265::TComYuv*, unsigned int, unsigned 
int, unsigned int, unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComPicYuv::clearReferences()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::setDepthSubParts(unsigned int, unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::getQuadtreeTULog2MinSizeInCU(unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSampleAdaptiveOffset::processSaoUnitAll(x265::_SaoLcuParam*, bool, 
int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComTrQuant::setQPforQuant(int, x265::TextType, int, int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComScalingList::TComScalingList()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSlice::getRapPicFlag()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComPrediction::predIntraLumaAng(unsigned int, unsigned char*, unsigned 
int, int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSlice::setRefPOCList()'
/usr/local/lib/libx265.so: undefined reference to `x265::TShortYUV::clear()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComPattern::initAdiPatternChroma(x265::TComDataCU*, unsigned int, 
unsigned int, unsigned char*, int, int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::PCMLFDisableProcess(x265::TComPic*)'
/usr/local/lib/libx265.so: undefined reference to `x265::TComSPS::~TComSPS()'
/usr/local/lib/libx265.so: undefined reference to `x265::JobProvider::flush()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComSPS::setHrdParameters(unsigned int, unsigned int, unsigned int, 
bool)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::copyToPic(unsigned char, unsigned int, unsigned int)'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::setPartSizeSubParts(x265::PartSize, unsigned int, unsigned 
int)'
/usr/local/lib/libx265.so: undefined reference to `x265::Thread::start()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComTrQuant::~TComTrQuant()'
/usr/local/lib/libx265.so: undefined reference to `x265::TComPic::TComPic()'
/usr/local/lib/libx265.so: undefined reference to 
`x265::TComDataCU::create(unsigned int, unsigned int

Re: [x265] [PATCH] common: tighten up tool descriptions; save horizontal space

[Derek Buitenhuis]

On 10/1/2013 11:30 PM, Steve Borho wrote:
 # HG changeset patch
 # User Steve Borho st...@borho.org
 # Date 1380666567 18000
 #  Tue Oct 01 17:29:27 2013 -0500
 # Node ID 3a4f4005d583b18215b911eb34dd5c4cd255eae4
 # Parent  73f1415009ea83511469f34a9ddbf999e1c64757
 common: tighten up tool descriptions; save horizontal space

OK.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Replace sad_12, sad_24, sad_32 vector class functions with intrinsics

[Derek Buitenhuis]

On Tue, Oct 1, 2013 at 2:08 PM,  dnyanesh...@multicorewareinc.com wrote:
 # HG changeset patch
 # User Dnyaneshwar
 # Date 1380631342 -19800
 #  Tue Oct 01 18:12:22 2013 +0530
 # Node ID ecc483a16f1d9e0163182d090c18fad3f1616ab5
 # Parent  a03659cfa9574a2639292e427b2cb3d080c648ad
 Replace sad_12, sad_24, sad_32 vector class functions with intrinsics.

 Performance improvement measured is close to 1.5x

What happened to the no new intrinsics promise?

Use proper asm and x86inc macros.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Accessunit: Remove unused accessUnit class

[Derek Buitenhuis]

On 9/25/2013 6:58 AM, Gopu Govindaswamy wrote:
 # HG changeset patch
 # User Gopu Govindaswamy g...@multicorewareinc.com
 # Date 1380088686 -19800
 # Node ID bb88bbe34c95b3f398a6af63c05e06a3fe7bc7d3
 # Parent  bdd26fd0325acf0f36409e994bdc262b11fa70f4
 Accessunit: Remove unused accessUnit class
 
 AccessUnit class derived from std template list, Accessunit class replaced 
 with pointers to an array

English fix:

AccessUnit: Remove unused AccessUnit class

The AccessUnit class was derived from std::list, whose usage was replaced
with pointers to an array.

Rest OK.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] fix hash mistake in --sao-lcu-opt=0 mode

[Derek Buitenhuis]

On 9/25/2013 7:30 AM, Min Chen wrote:
 # HG changeset patch
 # User Min Chen chenm...@163.com
 # Date 1380090001 -28800
 # Node ID 2d1646a4fc2a7aee4fba79c5c587ca396c50cbe0
 # Parent  57efca19f5b8d8b5bdc22a0bb9fbfc6169724266
 fix hash mistake in --sao-lcu-opt=0 mode

Add how to the commit message.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1/5][RFC] Only use UNIX line endings

[Derek Buitenhuis]

On 9/24/2013 2:15 AM, Steve Borho wrote:
 I've pushed commits which affect these changes and go a bit further in a few 
 cases

... Any particular reason my commits weren't used? I even sent a PR as
you requested.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH 1/5][RFC] Only use UNIX line endings

[Derek Buitenhuis]

Be consistent. Only use CRLF lien endings in .bat files.

Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
 build/README.txt  |   136 +-
 build/regression/commandlines-example.txt |30 +-
 build/regression/config-example.txt   |16 +-
 build/regression/email-csv.py |98 +-
 doc/astyle/apply-to-all-source.py |42 +-
 doc/astyle/astyle-config.txt  |24 +-
 doc/uncrustify/apply-to-all-source.py |48 +-
 doc/uncrustify/codingstyle.cfg|   464 +-
 source/Lib/README.txt | 6 +-
 source/VectorClass/README.txt | 2 +-
 source/VectorClass/vectorclass.h  |90 +-
 source/VectorClass/vectori128.h   | 11140 ++--
 source/VectorClass/vectori256.h   |  9464 +++
 source/VectorClass/vectori256e.h  |  7086 +-
 source/common/x86/README.txt  |28 +-
 15 files changed, 14337 insertions(+), 14337 deletions(-)

[... snip ...]
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] types: use stdint.h data types for UChar, UShort, UInt64, Pel, TCoeff

[Derek Buitenhuis]

On 9/19/2013 5:18 AM, Steve Borho wrote:
 +typedef uint8_t  UChar;
 +typedef uint16_t UShort;
 +typedef unsigned int UInt;
 +typedef int64_t  Int64;
 +typedef uint64_t UInt64;

This seems quite wrong, since they're not necessarily analogous on
all platforms... like short.

Why not replace them properly?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH 1 of 2] Always active sao-lcu-opt because we broken it after Frame Parallelism

[Derek Buitenhuis]

On 9/19/2013 10:16 AM, Min Chen wrote:
 +// Disabled because Frame Parallelism call processRowPost early, it is 
 broken data.
 +// OPT(sao-lcu-opt, param-saoLcuBasedOptimization,required_argument, 
 0, 0: SAO picture-based optimization, 1: SAO LCU-based optimization )

... Why not fix it instead of commenting stuff out?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Resolve some patching issues for previous patch (deadlock)

[Derek Buitenhuis]

On 9/17/2013 2:11 PM, Min Chen wrote:
 # HG changeset patch
 # User Min Chen chenm...@163.com
 # Date 1379423463 -28800
 # Node ID c5c645aa14bfdbf482186730c59a000fdae10e07
 # Parent  0d33ff236f68bc2238138a7213301b2efc0e6426
 Resolve some patching issues for previous patch (deadlock).

Can you add a short description of how it is fixed to
the commit message?

Much of the patch is confusing without context.

  uint64_t oldval = m_queuedBitmap[w];
 -if (oldval == 0) // race condition
 +uint64_t mask = m_queuedBitmap[w]  m_enableBitmap[w];
 +if (mask == 0) // race condition
  break;

if (!(oldval  m_enableBitmap[w]))
break;

No need for a new stack var. Just a matter of preference; feel
free to ignore.

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH]RDLevel: Disable RDOQTS when RDO and/or TS are disabled.

[Derek Buitenhuis]

On Mon, Sep 16, 2013 at 7:11 AM, Deepthi Nandakumar
deep...@multicorewareinc.com wrote:
 # HG changeset patch
 # User Deepthi Nandakumar deep...@multicorewareinc.com
 # Date 1379311811 -19800
 # Node ID c1ec5b8a6752529368753c110d626f1c53d90f3e
 # Parent  22c4e67c7246cd77968a86e967377e4a18b47b31
 RDLevel: Disable RDOQTS when RDO and/or TS are disabled.

[...]

 +else
 +{
 +_param-bEnableRDOQTS = 0;
 +}

Is the param structure not zero-allocated with something like calloc
or malloc+memset?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH]RDLevel: Disable RDOQTS when RDO and/or TS are disabled.

[Derek Buitenhuis]

On Mon, Sep 16, 2013 at 10:47 AM, Deepthi Nandakumar
deep...@multicorewareinc.com wrote:

 Yes, this particular param flag is initialised to 1 (highest quality
 setting) in x265_param_default. I'm setting it to zero for a certain set of
 user defined parameters.

What's the point of the first check
(http://mailman.videolan.org/pipermail/x265-devel/2013-September/000783.html)
which sets it to 1 then?

- Derek
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel