Hi, Two sections pasted from the current Feature5 documentation say: page 12 Do NOT download the LEAP 10bit version unless you use h264 (it can't render 8bit h264). page 171 38. Cinx and a “Bit” of Confusion Cinx is the exact same program as Cin. The X (x) represents the roman numeral 10 for 10 bit as opposed to 8-bit standard. The third-party library used for x265 must be specially compiled with –bit- depth=10 in order to produce 10 bit rendered output. This build will not be able to output 8-bit depth which means you have to retain the Cin version also. Whatever build ffmpeg is linked to will determine what bit depth it can output. This is why there has to be separate builds. The same is true for x264 but no special build has been created for that; however the user can do their own build. If you install both packages, Cin and CinX, you may get “file conflicts of same file name” - just continue. Keep in mind that the regular 8-bit version works on 8-bit bytes – the standard word size for computers, but the 10-bit version has to use 2 words to contain all 10 bits so you can expect rendering to be as much as twice as slow. There is also a 12-bit version for consideration but currently the results are simply the same as 10-bit with padding to make 12-bit so it is of no value. I wonder if there is a typo above on page 12 "h264" vs "x265" and "x264" page 171, or something I have mis-interpreted? I have both Cin and Cinx installed on the same Leap15 and have the following libx installed: zypper se -i libx26 S | Name | Summary | Type ---+-------------+-------------------------------------------+-------- i+ | libx264-152 | A free h264/avc encoder - encoder binary | package i+ | libx265-151 | A free H265/HEVC encoder - encoder binary | package i+ | libx265-165 | A free H265/HEVC encoder - encoder binary | package ------------------------ As I understand the following url, x264 supports both 8-bit and 10-bit H.264 encoding https://gist.github.com/l4n9th4n9/4459997 and VLC 3.0: Hardware acceleration for H. 264/H. 265 in 8/10 Bit and CineForm https://www.slashcam.com/news/single/VLC-3-0--Hardware-acceleration-for-H--2... In short it seems like 10-bit h264 encoding is better for smaller file size and colors, also for 8-bit video sources.H It is not a HD Blu-ray video standard, but can be decoded on a PC. 10-bit h265 is part of the UHD Blu-ray video format. Thanks, Terje
Hi, Terje, I am in the process of trying to create a single manual so any errors you find with cin/cinx, just point them out so I can fix them. My attempt at creating a "tutorial" has turned out to be a complete failure! I found that I could write the words OK but the recording execution of the operations inside cinelerra was very jagged and I ended up starting over again 20 times. With very little success ever likely to occur this century, I abandoned the effort. Thanks for your input, gg/Phyllis
Hi Phyllis, As I'm somewhat unsure (confused) here, my question is still: Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265? A single, updated manual for "Cinelerra-GG Infinity" sounds to be to the 'right time', and yes, I will report typos/faults/RFEs on areas I see the demand for more detailed explanations or procedures. In general a 'single manual' needs to fill the demand for a combined "Users Guide" beside a "Reference or Feature Guide", maybe also as a online html and pdf print. And especially the new "gui ease of use" with the new "Cinfinity plugins icon set" compared with the original default icons or KB shortcuts as a reference. Related to my topic and for simpler expressions search, I would suggest standardizing where possible, i.e "10-bit" everywhere an no "10bit" or "10 bit". Should this possibly also affect the package name "Cinelerra10bit" accordingly? Terje ee the demand to be for. Den 02.01.2019 01:23, skrev Phyllis Smith: Hi, Terje, I am in the process of trying to create a single manual so any errors you find with cin/cinx, just point them out so I can fix them. My attempt at creating a "tutorial" has turned out to be a complete failure! I found that I could write the words OK but the recording execution of the operations inside cinelerra was very jagged and I ended up starting over again 20 times. With very little success ever likely to occur this century, I abandoned the effort. Thanks for your input, gg/Phyllis
Though I guess a RFE documentation page would be of beneficial, I will add at the same time here: Maybe this is a possibility to create a more integrated Help-system for Cinelerra-GG Infinity? I.e a "Help" menu with - link to the online manual - context sensitive Help? - the "About" button - Terje Den 02.01.2019 09:19, skrev terje: Hi Phyllis, As I'm somewhat unsure (confused) here, my question is still: Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265? A single, updated manual for "Cinelerra-GG Infinity" sounds to be to the 'right time', and yes, I will report typos/faults/RFEs on areas I see the demand for more detailed explanations or procedures. In general a 'single manual' needs to fill the demand for a combined "Users Guide" beside a "Reference or Feature Guide", maybe also as a online html and pdf print. And especially the new "gui ease of use" with the new "Cinfinity plugins icon set" compared with the original default icons or KB shortcuts as a reference. Related to my topic and for simpler expressions search, I would suggest standardizing where possible, i.e "10-bit" everywhere an no "10bit" or "10 bit". Should this possibly also affect the package name "Cinelerra10bit" accordingly? Terje ee the demand to be for. Den 02.01.2019 01:23, skrev Phyllis Smith: Hi, Terje, I am in the process of trying to create a single manual so any errors you find with cin/cinx, just point them out so I can fix them. My attempt at creating a "tutorial" has turned out to be a complete failure! I found that I could write the words OK but the recording execution of the operations inside cinelerra was very jagged and I ended up starting over again 20 times. With very little success ever likely to occur this century, I abandoned the effort. Thanks for your input, gg/Phyllis
Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265?
It is based on x265 BUT there is a enable flag in the build scripts for anyone doing there own build to use x264 instead. The confusion and uncorrected manual resulted in falsely believing that the maintainers of x264 included the possibility of having both 8/10 bit working without having to make a special compile. We were fooled for a month or so and I had updated the manual and did not correct it GG is doing a Leap15 cinx experiment right now so I can get the wording correct in the manual since we have not re-tested it in quite some time. And I will try to be consistent in the terminology as you suggested too. A single, updated manual for "Cinelerra-GG Infinity" sounds to be to the
'right time', and yes, I will report typos/faults/RFEs on areas I see the demand for more detailed explanations or procedures.
In general a 'single manual' needs to fill the demand for a combined "Users Guide" beside a "Reference or Feature Guide", maybe also as a online html and pdf print. And especially the new "gui ease of use" with the new "Cinfinity plugins icon set" compared with the original default icons or KB shortcuts as a reference.
Issue #77 in MantisBT is planned to be used to get reviewers help on the manual. Maybe this is a possibility to create a more integrated Help-system for
Cinelerra-GG Infinity?
I.e a "Help" menu with
- link to the online manual - context sensitive Help? - the "About" button
Believe it or not we actually have 2 shortcut single letters left in the english alphabet for use on the main window. One of these is "h" and we are saving it for Help ! The other letter is "p" which I think should be saved for "p-hyllis". P.S. gg's experiment was done faster than I could finish this email due to interruptions. With CINX, you can ONLY create 10-bit output when you render. gg/phyllis
Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265? It is based on x265 BUT there is a enable flag in the build scripts for anyone doing there own build to use x264 instead. Thank you for clarifying and confirming that, which was what I initially thought. The confusion and uncorrected manual resulted in falsely believing that the maintainers of x264 included the possibility of having both 8/10 bit working without having to make a special compile. We were fooled for a month or so and I had updated the manual and did not correct it Yes, I remember that (refer your previous mail 07.06.2018). But as Cinelerra (Cin) then is based on x264, I wonder if the following reference below is something that has been incorporated later in x264 and possibly yet change that "Cin" has the opportunity to work with both 8-bit and 10-bit x264? x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special. ffmpeg -h encoder=libx264 ...... Previously you had to compile x264 with --bit-depth=10, and then link your ffmpeg to either an 8-bit or 10-bit libx264, but that is now unnecessary. See Unify 8-bit and 10-bit CLI and libraries for more info. https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-... See Unify 8-bit and 10-bit CLI and libraries for more info. https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45... Very interesting and promising signals regarding better help and documentation, if this succeed to make things easier for new users to start with and next continue with Cinelerra. It is known this has been an Achilles heel and has caused the impression of a steep learning curve. Terje Den 02.01.2019 18:02, skrev Phyllis Smith: Is Cinelerra10bit (Cinx) based on 10-bit x264 or 10-bit x265? It is based on x265 BUT there is a enable flag in the build scripts for anyone doing there own build to use x264 instead. The confusion and uncorrected manual resulted in falsely believing that the maintainers of x264 included the possibility of having both 8/10 bit working without having to make a special compile. We were fooled for a month or so and I had updated the manual and did not correct it GG is doing a Leap15 cinx experiment right now so I can get the wording correct in the manual since we have not re-tested it in quite some time. And I will try to be consistent in the terminology as you suggested too. A single, updated manual for "Cinelerra-GG Infinity" sounds to be to the 'right time', and yes, I will report typos/faults/RFEs on areas I see the demand for more detailed explanations or procedures. In general a 'single manual' needs to fill the demand for a combined "Users Guide" beside a "Reference or Feature Guide", maybe also as a online html and pdf print. And especially the new "gui ease of use" with the new "Cinfinity plugins icon set" compared with the original default icons or KB shortcuts as a reference. Issue #77 in MantisBT is planned to be used to get reviewers help on the manual. Maybe this is a possibility to create a more integrated Help-system for Cinelerra-GG Infinity? I.e a "Help" menu with - link to the online manual - context sensitive Help? - the "About" button Believe it or not we actually have 2 shortcut single letters left in the english alphabet for use on the main window. One of these is "h" and we are saving it for Help ! The other letter is "p" which I think should be saved for "p-hyllis". P.S. gg's experiment was done faster than I could finish this email due to interruptions. With CINX, you can ONLY create 10-bit output when you render. gg/phyllis
A follow up: Shouldn't ffmpeg according to the reference below, list 'yuv422p10le' among the supported pixel formats on my system? ffmpeg -h encoder=libx264 ......... Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 ffmpeg -h encoder=libx265 ............ Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray --------- Terje J. H https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-...
|ffmpeg|
If using |ffmpeg| you can see what pixel formats and bit depths are supported by libx264:
|$ ffmpeg -h encoder=libx264 [...] Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le |
10-bit pixel formats are: yuv420p10le, yuv422p10le, yuv444p10le.
||
Previously you had to compile x264 with |--bit-depth=10|, and then link your |ffmpeg| to either an 8-bit or 10-bit libx264, but that is now unnecessary. See Unify 8-bit and 10-bit CLI and libraries <https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c5301e45522e57127db4> for more info.
edited Nov 29 '18 at 19:23 <https://video.stackexchange.com/posts/13166/revisions>
В сообщении от Monday 07 January 2019 02:32:22 Terje J Hanssen написал(а):
A follow up: Shouldn't ffmpeg according to the reference below, list 'yuv422p10le' among the supported pixel formats on my system?
ffmpeg -h encoder=libx264 ......... Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21
ffmpeg -h encoder=libx265 ............ Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
--------- Terje J. H
your ffmpeg must be one after https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/c6558e8840fbb2386bf8742e4d68... (author Luca Barbato <[email protected]> Tue, 26 Dec 2017 14:32:42 +0300 (12:32 +0100) committer Luca Barbato <[email protected]> Wed, 27 Dec 2017 18:59:45 +0300 (15:59 +0000) commit c6558e8840fbb2386bf8742e4d68dd6e067d262e tree 9f079a15424ed70fec0d131e45cd3fafd13cd65c tree | snapshot parent 2beba58e0e4bda688bf96e12413231607ceafdd4 commit | diff x264: Support version 153) and x264 revision obviously must be >= 153. If it still doesn't work - may be ffmpeg and/or x264 teams broke it unintentionally again :/
https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with -libx264/13166#13166
|ffmpeg|
If using |ffmpeg| you can see what pixel formats and bit depths are
supported by libx264: |$ ffmpeg -h encoder=libx264 [...] Supported pixel formats: yuv420p
yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le |
10-bit pixel formats are: yuv420p10le, yuv422p10le, yuv444p10le.
Previously you had to compile x264 with |--bit-depth=10|, and then link your |ffmpeg| to either an 8-bit or 10-bit libx264, but that is now unnecessary. See Unify 8-bit and 10-bit CLI and libraries <https://git.videolan.org/?p=x264.git;a=commit;h=71ed44c7312438fac7c5c530 1e45522e57127db4> for more info.
edited Nov 29 '18 at 19:23 <https://video.stackexchange.com/posts/13166/revisions>
Terje: mystery solved. Andrew's response jostled my brain and here is the answer for Cinelerra usage. You ran the command using the operating system (Leap 15) ffmpeg package. If you run the command using cd to cinelerra path /thirdpackage/ffmpeg4.1 then ./ffmpeg -h encoder=libx264 see:
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20l
This is exactly why cinelerra likes to include the thirdparty packages with it so as to know what is actually being used as opposed to what the O/S has installed. For x265, I have:
Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
Might be different for CINX. gg/Phyllis
Thanks for the replies, Phyllis and Adrew. Either it is my installation or just me. Actually I thought of both the Leap 15 system's and Cinelerra's bundled ffmpeg and libs. But so far I have not been able to find or use the latter "ffmpeg4.1" or "x264-snapshot-20180118-2245" as shown below. I have removed and re-installed the latest Cinelerra and Cinelerra10-bit packages on Leap 15 according to the standard installation procedures, in case there was something left from my previous Leap 42.3 to Leap 15 upgrade. Here is the output from my installation: # which cin cinx /usr/bin/cin /usr/bin/cinx # find / -name ffmpeg find: ‘/run/user/1000/gvfs’: Permission denied /home/cin/ffmpeg /usr/share/ffmpeg /usr/share/cin/ffmpeg /usr/share/cinx/ffmpeg /usr/bin/ffmpeg # find / -name ffmpeg4.1 find: ‘/run/user/1000/gvfs’: Permission denied # /home/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /home/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/ffmpeg/ffmpeg: No such file or directory # /usr/share/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/cinx/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cinx/ffmpeg/ffmpeg: No such file or directory and regarding x264 and x265 respectively: # find / -name x264-snapshot-20180118-2245 find: ‘/run/user/1000/gvfs’: Permission denied # find / -name libx264* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx264.so.152 /usr/lib64/libx264.so.148 # find / -name x265* find: ‘/run/user/1000/gvfs’: Permission denied # find / -name libx265* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx265.so.130 /usr/lib64/libx265.so.165 /usr/lib64/libx265.so.146 /usr/lib64/libx265.so.151 /usr/lib64/libx265.so.116 I expect your output was from Fedora. Do you have a chance to test and possibly confirm/clarify this on your Leap 15 installation?
I have locally corrected the manual to use 10-bit everywhere it makes sense, except for when the meaning is actually talking about 10 bits. I do not think I will be able to get gg to change the name Cinelerra10bit accordingly, but will try.
The package names are not a big deal. Yet, if so - maybe Cinelerrax264 and Cinelerrax265 would be better options, when the Cinelerra x264 version now should be able to handle both 8-bit and 10-bit color depth(?) Thanks, Terje Den 07.01.2019 03:49, skrev Phyllis Smith:
Terje: mystery solved. Andrew's response jostled my brain and here is the answer for Cinelerra usage.
You ran the command using the operating system (Leap 15) ffmpeg package. If you run the command using cd to cinelerra path /thirdpackage/ffmpeg4.1 then ./ffmpeg -h encoder=libx264 see:
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20l
This is exactly why cinelerra likes to include the thirdparty packages with it so as to know what is actually being used as opposed to what the O/S has installed.
For x265, I have:
Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
Might be different for CINX. gg/Phyllis
Meldingsteksten vil bli nedlastet etter behov.
В сообщении от Monday 07 January 2019 13:10:34 Terje J Hanssen написал(а):
Thanks for the replies, Phyllis and Adrew.
Either it is my installation or just me. Actually I thought of both the Leap 15 system's and Cinelerra's bundled ffmpeg and libs. But so far I have not been able to find or use the latter "ffmpeg4.1" or "x264-snapshot-20180118-2245" as shown below. I have removed and re-installed the latest Cinelerra and Cinelerra10-bit packages on Leap 15 according to the standard installation procedures, in case there was something left from my previous Leap 42.3 to Leap 15 upgrade.
Here is the output from my installation:
# which cin cinx /usr/bin/cin /usr/bin/cinx
# find / -name ffmpeg find: ‘/run/user/1000/gvfs’: Permission denied /home/cin/ffmpeg /usr/share/ffmpeg /usr/share/cin/ffmpeg /usr/share/cinx/ffmpeg /usr/bin/ffmpeg
# find / -name ffmpeg4.1 find: ‘/run/user/1000/gvfs’: Permission denied
# /home/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /home/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/ffmpeg/ffmpeg: No such file or directory # /usr/share/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/cinx/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cinx/ffmpeg/ffmpeg: No such file or directory
and regarding x264 and x265 respectively:
# find / -name x264-snapshot-20180118-2245 find: ‘/run/user/1000/gvfs’: Permission denied
# find / -name libx264* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx264.so.152 /usr/lib64/libx264.so.148
guess both 0.148 and 0.152 libraries less than desired 153 ... there seems to be multiple community packages for x264 - try to install newest snapshot (), and then rebuild system ffmpeg (one of them ..you seems to have at least two). Or just build yet another ffmpeg in your home directory , after building/installing new enough x264 package AND its development files (I assume SuSE like most binary distros split actual programs from their -dev and -doc portions) ... https://software.opensuse.org/package/libx264 https://build.opensuse.org/package/show/home%3ASocMinarch%3Ax264/x264 (seems to be at 0.157)
# find / -name x265* find: ‘/run/user/1000/gvfs’: Permission denied
# find / -name libx265* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx265.so.130 /usr/lib64/libx265.so.165 /usr/lib64/libx265.so.146 /usr/lib64/libx265.so.151 /usr/lib64/libx265.so.116
I expect your output was from Fedora. Do you have a chance to test and possibly confirm/clarify this on your Leap 15 installation?
I have locally corrected the manual to use 10-bit everywhere it makes sense, except for when the meaning is actually talking about 10 bits. I do not think I will be able to get gg to change the name Cinelerra10bit accordingly, but will try.
The package names are not a big deal. Yet, if so - maybe Cinelerrax264 and Cinelerrax265 would be better options, when the Cinelerra x264 version now should be able to handle both 8-bit and 10-bit color depth(?)
Thanks, Terje
Den 07.01.2019 03:49, skrev Phyllis Smith:
Terje: mystery solved. Andrew's response jostled my brain and here is the answer for Cinelerra usage.
You ran the command using the operating system (Leap 15) ffmpeg package. If you run the command using cd to cinelerra path /thirdpackage/ffmpeg4.1 then ./ffmpeg -h encoder=libx264 see:
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20l
This is exactly why cinelerra likes to include the thirdparty packages with it so as to know what is actually being used as opposed to what the O/S has installed.
For x265, I have:
Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
Might be different for CINX. gg/Phyllis
Meldingsteksten vil bli nedlastet etter behov.
Den 07.01.2019 14:08, skrev Andrew Randrianasulu:
guess both 0.148 and 0.152 libraries less than desired 153 ... there seems to be multiple community packages for x264 - try to install newest snapshot (), and then rebuild system ffmpeg (one of them ..you seems to have at least two). Or just build yet another ffmpeg in your home directory , after building/installing new enough x264 package AND its development files (I assume SuSE like most binary distros split actual programs from their -dev and -doc portions) ...
https://software.opensuse.org/package/libx264
https://build.opensuse.org/package/show/home%3ASocMinarch%3Ax264/x264 (seems to be at 0.157)
I install and use only the suggested prebuild multimedia packages from the "semi-official" Packman repo etc according to http://opensuse-guide.org/codecs.php By the way, shouldn't the thirdparty (statical linked) ffmpeg4.1 and x264 be part of a standard Cinelerra package installation? Terje
It turns out be both my installation - and me ;) Reading The Feature5 Manual (RTFM) better, I think section 1.1.6 explains the situation: "That is because the Cinelerra ffmpeg is a known static build and is usually the latest stable/released version. In the current case of Leap 15, libx264 and libx265 are not built in and this can be debilitating; You can always run “ffmpeg -formats” and “ffmpeg -codecs” to see what is available on your system." ----------- I have the RPM binary packages installed for Leap15, which is unbundled builds which links dynamic to the system ffmpeg and libx264 (Cinelerra10bit to libx265). Obviously the current installed system ffmpeg/libx264 (as already pointed out ) require higher versions to support optional 'yuv422p10le' (10-bit for Cin). Why not ffmpeg/libx265 doesn't confirm the pixel format 'yuv422p10le' (10-bit) I don't know, maybe this also need a higher version of ffmpeg if Cinx should support 10-bit color depth ..... Feature5 section 1.2: .... alternatively there are some pre-built dynamic or static binaries https://cinelerra-gg.org/download/tars The “tars” directory contains single-user static builds for different distros. Do NOT download the LEAP 10bit version unless you use h264 (it can't render 8bit h264). page 14 for Leap 42 and Leap 15 (at least on my current, open Feature5 version): The 'zypper ar' .... commands should be updated from 'cincv' to 'cingg' Terje J. H Den 07.01.2019 11:10, skrev Terje J Hanssen:
Thanks for the replies, Phyllis and Adrew.
Either it is my installation or just me. Actually I thought of both the Leap 15 system's and Cinelerra's bundled ffmpeg and libs. But so far I have not been able to find or use the latter "ffmpeg4.1" or "x264-snapshot-20180118-2245" as shown below. I have removed and re-installed the latest Cinelerra and Cinelerra10-bit packages on Leap 15 according to the standard installation procedures, in case there was something left from my previous Leap 42.3 to Leap 15 upgrade.
Here is the output from my installation:
# which cin cinx /usr/bin/cin /usr/bin/cinx
# find / -name ffmpeg find: ‘/run/user/1000/gvfs’: Permission denied /home/cin/ffmpeg /usr/share/ffmpeg /usr/share/cin/ffmpeg /usr/share/cinx/ffmpeg /usr/bin/ffmpeg
# find / -name ffmpeg4.1 find: ‘/run/user/1000/gvfs’: Permission denied
# /home/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /home/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/ffmpeg/ffmpeg: No such file or directory # /usr/share/cin/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cin/ffmpeg/ffmpeg: No such file or directory # /usr/share/cinx/ffmpeg/ffmpeg -h encoder=libx264 -bash: /usr/share/cinx/ffmpeg/ffmpeg: No such file or directory
and regarding x264 and x265 respectively:
# find / -name x264-snapshot-20180118-2245 find: ‘/run/user/1000/gvfs’: Permission denied
# find / -name libx264* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx264.so.152 /usr/lib64/libx264.so.148
# find / -name x265* find: ‘/run/user/1000/gvfs’: Permission denied
# find / -name libx265* find: ‘/run/user/1000/gvfs’: Permission denied /usr/lib64/libx265.so.130 /usr/lib64/libx265.so.165 /usr/lib64/libx265.so.146 /usr/lib64/libx265.so.151 /usr/lib64/libx265.so.116
I expect your output was from Fedora. Do you have a chance to test and possibly confirm/clarify this on your Leap 15 installation?
I have locally corrected the manual to use 10-bit everywhere it makes sense, except for when the meaning is actually talking about 10 bits. I do not think I will be able to get gg to change the name Cinelerra10bit accordingly, but will try. The package names are not a big deal. Yet, if so - maybe Cinelerrax264 and Cinelerrax265 would be better options, when the Cinelerra x264 version now should be able to handle both 8-bit and 10-bit color depth(?)
Thanks, Terje
Den 07.01.2019 03:49, skrev Phyllis Smith:
Terje: mystery solved. Andrew's response jostled my brain and here is the answer for Cinelerra usage.
You ran the command using the operating system (Leap 15) ffmpeg package. If you run the command using cd to cinelerra path /thirdpackage/ffmpeg4.1 then ./ffmpeg -h encoder=libx264 see:
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20l
This is exactly why cinelerra likes to include the thirdparty packages with it so as to know what is actually being used as opposed to what the O/S has installed.
For x265, I have:
Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
Might be different for CINX. gg/Phyllis
Meldingsteksten vil bli nedlastet etter behov.
Terje:
It turns out be both my installation - and me ;)
Actually I do not think it is either one ;) !
Reading The Feature5 Manual (RTFM) better, I think section 1.1.6 explains the situation: "That is because the Cinelerra ffmpeg is a known static build and is usually the latest stable/released version. In the current case of Leap 15, libx264 and libx265 are not built in and this can be debilitating;
Sometimes you can read in too much. This is specifically ONLY for unbundled builds. Unbundled builds is meant for the purists in the O/S distro world who want to include Cinelerra-gg in their distros but do not want to include another copy of ffmpeg. The warning is only for them to make them aware that some of the latest stuff/codecs may not be available for use in cinelerra BECAUSE they use a different version of ffmpeg. Cin and CinX package builds on the cinelerra-gg.org website are built WITH FFMPEG 4.1 and all of the third-party packages that are known to work. However, you do not see them (as I erroneously suggested) in a directory when you do a PACKAGE build as opposed to a TAR build.
----------- I have the RPM binary packages installed for Leap15, which is unbundled builds which links dynamic to the system ffmpeg and libx264 (Cinelerra10bit to libx265).
So the above is not true; if you used the package build, it is not the unbundled build.
Obviously the current installed system ffmpeg/libx264 (as already pointed out ) require higher versions to support optional 'yuv422p10le' (10-bit for Cin).
So GG just now was able to boot Leap 15 and has passed along to me how to make sure you get the 8-bit and 10-bit capabilities with X264. Here is how: (1) load a small video (do not need audio) (2) File-> Render (3) choose File Format - ffmpeg and mp4 and a name for the output file (4) click on the wrench icon on the right side of the word VIDEO (5) in the Pixels text box, scroll down to yuv420p10le (the 10 stands for 10-bit) (6) checkmark OK Now if you go to the Resources window, right mouse button on the highlighted media, you can choose Info and then Details to see it is pix yuv420p10le and if you do the same on your 8-bit input media you will not see 10le. Or, knowing as how you really like mediainfo, just run that on your output media and you will see things like: profile = High [email protected] and Bit Depth = 10 bits . You can do the same experiment with CINX. Do NOT download the LEAP 10bit version unless you use h264 (it can't
render 8bit h264).
page 14 for Leap 42 and Leap 15 (at least on my current, open Feature5 version): The 'zypper ar' .... commands should be updated from 'cincv' to 'cingg'
Thank you. I changed all of the cincv to cingg in my local copy and fixed any other 8bit/10bit errors.
Thanks a lot for the clarification, Phyllis and test procedure, GG: Den 12.01.2019 23:59, skrev Phyllis Smith: Terje: Sometimes you can read in too much. This is specifically ONLY for unbundled builds. Unbundled builds is meant for the purists in the O/S distro world who want to include Cinelerra-gg in their distros but do not want to include another copy of ffmpeg. The warning is only for them to make them aware that some of the latest stuff/codecs may not be available for use in cinelerra BECAUSE they use a different version of ffmpeg. Cin and CinX package builds on the cinelerra-gg.org<http://cinelerra-gg.org> website are built WITH FFMPEG 4.1 and all of the third-party packages that are known to work. However, you do not see them (as I erroneously suggested) in a directory when you do a PACKAGE build as opposed to a TAR build. Looks like this may be a useful emphazing in a later revision of the manual ...... ----------- I have the RPM binary packages installed for Leap15, which is unbundled builds which links dynamic to the system ffmpeg and libx264 (Cinelerra10bit to libx265). So the above is not true; if you used the package build, it is not the unbundled build. Obviously the current installed system ffmpeg/libx264 (as already pointed out ) require higher versions to support optional 'yuv422p10le' (10-bit for Cin). (I test-installed also openSUSE Tumbleweed rolling release. It had ffmpeg 4.1 but not libx264 new enough, as it didn't confirm 'yuv422p10le'. I will put a notice of information to the openSUSE team about this, even it does no matter regarding Cinelerra-gg, when this is bundled in the rpm package installation. On the other hand 'yuv422p10le' was confirmed on Ubuntu 18.04 on the same XPS13.) So GG just now was able to boot Leap 15 and has passed along to me how to make sure you get the 8-bit and 10-bit capabilities with X264. Here is how: (1) load a small video (do not need audio) (2) File-> Render (3) choose File Format - ffmpeg and mp4 and a name for the output file (4) click on the wrench icon on the right side of the word VIDEO (5) in the Pixels text box, scroll down to yuv420p10le (the 10 stands for 10-bit) (6) checkmark OK Now if you go to the Resources window, right mouse button on the highlighted media, you can choose Info and then Details to see it is pix yuv420p10le and if you do the same on your 8-bit input media you will not see 10le. Or, knowing as how you really like mediainfo, just run that on your output media and you will see things like: profile = High [email protected]<mailto:[email protected]> and Bit Depth = 10 bits . You can do the same experiment with CINX. Yup. I tested to render a 10-bit ProRes HQ file (.mov, 422 color-depth), not really small (1,8 GB, EAT, 3.5 min rendering) and got the following output info: Source ProRes file: --------------------------------- Cin > Info > Details: Filbane: /video/MOV/hd01.mov 1786412681 bytes Info: format: mov,mp4,m4a,3gp,3g2,mj2 1 video stream Vid0 (0), id 0x000093: video1 prores 1920x1080 25.00 pix yuv422p10le 1781+0 frms 71.24 secs 0:01:11.24 1 audio stream Aud0 (1), id 0x01000c: audio1-16 pcm_s24le s32 48000 24bits 3421421+0 smpl 71.28 secs 0:01:11.28 mediainfo hd01.mov | grep Format Format : QuickTime Format/Info : Original Apple specifications Format : ProRes Format version : Version 0 Format profile : 422 HQ Format : PCM Format settings : Little / Signed Rendered MP4 file: --------------------------------- Cin > Info > Details: Filbane: /video/MOV/hd01_cin_ffmpeg_mp4.mp4 96422835 bytes Info: format: mov,mp4,m4a,3gp,3g2,mj2 1 video stream Vid0 (0), id 0x00001b: video1 h264 1920x1080 25.00 pix yuv422p10le 1781+0 frms 71.24 secs 0:01:11.24 1 audio stream Aud0 (1), id 0x015002: audio1-6 aac fltp 48000 0bits 3421392+0 smpl 71.28 secs 0:01:11.28 major_brand=isom minor_version=512 compatible_brands=isomiso2avc1mp41 encoder=Lavf58.20.100 mediainfo hd01_cin_ffmpeg_mp4.mp4 | grep Format Format : MPEG-4 Format profile : Base Media Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:2:2@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Format settings, GOP : M=4, N=25 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC ------------------------------------------- ......also to @Sam: Maybe 10-bit ProRes HQ (.mov), 4:2:2 color depth should be added on the Cin-GG supported codecs list (decoding)? -------------- Thx Terje
Terje: just some minor feedback. Related to my topic and for simpler expressions search, I would suggest
standardizing where possible, i.e "10-bit" everywhere an no "10bit" or "10 bit". Should this possibly also affect the package name "Cinelerra10bit" accordingl
I have locally corrected the manual to use 10-bit everywhere it makes sense, except for when the meaning is actually talking about 10 bits. I do not think I will be able to get gg to change the name Cinelerra10bit accordingly, but will try.
Also, you are right! the article you quoted at: https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-... which has a edited date of November 2018 does state that now you do not have to do anything special in x264 to use 8 or 10 bit. If you "cd" to the cinelerra /thirdparty/x264-snapshot-20180118-2245 directory and keyin ./x264 --h you clearly see at the top "Output bit depth: 8/10". Yeah! so I removed the wording in the manual about compiling x264 with 10-bit option. I will have to look at the following yet/too:
Shouldn't ffmpeg according to the reference below, list 'yuv422p10le' among the supported pixel formats on my system?
Thanks for your welcome input, gg/Phyllis
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Terje J Hanssen