Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th November 2017, 07:51   #5701  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 39
Quote:
Originally Posted by MonoS View Post
Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?
The MPEG study group that recommended the changes x265 has implemented under the --hdr-opt option focused their study only on consumer grade video (HDR10 4:2:0). That is why it is recommended to use with 4:2:0 for now.

If there are other such recommendations for other color spaces, please do share it here.
pradeeprama is offline   Reply With Quote
Old 15th November 2017, 14:57   #5702  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,891
x265 2.5+55-dd9772385d15

Add CLI option to enable or disable picture copy to internal frame buffer

Code:
   --[no-]copy-pic               Copy buffers of input picture in frame. Default enabled
Quote:
Allow encoder to copy input x265 pictures to internal frame buffers. When disabled, x265 will not make an internal copy of the input picture and will work with the application's buffers. While this allows for deeper integration, it is the responsbility of the application to (a) ensure that the allocated picture has extra space for padding that will be done by the library, and (b) the buffers aren't recycled until the library has completed encoding this frame (which can be figured out by tracking NALs output by x265)
I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Old 15th November 2017, 17:17   #5703  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 39
Quote:
Originally Posted by LigH View Post
x265 2.5+55-dd9772385d15

Add CLI option to enable or disable picture copy to internal frame buffer

Code:
   --[no-]copy-pic               Copy buffers of input picture in frame. Default enabled


I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.
I understand the confusion this might cause. Let me try to clarify.

If you invoke the x265 application, you won't be able to access the invoking application's memory buffers as you are in separate processes and therefore this option isn't useful. This option is applicable only when you do an integration of the x265 library with another application. In that case, the option is useful because we advocate that you use the x265_param_parse() API call to populate the right fields of the param structure instead of directly writing the struct yourself; doing it through the API ensures that all checks are done by the library. For every param, the string that you pass to populate the param is the cli-option string and therefore, exposing this as a CLI option enables folks who do deep integration to use this option in a clean fashion
pradeeprama is offline   Reply With Quote
Old 15th November 2017, 17:40   #5704  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,279
Exposing an option to the CLI which con't be used through the CLI seems strange,.. (or did I misunderstand the above?)
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 15th November 2017, 20:05   #5705  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,891
As far as I hope to understand, it may not be helpful to the pure x265 CLI encoder, but possibly to other applications derived from this structure, configuring itself internally with a CLI parameter string as well.
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Old 15th November 2017, 20:07   #5706  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,279
So cli parameter that's not for the CLI,... <- this still seems like it shouldn't be exposed through the cli,..
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 15th November 2017, 20:36   #5707  |  Link
x265_Project
Registered User
 
x265_Project's Avatar
 
Join Date: Jul 2013
Posts: 580
Quote:
Originally Posted by Selur View Post
So cli parameter that's not for the CLI,... <- this still seems like it shouldn't be exposed through the cli,..
I asked Pradeep the same question today. As the GM and the primary product manager, I agree that we don't want to confuse people who use our command line interface (CLI) to run x265 by exposing options that are invalid when run from the CLI. I understand that the x265_param_parse() function is a part of the CLI, and that it is useful to validate and organize/prioritize parameters when you run x265 via the API, but this looks like something that we could restructure to eliminate confusion for CLI users. It could be as simple as labeling some options as API only, such that if you attempt to run them from the CLI you'll get an error, or we'll recognize them but they will just be ignored with a warning.

Our documentation has a lot to do with x265's usability. You'll notice that most of x265's parameters are documented as CLI options. There are a few things, for example reconfiguring x265 on the fly, that are only possible through the API. Some things are documented in our online docs (http://x265.readthedocs.io/en/default/api.html), and other things are found in header files. As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!
__________________
x265 HEVC (H.265) Video Encoder ____________ Follow x265 on Facebook.
x265_Project is offline   Reply With Quote
Old 15th November 2017, 21:26   #5708  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 153
Quote:
Originally Posted by pradeeprama View Post
The MPEG study group that recommended the changes x265 has implemented under the --hdr-opt option focused their study only on consumer grade video (HDR10 4:2:0). That is why it is recommended to use with 4:2:0 for now.

If there are other such recommendations for other color spaces, please do share it here.
Not that i know, i just want to encode a 1080p 4:4:4 HDR stream
MonoS is offline   Reply With Quote
Old 15th November 2017, 23:55   #5709  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,401
Quote:
Originally Posted by x265_Project View Post
..............
As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!
How about finally correcting/updating this piece of (mis)information?

Code:
--bframes <integer>    Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4
Midzuki is offline   Reply With Quote
Old 17th November 2017, 13:15   #5710  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 228
x265 v2.5+58-06979c042350 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 17th November 2017, 20:15   #5711  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,401
Quote:
Originally Posted by Midzuki View Post
Quote:
Originally Posted by x265_Project View Post
..............
As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!
How about finally correcting/updating this piece of (mis)information?

Code:
--bframes <integer>    Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4
Apparently I will have to return to the x265 mailing list.
Or pester Steve Borho.
Probably both things...
Midzuki is offline   Reply With Quote
Old 18th November 2017, 15:30   #5712  |  Link
x265_Project
Registered User
 
x265_Project's Avatar
 
Join Date: Jul 2013
Posts: 580
Quote:
Originally Posted by Midzuki View Post
Apparently I will have to return to the x265 mailing list.
Or pester Steve Borho.
Probably both things...
Or contribute a patch
__________________
x265 HEVC (H.265) Video Encoder ____________ Follow x265 on Facebook.
x265_Project is offline   Reply With Quote
Old 19th November 2017, 13:27   #5713  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,401
Quote:
Originally Posted by x265_Project View Post
Or contribute a patch
Yeah, something so difficult as erasing some bytes from a lazily-written help screen really requires an official patch created by someone who stopped programming decades ago

P.S.: welcome to my Ignore List (again)

Last edited by Midzuki; 19th November 2017 at 13:29. Reason: add P.S.
Midzuki is offline   Reply With Quote
Old 19th November 2017, 13:57   #5714  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,891
Ah, come on ... I am not experienced in creating correct patches either, but when I knew how to improve things, suggesting the kernel of a diff in the mailing list was usually sufficient that another developer included that in a following full patch. They may be a bit picky about the exact style when it comes to official patches, but a professional project with commercial customers requires that amount of pedantism, and amateur suggestions are still welcome.

In your case with the consecutive B frames, I would not be sure which new content would be optimal, but I would know how I would submit a "snippet of a patch" to the mailing list.
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Old 19th November 2017, 14:38   #5715  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 257
Quote:
Originally Posted by x265_Project View Post
Or contribute a patch
It's not always enough -- the patch https://patches.videolan.org/patch/15688/ is forgotten, x265cli.h has changed and now this patch doesn't apply cleanly.
Ma is offline   Reply With Quote
Old 19th November 2017, 19:10   #5716  |  Link
x265_Project
Registered User
 
x265_Project's Avatar
 
Join Date: Jul 2013
Posts: 580
I'm just trying to encourage participation. Sure, ideally we'd love patches to be in the right format, able to be applied cleanly to the latest development tip. But for our documentation, we can certainly handle an email to the developer mailing list with your suggested update to the documentation for a particular feature. Our team can figure out how to turn this into the official patch. Developing x265 is a big job... but this is open source, so we want to encourage participation.

Ma - I'm sorry if something was missed. We'll check into it.
__________________
x265 HEVC (H.265) Video Encoder ____________ Follow x265 on Facebook.
x265_Project is offline   Reply With Quote
Old 19th November 2017, 21:02   #5717  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 756
are there going to be any nice quality improvements in the near future in x265 or are you getting towards x265's limit?
hajj_3 is offline   Reply With Quote
Old Yesterday, 08:57   #5718  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,891
Not speaking for the developers, just my personal guess: I would not expect a revolution anymore, at least in the home consumer area (8-10 bit depth), rather evolution - at most finetuning. "Miracle time" is over, the HEVC specs indicate the range of algorithms which can be used (how to search for redundancies to spare and how to encode the video stream efficiently), and "revolutionary" improvements may not be supported by HEVC specs anymore (but there is e.g. AOMedia AV1). The biggest change I hope for would be integration of libav and AviSynth input modules.

But I could imagine room for more features for professional and specific "niche" usage cases. And of course, steady improvements of speed-up technologies, from more assembly to smarter algorithms in depth.
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Old Yesterday, 10:04   #5719  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 39
Quote:
Originally Posted by Ma View Post
It's not always enough -- the patch https://patches.videolan.org/patch/15688/ is forgotten, x265cli.h has changed and now this patch doesn't apply cleanly.
My bad - sorry. This patch is now pushed in and the outdated commit message has finally been updated!
pradeeprama is offline   Reply With Quote
Old Yesterday, 11:50   #5720  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 4,891
x265 2.5+65-a7c2f80c18af

Disable opt-qp-pps and opt-ref-list-length-pps by default; use AVC CU analysis data in anlysis-reuselevel 7 and 8; update an outdated help message for --bframes
__________________

German doom9 / Gleitz video board
CQME – change the Matrix!
BeSweet 1.5b31 All In One | HeadAC3he 0.24a13

Rémoulade is spoiled
LigH is online now   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.