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 14th November 2017, 01:08   #5701  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Blue_MiSfit View Post
What's the usefulness of these new VBV params when you're doing segment encoding?
Yes, I think our documentation could be a bit better for this feature. If you want the whole video (after assembling your segments) to comply to specific VBV settings, set --vbv-end to the same value as you use for --vbv-init. In other words, the fullness of the decoder's buffer at the end of segment X needs to match the initial buffer fullness for segment X+1.

For example, if we assume the buffer is 90% full when we start a new segment, we need to make sure it wasn't more than 90% full when we finished encoding the last segment.
  Reply With Quote
Old 14th November 2017, 02:18   #5702  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
I see.
Blue_MiSfit is offline   Reply With Quote
Old 14th November 2017, 06:47   #5703  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265.h: change references into pointers for C compatibility

Building ffmpeg with libx265 should work again.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th November 2017, 20:44   #5704  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?
MonoS is offline   Reply With Quote
Old 14th November 2017, 22:15   #5705  |  Link
SeeMoreDigital
Life's clearer in 4K UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,219
Quote:
Originally Posted by MonoS View Post
Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?
Currently all video encoded for use with DVD, Blu-ray, Ultra HD, internet streaming and television broadcasts is 4:2:0...
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 14th November 2017, 22:31   #5706  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Quote:
Originally Posted by SeeMoreDigital View Post
Currently all video encoded for use with DVD, Blu-ray, Ultra HD, internet streaming and television broadcasts is 4:2:0...
So not something like "quantizer for != 4:2:0 encode should be different than the one coded in the codec", just there's no content out there?
MonoS is offline   Reply With Quote
Old 15th November 2017, 07:51   #5707  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
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   #5708  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 15th November 2017, 17:17   #5709  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
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   #5710  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
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   #5711  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 15th November 2017, 20:07   #5712  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
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   #5713  |  Link
x265_Project
Guest
 
Posts: n/a
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!
  Reply With Quote
Old 15th November 2017, 21:26   #5714  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
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   #5715  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
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   #5716  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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   #5717  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
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   #5718  |  Link
x265_Project
Guest
 
Posts: n/a
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
  Reply With Quote
Old 19th November 2017, 13:27   #5719  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
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   #5720  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   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 17:19.


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