My bread profile based on CRF instead of fixed quality scale (VBR). I use it for almost all sizes up to FullHD.
matroska libx265
# CRF 16 creates a balanced compromise between quality and file size.
crf=16
# Preset changes encoding speed and generally degrades the overall
# result. Medium (default) always fits.
preset=medium
# me=star improves the search for very fast movements, but
# slows down the encoding.
#x265-params=me=star
# Keyint does ffmpeg automatically, otherwise the setting must match
# the frame rate.
#keyint_min=25
# Profile does ffmpeg automatically.
#profile=high
# Source sRBG and retention of color space. 720/1080=bt709 if no
# profile set. Useful for formats smaller than 720 if no lossy
# conversion is desired.
colorspace=bt709
color_trc=bt709
color_primaries=bt709
# Output in 10 bit, prevents 8-bit step formation (and reduces the
# file size for unknown reasons).
pixel_format=yuv420p10
--
The recommended basic settings for the upload encoding for Vimeo can be found under:
https://vimeo.com/help/compression
YT probably can't do anything with this codec and container, the recommended basic settings for the upload encoding can be found under:
https://support.google.com/youtube/answer/1722171?hl=en [de …]
Very clear and useful example. Thank you. I would like to insert it in chapter 7 of the latex manual as "7.5.4 Use case: x265". Obviously if you give me permission and Phyllis is fine with the insertion.
One question:
The lines "color space ... color primaries" are used to provide the output file with an ICC profile (BT709)? Without these lines would you have no profile?
There is nothing against using the video profile and adapting it to your own needs, freely and without naming. I opened this fred to discuss export and compression issues. Obviously there is still a need for information, especially since video compression is not easy to understand. CGG can produce very high output quality, but you need to know which switches to set.
The color space information must be used explicitly so that it can be included in the video. CGG or FFmpeg does not write it by itself. Without this information the players (e.g. MPV) stick to the dimensions of the video and take the assumed color model from a table. With videos in the dimensions from 720 to 1080 this is like written bt709. For smaller dimensions, e.g. DVD, bt601 is assumed and for 4k and above it is bt2020. Normally this is not a problem, but if you want to export a FullHD without color loss to a smaller size like 576 for example, you have to inform the encoder as well as the decoder of the player. This also applies if the videos are to be loaded on video platforms, where they are then converted into videos of different sizes. It is a security measure to prevent false colors, such as the color profiles in digital photos and the copies made from them. But please do not confuse with the internal color space of CGG, that is (X11 s)RGB without color profile.
Great, you clarified a subject that made me confused.
Another question (if you can):
Settings --> Preferences --> appearance tab
What do the "YUV Color space" and "YUV color range" drop-down menus mean and how do they work?
Shouldn't this already be in the manual? 😉
I assume (!), these settings only affect the "Format Settings", if the color model "YUV[A]-8 Bit" was selected there. The "YUV Color Range" JPEG is slightly larger than MPEG. How much exactly did I forget, there is a description in WIKIPEDIA. The field of application of YUV is, as far as I know, SDTV and tube TV. The "YUV color space" regulates possibly the internal limitation of the color space with the internal processing. As written before, CGG's Composer works exclusively in (s)RGB. However, colour differences are still visible, YUV looks washed out in comparison to RGB. Maybe Phylis can say something?
I use the digital RGB[A-Float] model without exception to exclude color loss. Of course you can also use a smaller "RGB[A]-8 bit" during editing, then it is a bit smoother because the amount of data is reduced. For the final export you must or should switch back to Float.
A supplement to CRF 16 because the manual was mentioned. A CRF of 16 delivers satisfactory results in most cases. However, if the film material is really grainy, a CRF 16 can lead to unwanted large files. In this case, a trial export of perhaps one minute should be performed. The resulting bit rate can be used to correct the CRF to 17,18,19... Remember, a CRF of 0 means lossless, the higher the number the stronger the compression. The approximate calculation of the final file size can be extrapolated from the sample export.
Thank you, Olaf. Your comments are very instructive. I enclose a .txt as an example of how I could add the new section to the manual. What do you think? Any corrections are welcome.
Perfect. I have inserted a small addition.
Edit: .tex text files are not allowed. I had to rename them accordingly.
Edit: DOS to UTF8
Edit: Typo
Edit: Translation
Andrea/Olaf:
This is the kind of additional information that enhances the usefulness of the manual. From a technical viewpoint, it is beyond me, but for purposes of reviewing for the manual, I have the following commentary.
1 - Andrea, when you say add as section 7.5.5, does that mean that the original 7.5.5 will be renumbered (I just want to make sure it is not deleted because "Piping Video..." was a big deal to a specific user)?
2 - "% The purpose of the comments in the profile is to allow users to
% description at the ready." -- Should this be "to have description at the ready." ?
3 - "% grainy, see "x265 Presets/Tunig"" -- I think "Tunig" is supposed to be "Tuning" because Tunig is German for Tuning in english. ??
4 - "video and take the assumed color model from a table. With videos in
the dimensions from 720 to 1080 this is like written bt709." -- not sure what "like written bt709" is supposed to be? Maybe "like using bt709"? or "like writing bt709"? I do not know technically.
Also, I agree with Olaf removing the credit of him for this from his changes. Originally I had only added specific credits when there was an overwhelming amount of work done or the information came directly from CV and I did not want the work of others to be unacknowledged. (P.S. I prefer to leave my name off since none of what I do is original work).
1- Sorry, Phyllis, I should've explained better. I assumed that Olaf only knew the current manual for which I used chapter 7, which in latex is 6 (because the current chapter 1 -Introduction- has not been numbered). In any case, when I insert section 6.5.5 in the manual_latex, all subsequent sections automatically scale without manual intervention. "Piping video..." will become 6.5.6 and so on. This is one of the many qualities of LaTeX.
2, 3 and 4- I've corrected the text.
- Credits: I don't agree with your name: in my opinion it should be put in the colophon, if not even in the title page. If not as an author at least as a co-author and curator.
- Olaf, a further question: Instead of CRF vs VBR, wouldn't it become CRF vs Costant QP (CQP)?
No, the A secretly turned on its head, ABR is meant. 😉
--bitrate :: Enables single-pass ABR rate control.
--crf :: Quality-controlled variable bitrate.
- https://x265.readthedocs.io/en/latest/cli.html
-qp :: do not use this mode.
Thx Phyllis & Andrea
I made the addition to the manual (pag 160-161), but since I'm not loading it into my Git branch right now. You can only see the pdf I have in Dropbox at the following address:
https://www.dropbox.com/s/0js49r47s0qu621/CinelerraGG_Manual.pdf?dl=0
(the last two chapters have not yet been revised)
@Olaf
I tried to insert also the information that CinGG works on its internal color space, that is sRGB; it seems to me an essential information. You can see it on pag 74-75 of the pdf ("Color model"). But the color management of CinGG is not clear to me at all, so I ask you for a favor, if you want, to review it.
Good Guy should answer these technical questions from the developer's point of view.
What I write here should be enough for home use, despite and because of the language barrier, and as generally understandable as possible.
CGG’s color spaces and color profiles have no priority https://www.cinelerra-gg.org/bugtracker/view.php?id=238
At this point the editor only needs to know that his monitor should be set to sRGB if color corrections are to be made with Cinelerra.
Yesterday I had revised the source code (except ABR) at the same time as your posting. These changes are not included, I see. A note on formatting, when removing comments, be careful to close the gaps, otherwise you'll get a new paragraph after each sentence. 😉
