How to identify if a running CinGG is the Regular or Multibit version?
Previously package installations used /usr/bin/cin to start the Regular version vs /usr/bin/cinx for the 10-bit version (rpm on openSUSE). Now the Appimage name itself contains Multibit for the latter. But for a running CinGG system, "Settings > Preferences | About contains" Built date and time and libav version It seems as nothing here tells if it is the regular or multibit version running, or? Will it be possible to add the version info here? Terje
вт, 9 июл. 2024 г., 02:35 Terje J. Hanssen via Cin < [email protected]>:
Previously package installations used /usr/bin/cin to start the Regular version vs /usr/bin/cinx for the 10-bit version (rpm on openSUSE). Now the Appimage name itself contains Multibit for the latter.
But for a running CinGG system, "Settings > Preferences | About contains"
Built date and time and libav version
It seems as nothing here tells if it is the regular or multibit version running, or?
Will it be possible to add the version info here?
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg. So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
Terje
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Will it be possible to add the version info here?
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
This is EXACTLY what I do !
Den 09.07.2024 02:24, skrev Phyllis Smith via Cin:
Will it be possible to add the version info here?
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
This is EXACTLY what I do !
Some sample steps here would be useful and worth having for simple testing ;) And, one needs to load a 10-bit video file (fx prores, cfhd or other) to be able to render a 10-bit output? Which 10-bit/12-bit output formats are currently supported in CinGG or potential actual to add support for with profiles etc. ? ----------------- I looked into which pixel formats current ffmpeg-7 encoders in question do support as follows: Cineform ffmpeg -hide_banner -h encoder=cfhd | grep Supported Supported pixel formats: yuv422p10le gbrp12le gbrap12le Prores ffmpeg -hide_banner -h encoder=cfhd | grep Supported Supported pixel formats: yuv422p10le gbrp12le gbrap12le x264 ffmpeg -hide_banner -h encoder=libx264 | grep Supported Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray gray10le x265 ffmpeg -hide_banner -h encoder=libx265 | grep Supported Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le AV1 ffmpeg -hide_banner -h encoder=libsvtav1 | grep Supported Supported pixel formats: yuv420p yuv420p10le ffmpeg -hide_banner -h encoder=av1_nvenc | grep Supported Supported hardware devices: cuda cuda Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 bgra rgb0 rgba x2rgb10le x2bgr10le gbrp gbrp16le cuda ffmpeg -hide_banner -h encoder=av1_qsv | grep Supported Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 p010le qsv ffmpeg -hide_banner -h encoder=av1_vaapi | grep Supported Supported hardware devices: vaapi Supported pixel formats: vaapi ----------- Earlier topics as background references: [CinCV TNG] 10-bit ProRes 422 (HQ) and matching Cinelerra Color models? https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q1/004083.html [CinCV TNG] 10-Bit Cinelerra-GG version - CINX https://lists.cinelerra-cv.org/pipermail/cinelerra/2018q2/008888.html [Cin] Cinx - 10-bit h264 and/or h265 https://lists.cinelerra-gg.org/pipermail/cin/2019-January/000113.html UHD and 10-bit (forum 2019) https://www.cinelerra-gg.org/forum/help-video/uhd-and-10-bit/
ср, 10 июл. 2024 г., 01:45 Terje J. Hanssen <[email protected]>:
Den 09.07.2024 02:24, skrev Phyllis Smith via Cin:
Will it be possible to add the version info here?
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
This is EXACTLY what I do !
Some sample steps here would be useful and worth having for simple testing ;)
And, one needs to load a 10-bit video file (fx prores, cfhd or other) to be able to render a 10-bit output?
for just testing you probably can load any video/image - it will error out at rendering time if libx265 does not support those high depths. I have read somewhere that at least with x264 even normal, originally 8bit content showed less visible gradients in flatly colored areas (like anime/cartoons) if encoded as 10bit h264. You can run your own test and see if it holds true for footage you have.
Which 10-bit/12-bit output formats are currently supported in CinGG or potential actual to add support for with profiles etc. ? -----------------
I looked into which pixel formats current ffmpeg-7 encoders in question do support as follows:
Cineform ffmpeg -hide_banner -h encoder=cfhd | grep Supported Supported pixel formats: yuv422p10le gbrp12le gbrap12le
Prores ffmpeg -hide_banner -h encoder=cfhd | grep Supported Supported pixel formats: yuv422p10le gbrp12le gbrap12le
x264 ffmpeg -hide_banner -h encoder=libx264 | grep Supported Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray gray10le
x265 ffmpeg -hide_banner -h encoder=libx265 | grep Supported Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
AV1 ffmpeg -hide_banner -h encoder=libsvtav1 | grep Supported Supported pixel formats: yuv420p yuv420p10le
ffmpeg -hide_banner -h encoder=av1_nvenc | grep Supported Supported hardware devices: cuda cuda Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 bgra rgb0 rgba x2rgb10le x2bgr10le gbrp gbrp16le cuda
ffmpeg -hide_banner -h encoder=av1_qsv | grep Supported Supported hardware devices: qsv qsv qsv Supported pixel formats: nv12 p010le qsv
ffmpeg -hide_banner -h encoder=av1_vaapi | grep Supported Supported hardware devices: vaapi Supported pixel formats: vaapi
-----------
Earlier topics as background references:
[CinCV TNG] 10-bit ProRes 422 (HQ) and matching Cinelerra Color models? https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q1/004083.html
[CinCV TNG] 10-Bit Cinelerra-GG version - CINX https://lists.cinelerra-cv.org/pipermail/cinelerra/2018q2/008888.html
[Cin] Cinx - 10-bit h264 and/or h265 https://lists.cinelerra-gg.org/pipermail/cin/2019-January/000113.html
UHD and 10-bit (forum 2019) https://www.cinelerra-gg.org/forum/help-video/uhd-and-10-bit/
@Terje Do you think the following sentence is correct? (possibly to be included in the section on CinX in the manual) To recap: all codecs except x265 (hevc) work at whatever bit-depth is supported, both in decoding and in encoding. x265 on the other hand, works at all bit-depths in decoding but in encoding only supports 8-bit. To get x265 encoding at 10/12-bit you have to use CinX (multibit), but lose the ability to do x265 encoding at 8-bit.
ср, 10 июл. 2024 г., 14:46 Andrea paz <[email protected]>:
@Terje Do you think the following sentence is correct? (possibly to be included in the section on CinX in the manual)
To recap: all codecs except x265 (hevc) work at whatever bit-depth is supported, both in decoding and in encoding. x265 on the other hand, works at all bit-depths in decoding but in encoding only supports 8-bit. To get x265 encoding at 10/12-bit you have to use CinX (multibit), but lose the ability to do x265 encoding at 8-bit.
but why? I mean, patch currently building x265 for all depths (8, 10,12 ) should make x265 lib capable of encoding all of them ? But I haven't tested this recently, due to rel. slow speed of my machines ....
True, I downloaded the multibit appimage and did an 8-bit x265 rendering successfully. In contrast, the 8-bit version does not render at 10-bit. So we keep the 8-bit because it is more efficient (1 word vs 2 words)? Are there other reasons? Wouldn't it be less confusing to just have the multibit?
Den 10.07.2024 14:51, skrev Andrea paz:
True, I downloaded the multibit appimage and did an 8-bit x265 rendering successfully. In contrast, the 8-bit version does not render at 10-bit. So we keep the 8-bit because it is more efficient (1 word vs 2 words)? Are there other reasons? Wouldn't it be less confusing to just have the multibit?
Does x264 then lose something, 8 or 10bit on the Multibit version? If not, it seems beneficial and reasonable to merge and keep just the latter version; less work for both developers and users, and not at least less confusing. It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual.
It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual.
CineformHD is only mentioned in the "Overview on Formats and Codecs" appendix. If you provide a brief description we can incorporate it into this section. Or you can do a more in-depth specific section in the "Rendering" chapter, "Some specific Rendering" section. I don't know if the manual is the right place to describe the various codecs, though. In the "Private Options" section, it is recommended to study the white papers of each codecs we want to use: "Render presets in CINELERRA-GG should work Out Of the Box. You can still configure the Global Options and Private Options manually. Finding the combination of parameters that best suits your needs, or simply finding working (legal) combinations, requires studying each codec in depth. You can start by looking in Wikipedia until you get to download and study the white papers of the codecs of interest. In any case, you must then start a long experimental phase, trying presets with different configurations or creating new ones, until you get satisfactory results." Perhaps the best thing is a document outside the manual but downloadable from the site, like your "Preserving Camcoder Media.pdf," where you can accumulate all the data on codecs that users have experienced. I found this table: https://postimg.cc/PPwPgn83
Den 10.07.2024 21:54, skrev Andrea paz:
It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual. CineformHD is only mentioned in the "Overview on Formats and Codecs" appendix.
Ok, there it was mentioned. I searched only the html manual index and didn't find it.
If you provide a brief description we can incorporate it into this section. Or you can do a more in-depth specific section in the "Rendering" chapter, "Some specific Rendering" section. I don't know if the manual is the right place to describe the various codecs, though. In the "Private Options" section, it is recommended to study the white papers of each codecs we want to use:
"Render presets in CINELERRA-GG should work Out Of the Box. You can still configure the Global Options and Private Options manually. Finding the combination of parameters that best suits your needs, or simply finding working (legal) combinations, requires studying each codec in depth. You can start by looking in Wikipedia until you get to download and study the white papers of the codecs of interest. In any case, you must then start a long experimental phase, trying presets with different configurations or creating new ones, until you get satisfactory results."
Perhaps the best thing is a document outside the manual but downloadable from the site, like your "Preserving Camcoder Media.pdf," where you can accumulate all the data on codecs that users have experienced. I found this table: https://postimg.cc/PPwPgn83
I didn't really mean that Cineform should get a more specific description than other codecs. And of course, the CinGG manual has to delimit surrounding details, a knowledge interested can find other places. In addition to the table url above and wikipedia mentioned, here follows url to the Cineform SDK https://gopro.github.io/cineform-sdk/
Den 10.07.2024 22:56, skrev Terje J. Hanssen:
Den 10.07.2024 21:54, skrev Andrea paz:
It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual. CineformHD is only mentioned in the "Overview on Formats and Codecs" appendix.
Ok, there it was mentioned. I searched only the html manual index and didn't find it.
If you provide a brief description we can incorporate it into this section. Or you can do a more in-depth specific section in the "Rendering" chapter, "Some specific Rendering" section. I don't know if the manual is the right place to describe the various codecs, though. In the "Private Options" section, it is recommended to study the white papers of each codecs we want to use:
"Render presets in CINELERRA-GG should work Out Of the Box. You can still configure the Global Options and Private Options manually. Finding the combination of parameters that best suits your needs, or simply finding working (legal) combinations, requires studying each codec in depth. You can start by looking in Wikipedia until you get to download and study the white papers of the codecs of interest. In any case, you must then start a long experimental phase, trying presets with different configurations or creating new ones, until you get satisfactory results."
Perhaps the best thing is a document outside the manual but downloadable from the site, like your "Preserving Camcoder Media.pdf," where you can accumulate all the data on codecs that users have experienced. I found this table: https://postimg.cc/PPwPgn83
I didn't really mean that Cineform should get a more specific description than other codecs. And of course, the CinGG manual has to delimit surrounding details, a knowledge interested can find other places.
In addition to the table url above and wikipedia mentioned, here follows url to the Cineform SDK https://gopro.github.io/cineform-sdk/
1) To sum up and add to my background references, I forgot we also had a thoroughly discussion about Cin vs Cinx in 2021 So evidently more frequent repetitions is needed as getting older ;) from this post by Andrea on, section: 2- I don't really understand the multibit version.Why put both the regular version and the multibit version? Are there things that work with one and not the other version? https://www.mail-archive.com/[email protected]/msg03385.html 2) Possibly I can make an update extension of my previous "Preserving Camcoder Media.pdf," document included experiences from my ongoing DVD project, but not before I have finished that. Even though I don't plan to make a codec/encoder document, I still think it would useful with an extensible table or list over "Supported pixel formats" for each encoder of interest. This based on CinGG's internal ffmpeg engine, which I don't think can be accessed by users from a CinGG package or appimage, and which might be some different from the system's enabled codecs and encoders(?) By the way, this should not need to a longer document than a few of pages. As an example using my own systems ffmpeg, a short encoders list (of my current interest) could be ffmpeg -hide_banner -encoders | egrep "av1|x265|x264|mpeg2video|prores|cfhd|ffv1" V....D libaom-av1 libaom AV1 (codec av1) V....D librav1e librav1e AV1 (codec av1) V..... libsvtav1 SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1) V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1) V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V....D av1_amf AMD AMF AV1 encoder (codec av1) V....D av1_vaapi AV1 (VAAPI) (codec av1) VF...D cfhd GoPro CineForm HD V.S..D ffv1 FFmpeg video codec #1 V....D libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264) V....D libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264) V....D libx265 libx265 H.265 / HEVC (codec hevc) V.S... mpeg2video MPEG-2 video V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V....D mpeg2_vaapi MPEG-2 (VAAPI) (codec mpeg2video) VF...D prores Apple ProRes VF...D prores_aw Apple ProRes (codec prores) VFS... prores_ks Apple ProRes (iCodec Pro) (codec prores) A....D wmav1 Windows Media Audio 1 and some selected encoder's "Supported pixel formats" ffmpeg -hide_banner -h encoder=cfhd | grep "Supported pixel formats" Supported pixel formats: yuv422p10le gbrp12le gbrap12le ffmpeg -hide_banner -h encoder=mpeg2video | grep "Supported pixel formats" Supported pixel formats: yuv420p yuv422p ffmpeg -hide_banner -h encoder=libx265 | grep "Supported pixel formats" Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le ffmpeg -hide_banner -h encoder=libsvtav1 | grep "Supported pixel formats" Supported pixel formats: yuv420p yuv420p10le terje@localhost:~> ffmpeg -hide_banner -h encoder=av1_qsv | grep "Supported pixel formats" Supported pixel formats: nv12 p010le qsv
Catching up on this thread with some trivial commentary on my part. I looked into which pixel formats current ffmpeg-7 encoders in question do
support as follows: "QUOTE from Terje"
The "pixel formats" that CinGG supports with whatever ffmpeg version is currently being used, is shown in the Render Menu when you click on the Video wrench. There is a box labeled "Pixels" and when you click on the down arrow next to the box, it displays all of the supported formats so you do not have to reference the ffmpeg documentation externally. So we keep the 8-bit because it is more efficient (1 word vs 2 words)? Are
there other reasons? Wouldn't it be less confusing to just have the multibit? "QUOTE from Andrea"
As long as we have the capability to support older operating systems, smaller computers, 32-bit, and older cameras, there does not seem to be any reason to eliminate the non-multibit version. Now there is still a choice and there may be reasons to not just have the multibit version from what I read based on the multibit taking more CPU (I have not tested this). It does not seem confusing to me -- probably newer users with newer systems will automatically pick the multibit version. less work for both developers and users "QUOTE from Terje"
Because I sometimes do multiple builds in a single session, the extra time it takes to compile the multibit version is detrimental for me. On the other hand, creating a single AppImage multibit version of the generally newer operating system is only done by me once a month or less and no work at all. BTW, the CinGG-20240630-x86_64-older-distros-multibit.AppImage was just a request from a Red Hat user (like Fedora) who wanted Intel graphics capability that I just happened to have set up. I am not sure if it is much used. And I do not see any additional work needed by users -- they should just pick that single multibit version. It would also be useful with an updated list over supported formats, codecs
and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual. "QUOTE Terje"
Accuracy and being up to date on ffmpeg documentation is really best done by their team. Those using AppImage may not have ffmpeg actually installed on their computer, but all of the ffmpeg documentation is readily available on the internet. Duplication is not a good idea as it may not get updated. CineformHD is only mentioned in the "Overview on Formats and Codecs"
appendix "QUOTE Andrea"
There is an index entry in the Manual of "codec". Maybe adding "Overview on Formats and Codecs" could be another index?
Den 12.07.2024 01:02, skrev Phyllis Smith:
Catching up on this thread with some trivial commentary on my part.
I looked into which pixel formats current ffmpeg-7 encoders in question do support as follows: "QUOTE from Terje"
The "pixel formats" that CinGG supports with whatever ffmpeg version is currently being used, is shown in the Render Menu when you click on the Video wrench. There is a box labeled "Pixels" and when you click on the down arrow next to the box, it displays all of the supported formats so you do not have to reference the ffmpeg documentation externally.
Thank you, that was clarifying using CinGG, and I did some browsing tests, additional selected container format and compression (?) It's late, so please excuse and correct me if I did miss something during a quick comparison with my last post and could not see these encoders av1_nvenc, av1_qsv, av1_amf, mpeg2_qsv (hwaccel) and cfhd
So we keep the 8-bit because it is more efficient (1 word vs 2 words)?Are there other reasons? Wouldn't it be less confusing to just havethe multibit? "QUOTE from Andrea"
As long as we have the capability to support older operating systems, smaller computers, 32-bit, and older cameras, there does not seem to be any reason to eliminate the non-multibit version. Now there is still a choice and there may be reasons to not just have the multibit version from what I read based on the multibit taking more CPU (I have not tested this). It does not seem confusing to me -- probably newer users with newer systems will automatically pick the multibit version.
less work for both developers and users "QUOTE from Terje"
Because I sometimes do multiple builds in a single session, the extra time it takes to compile the multibit version is detrimental for me. On the other hand, creating a single AppImage multibit version of the generally newer operating system is only done by me once a month or less and no work at all. BTW, the CinGG-20240630-x86_64-older-distros-multibit.AppImage was just a request from a Red Hat user (like Fedora) who wanted Intel graphics capability that I just happened to have set up. I am not sure if it is much used. And I do not see any additional work needed by users -- they should just pick that single multibit version.
Ok, no extra maintaining job. I have up to now installed both versions of the belief that only Multibit did support 10bit or higher color depth (esp. x265). So to clarify further, is also einander's CinGG package version (rpm for me) identical with the Multibit version (earlier Cinx)?
It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual. "QUOTE Terje"
Accuracy and being up to date on ffmpeg documentation is really best done by their team. Those using AppImage may not have ffmpeg actually installed on their computer, but all of the ffmpeg documentation is readily available on the internet. Duplication is not a good idea as it may not get updated.
CineformHD is only mentioned in the "Overview on Formats and Codecs"appendix"QUOTE Andrea"
There is an index entry in the Manual of "codec". Maybe adding "Overview on Formats and Codecs" could be another index?
I, too, wonder whether einhander binaries are 8-bit or multibit. The underlying theme is that, normally, video editing involves powerful hardware and, I think, the majority have it. However, it is also true that CinGG is suitable for non-powerful hardware and it could be that the majority of its users have dated hardware. A survey of the PCs that CinGG users have would be interesting. One possible idea (not important, surely it is better to leave everything as it is now) could be to change the current default (8-bit) to multibit, for example: CinGG.appimage --> CinGG_8-bit.appimage CinGG_multibit.appimage --> CinGG.appimage and the same for the source which should include by default the flag : -bit-depth=10 (which involves creating a patch for 8-bit and removing the current patch for multibit). This makes it clearer that the 8-bit (more limited but also more efficient) should be used by those who have an older system; otherwise the multibit version is more complete. I repeat: this is not a major change and we can very well continue as it is now. In any case I will put a modification in the manual to explain which configuration best suits our own hardware. Note: the 8-bit limitation only affects encoding with 10-bit x265. I have the following error: [libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not supported by the libx265 encoder. [libx265 @ 0x71dcbc0afac0] Supported pixel formats: [libx265 @ 0x71dcbc0afac0] yuv420p [libx265 @ 0x71dcbc0afac0] yuvj420p [libx265 @ 0x71dcbc0afac0] yuv422p [libx265 @ 0x71dcbc0afac0] yuvj422p [libx265 @ 0x71dcbc0afac0] yuv444p [libx265 @ 0x71dcbc0afac0] yuvj444p [libx265 @ 0x71dcbc0afac0] gbrp [libx265 @ 0x71dcbc0afac0] gray @Terje Great link to the cheat sheets you mentioned on the forum. Instead of making a new document I can put that link on the manual. https://gist.github.com/dexeonify/ed31c7d85fcf7297719e2ec4740fafda @Terje Having an AMD GPU, I have often thought of making a preset for AMF. However, it requires AMD's closed driver (amdgpu-pro) and also Vulkan. There are discussions that soon AMF will also work with open amdgpu (supported in Mesa). In that case I will try to make the preset. For the Nvidia/Intel cases, I could not test and so I did not try to make new presets.
Den 12.07.2024 10:39, skrev Andrea paz:
I, too, wonder whether einhander binaries are 8-bit or multibit.
I did a render test, and it seems to me that this is the 8-bit version. If einander once make a change, I would suggest to put the Cinx Suse version on Slowroll ;)
Note: the 8-bit limitation only affects encoding with 10-bit x265. I have the following error:
[libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not supported by the libx265 encoder. [libx265 @ 0x71dcbc0afac0] Supported pixel formats: [libx265 @ 0x71dcbc0afac0] yuv420p [libx265 @ 0x71dcbc0afac0] yuvj420p [libx265 @ 0x71dcbc0afac0] yuv422p [libx265 @ 0x71dcbc0afac0] yuvj422p [libx265 @ 0x71dcbc0afac0] yuv444p [libx265 @ 0x71dcbc0afac0] yuvj444p [libx265 @ 0x71dcbc0afac0] gbrp [libx265 @ 0x71dcbc0afac0] gray
@Terje Great link to the cheat sheets you mentioned on the forum. Instead of making a new document I can put that link on the manual. https://gist.github.com/dexeonify/ed31c7d85fcf7297719e2ec4740fafda
Well, I loaded a 10-bit Cineform (ffmpeg rendered) file with Cinelerra and was able to render it to the following 10-bit formats (0 content didn't succeed in either version, interested to hear if other get them to work): du -sh * 3,3G cfhd01.mkv 23M h265-10bit_yuv422p10le_cfhd01.mp4 23M h265-10bit_yuv422p_cfhd01.mp4 17M av1_svt_10bit_yuv420p10le_cfhd01.webm ------didn't work: 0 h264-10bit_yuv422p10le_cfhd01.mp4 0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
Den 13.07.2024 13:01, skrev Terje J. Hanssen:
Den 12.07.2024 10:39, skrev Andrea paz:
I, too, wonder whether einhander binaries are 8-bit or multibit.
I did a render test, and it seems to me that this is the 8-bit version. If einander once make a change, I would suggest to put the Cinx Suse version on Slowroll ;)
Note: the 8-bit limitation only affects encoding with 10-bit x265. I have the following error:
[libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not supported by the libx265 encoder. [libx265 @ 0x71dcbc0afac0] Supported pixel formats: [libx265 @ 0x71dcbc0afac0] yuv420p [libx265 @ 0x71dcbc0afac0] yuvj420p [libx265 @ 0x71dcbc0afac0] yuv422p [libx265 @ 0x71dcbc0afac0] yuvj422p [libx265 @ 0x71dcbc0afac0] yuv444p [libx265 @ 0x71dcbc0afac0] yuvj444p [libx265 @ 0x71dcbc0afac0] gbrp [libx265 @ 0x71dcbc0afac0] gray
@Terje Great link to the cheat sheets you mentioned on the forum. Instead of making a new document I can put that link on the manual. https://gist.github.com/dexeonify/ed31c7d85fcf7297719e2ec4740fafda
Well, I loaded a 10-bit Cineform (ffmpeg rendered) file with Cinelerra and was able to render it to the following 10-bit formats (0 content didn't succeed in either version, interested to hear if other get them to work):
du -sh * 3,3G cfhd01.mkv 23M h265-10bit_yuv422p10le_cfhd01.mp4 23M h265-10bit_yuv422p_cfhd01.mp4 17M av1_svt_10bit_yuv420p10le_cfhd01.webm ------didn't work: 0 h264-10bit_yuv422p10le_cfhd01.mp4 0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
Correction: I also got this to work with einander's "8-bit version" 80M h264-10bit_yuv422p10le_cfhd01.mp4
Me too. I have tried various 10-bit codecs with the CinGG(8-bit) version. They all work except x265_10-bit. So that is the only difference between 10-bit and 8-bit CinGG. We would have to do tests to see if there are performance differences with playback (using filters and transitions as well). I will see in the next few days. The codecs used for the test are: DNxHR HQX CineformHD ffv1(10-bit) x264(10-bit) x265(10-bit) NO AVC_Intra(10-bit) ProRes 444 hqx SVT-AV1(10-bit) DPX(10-bit) HDR(32-bit)
I, too, wonder whether einhander binaries are 8-bit or multibit.
I use the default build scripts with a minor changes, so I think it's 8-bit. Should I change 8-bit version to multibit? Or make a separate 8-bit, multibit and 10-bit version? Best regards, Andrey сб, 13 июл. 2024 г., 17:31 Terje J. Hanssen via Cin < [email protected]>:
Den 13.07.2024 13:01, skrev Terje J. Hanssen:
Den 12.07.2024 10:39, skrev Andrea paz:
I, too, wonder whether einhander binaries are 8-bit or multibit.
I did a render test, and it seems to me that this is the 8-bit version. If einander once make a change, I would suggest to put the Cinx Suse version on Slowroll ;)
Note: the 8-bit limitation only affects encoding with 10-bit x265. I have the following error:
[libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not supported by the libx265 encoder. [libx265 @ 0x71dcbc0afac0] Supported pixel formats: [libx265 @ 0x71dcbc0afac0] yuv420p [libx265 @ 0x71dcbc0afac0] yuvj420p [libx265 @ 0x71dcbc0afac0] yuv422p [libx265 @ 0x71dcbc0afac0] yuvj422p [libx265 @ 0x71dcbc0afac0] yuv444p [libx265 @ 0x71dcbc0afac0] yuvj444p [libx265 @ 0x71dcbc0afac0] gbrp [libx265 @ 0x71dcbc0afac0] gray
@Terje Great link to the cheat sheets you mentioned on the forum. Instead of making a new document I can put that link on the manual.https://gist.github.com/dexeonify/ed31c7d85fcf7297719e2ec4740fafda
Well, I loaded a 10-bit Cineform (ffmpeg rendered) file with Cinelerra and was able to render it to the following 10-bit formats (0 content didn't succeed in either version, interested to hear if other get them to work):
du -sh * 3,3G cfhd01.mkv 23M h265-10bit_yuv422p10le_cfhd01.mp4 23M h265-10bit_yuv422p_cfhd01.mp4 17M av1_svt_10bit_yuv420p10le_cfhd01.webm ------didn't work: 0 h264-10bit_yuv422p10le_cfhd01.mp4 0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
Correction: I also got this to work with einander's "8-bit version"
80M h264-10bit_yuv422p10le_cfhd01.mp4
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Let's wait before changing the name. There is a risk that playback on the timeline (which is already problematic in CinGG) will be less efficient. Let me do some more testing and even better would be to do some more with less performing hardware (which I don't have). The confusion involved with the name change could also be problematic. I'd love the opinions of other users as well.
вт, 16 июл. 2024 г., 10:20 Andrea paz via Cin <[email protected]>:
Let's wait before changing the name. There is a risk that playback on the timeline (which is already problematic in CinGG) will be less efficient.
As far as I understand x265 is *encoder* so playback performance should stay roughly the same .... Let me do some more testing and even better would be to do
some more with less performing hardware (which I don't have). The confusion involved with the name change could also be problematic. I'd love the opinions of other users as well. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I thought that the "1 word --> 2 words" speech was also about playback. If it is limited to the encoder then I noticed a small difference (in my tests: 8-bit: 22 fps; multibit: 19 fps)
Den 09.07.2024 01:43, skrev Andrew Randrianasulu:
........
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
Does this mean that the "regular" or basic CinGG version has multibit capability for all encoding (x264 included), except for x265 which has only 8-bit here? And on the other hand, CinGG-Multibit has multibit capability for all encoding (x265 included), except for x264 which has only 8-bit here? Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included? Den 16.07.2024 09:24, skrev Andrew Randrianasulu via Cin:
вт, 16 июл. 2024 г., 10:20 Andrea paz via Cin <[email protected]>:
Let's wait before changing the name. There is a risk that playback on the timeline (which is already problematic in CinGG) will be less efficient.
As far as I understand x265 is *encoder* so playback performance should stay roughly the same ....
Let me do some more testing and even better would be to do some more with less performing hardware (which I don't have). The confusion involved with the name change could also be problematic. I'd love the opinions of other users as well. --
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
And won't it be possible to enable Intel qsv etc. hwaccel support with CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <[email protected]>:
Den 09.07.2024 01:43, skrev Andrew Randrianasulu:
........
well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
Does this mean that the "regular" or basic CinGG version has multibit capability for all encoding (x264 included), except for x265 which has only 8-bit here?
yes, I think .... And on the other hand, CinGG-Multibit has multibit capability for all
encoding (x265 included), except for x264 which has only 8-bit here?
no, x264 should be full featured (8/10 bit) in all variants of cingg compiled with internal x264/ffmpeg ...
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?
this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes. I looked up doom9 forums and it seems even modern CPUs struggle with 4k x265 encoder on slow preset too many pages http://forum.doom9.net/showthread.php?t=176545 "Which processor to encode x265 4K ?" openbenchmarking page https://openbenchmarking.org/test/pts/x265 few systems break 30 fps barrier ....
Den 16.07.2024 09:24, skrev Andrew Randrianasulu via Cin:
вт, 16 июл. 2024 г., 10:20 Andrea paz via Cin <[email protected]
:
Let's wait before changing the name. There is a risk that playback on the timeline (which is already problematic in CinGG) will be less efficient.
As far as I understand x265 is *encoder* so playback performance should stay roughly the same ....
Let me do some more testing and even better would be to do
some more with less performing hardware (which I don't have). The confusion involved with the name change could also be problematic. I'd love the opinions of other users as well. --
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
And won't it be possible to enable Intel qsv etc. hwaccel support with CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <[email protected]>:
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?
this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes.
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
There should also be more 10-bit pixel formats available as extracted from my previous post: https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008407.html cfhd: yuv422p10le gbrp12le gbrap12le libx265: yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le libsvtav1: yuv420p10le av1_qsv: nv12 p010le qsv
And won't it be possible to enable Intel qsv etc. hwaccel support with CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make <http://autogen.sh/configure/make>
I meant pre-build with CinGG. A hwaccel listing from my system ffmpeg: ffmpeg -hide_banner -encoders | grep qsv V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9) ffmpeg -hide_banner -encoders | grep amf V....D av1_amf AMD AMF AV1 encoder (codec av1) V....D h264_amf AMD AMF H.264 Encoder (codec h264) V....D hevc_amf AMD AMF HEVC encoder (codec hevc) ffmpeg -hide_banner -encoders | grep nvenc V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1) V....D h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc) And the ffmpeg banner: ffmpeg version 7.0 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13 (SUSE Linux) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --optflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-gnutls --enable-ladspa --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libjack --enable-libjxl --enable-librist --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopenh264-dlopen --enable-libopus --enable-libpulse --enable-librav1e --enable-librubberband --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-lv2 --enable-libvpl --enable-vaapi --enable-vdpau --enable-version3 --enable-libfdk-aac-dlopen --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libx264 --enable-libx265 --enable-libxvid
вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen <[email protected]>:
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <[email protected]>:
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?
this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes.
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
There should also be more 10-bit pixel formats available as extracted from my previous post: https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008407.html
cfhd: yuv422p10le gbrp12le gbrap12le libx265: yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le libsvtav1: yuv420p10le av1_qsv: nv12 p010le qsv
you tried to set pixel format dropdown menu after choosing preset?
And won't it be possible to enable Intel qsv etc. hwaccel support with
CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make
I meant pre-build with CinGG.
well, problem is, if we compile cingg for whatever new libs for ffmpeg exist - running it on system where such libs are at wrong version may result in weird crashes etc? Appimage helps with some of them, but sadly not with hw-assisted de/encoding ..... Why you are so reluctant to compiling cingg yourself? You have enough cou/memory/hdd space .... Some 20+ years ago I was distrohopping a bit because nearly every single distro was compiling mplayer just slightly wrong. Then I just stopped worrying about distro versions and embrace gcc .... with whole set of deps being that long I think having source copy and poke it from time to time is reasonable? I can't stop whole world from doing this style of development, even if personally I dislike being in focal point of breaking changes from all sides!
A hwaccel listing from my system ffmpeg:
ffmpeg -hide_banner -encoders | grep qsv V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9)
ffmpeg -hide_banner -encoders | grep amf V....D av1_amf AMD AMF AV1 encoder (codec av1) V....D h264_amf AMD AMF H.264 Encoder (codec h264) V....D hevc_amf AMD AMF HEVC encoder (codec hevc)
ffmpeg -hide_banner -encoders | grep nvenc V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1) V....D h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
And the ffmpeg banner:
ffmpeg version 7.0 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13 (SUSE Linux) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --optflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-gnutls --enable-ladspa --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libjack --enable-libjxl --enable-librist --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopenh264-dlopen --enable-libopus --enable-libpulse --enable-librav1e --enable-librubberband --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-lv2 --enable-libvpl --enable-vaapi --enable-vdpau --enable-version3 --enable-libfdk-aac-dlopen --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libx264 --enable-libx265 --enable-libxvid
Den 16.07.2024 13:19, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen <[email protected]>:
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <[email protected]>:
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?
this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes.
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
There should also be more 10-bit pixel formats available as extracted from my previous post: https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008407.html
cfhd: yuv422p10le gbrp12le gbrap12le libx265: yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le libsvtav1: yuv420p10le av1_qsv: nv12 p010le qsv
you tried to set pixel format dropdown menu after choosing preset?
Probably I missed that some preset steps (Compression?) on the Render menu. I found now 10bit more yuv422p10le for x265 and svt, but still not yet for av1_vaapi.
And won't it be possible to enable Intel qsv etc. hwaccel support with CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make <http://autogen.sh/configure/make>
I meant pre-build with CinGG.
well, problem is, if we compile cingg for whatever new libs for ffmpeg exist - running it on system where such libs are at wrong version may result in weird crashes etc? Appimage helps with some of them, but sadly not with hw-assisted de/encoding .....
Why you are so reluctant to compiling cingg yourself? You have enough cou/memory/hdd space ....
Well, actually I had begun to think about it, and might do a second attempt later on (winter work), so this was possibly a kick on the way ;) https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q1/003834.html In the meantime, is there differences between a "System Built" and a "Single User built" with regards to updated procedures and utilizing the system ffmpeg, libs and gpu performance? https://cinelerra-gg.org/download/CinelerraGG_Manual/How_Build_CINELERRA_GG_... I remember a fun anecdote from my first Unix (the) book, 1982 (translated 1985), in the chapter about 'ed' and 'vi'. They referred to inner circle Unix programmers who used to say: "Real hackers do it with ed" 😎
Some 20+ years ago I was distrohopping a bit because nearly every single distro was compiling mplayer just slightly wrong. Then I just stopped worrying about distro versions and embrace gcc ....
with whole set of deps being that long I think having source copy and poke it from time to time is reasonable?
I can't stop whole world from doing this style of development, even if personally I dislike being in focal point of breaking changes from all sides!
A hwaccel listing from my system ffmpeg:
ffmpeg -hide_banner -encoders | grep qsv V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9)
ffmpeg -hide_banner -encoders | grep amf V....D av1_amf AMD AMF AV1 encoder (codec av1) V....D h264_amf AMD AMF H.264 Encoder (codec h264) V....D hevc_amf AMD AMF HEVC encoder (codec hevc)
ffmpeg -hide_banner -encoders | grep nvenc V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1) V....D h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
And the ffmpeg banner:
ffmpeg version 7.0 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13 (SUSE Linux) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --optflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-gnutls --enable-ladspa --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libjack --enable-libjxl --enable-librist --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopenh264-dlopen --enable-libopus --enable-libpulse --enable-librav1e --enable-librubberband --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-lv2 --enable-libvpl --enable-vaapi --enable-vdpau --enable-version3 --enable-libfdk-aac-dlopen --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libx264 --enable-libx265 --enable-libxvid
вт, 16 июл. 2024 г., 17:07 Terje J. Hanssen <[email protected]>:
Den 16.07.2024 13:19, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen <[email protected]>:
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <[email protected]>:
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?
this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes.
I wonder why I didn't get the following encoding formats to work
0 av1_svt_yuv420p_cfhd01.webm 0 av1_vaapi_yuv420p_cfhd01.webm 0 av1_yuv422p10le_cfhd01.webm
There should also be more 10-bit pixel formats available as extracted from my previous post: https://lists.cinelerra-gg.org/pipermail/cin/2024-July/008407.html
cfhd: yuv422p10le gbrp12le gbrap12le libx265: yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le libsvtav1: yuv420p10le av1_qsv: nv12 p010le qsv
you tried to set pixel format dropdown menu after choosing preset?
Probably I missed that some preset steps (Compression?) on the Render menu. I found now 10bit more yuv422p10le for x265 and svt, but still not yet for av1_vaapi.
And won't it be possible to enable Intel qsv etc. hwaccel support with
CinGG's "internal ffmpeg", when it is available for my system ffmpeg?
in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make
I meant pre-build with CinGG.
well, problem is, if we compile cingg for whatever new libs for ffmpeg exist - running it on system where such libs are at wrong version may result in weird crashes etc? Appimage helps with some of them, but sadly not with hw-assisted de/encoding .....
Why you are so reluctant to compiling cingg yourself? You have enough cou/memory/hdd space ....
Well, actually I had begun to think about it, and might do a second attempt later on (winter work), so this was possibly a kick on the way ;) https://lists.cinelerra-cv.org/pipermail/cinelerra/2016q1/003834.html
In the meantime, is there differences between a "System Built" and a "Single User built" with regards to updated procedures and utilizing the system ffmpeg, libs and gpu performance?
"single user" means you can (and should) run it from directory 'bin' that appear in your cinelerra-5.1 directory after successful build. System (dynamic) build mean you disable thirdparty components (including ffmpeg) and resulting binary and plugins should be installed system-wide (for example in /usr/local ) You can make "single user build" with "system components" by adding both switches: ./configure --with-single-user --without-thirdparty but system-wide installed ffmpeg should be at compatible version (just in case you install some either new or too old ffmpeg/libavcodec). On systems where few ffmpegs installed you may need to figure out where exactly relevant libav* libs installed, and then add some CFLAGS/LDFLAGS before compilation. You can look at blds/bsd.bld and bld/netbsd.bld for some examples. not sure how suse handles this. you probably can look at ldd /usr/bin/ffmpeg to see where libs installed. Or query rpm database about specific packages https://cinelerra-gg.org/download/CinelerraGG_Manual/How_Build_CINELERRA_GG_...
I remember a fun anecdote from my first Unix (the) book, 1982 (translated 1985), in the chapter about 'ed' and 'vi'. They referred to inner circle Unix programmers who used to say: "Real hackers do it with ed" 😎
well, I do not think you can use vi with teletype :) but of course I never tried ed ....
Some 20+ years ago I was distrohopping a bit because nearly every single distro was compiling mplayer just slightly wrong. Then I just stopped worrying about distro versions and embrace gcc ....
with whole set of deps being that long I think having source copy and poke it from time to time is reasonable?
I can't stop whole world from doing this style of development, even if personally I dislike being in focal point of breaking changes from all sides!
A hwaccel listing from my system ffmpeg:
ffmpeg -hide_banner -encoders | grep qsv V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9)
ffmpeg -hide_banner -encoders | grep amf V....D av1_amf AMD AMF AV1 encoder (codec av1) V....D h264_amf AMD AMF H.264 Encoder (codec h264) V....D hevc_amf AMD AMF HEVC encoder (codec hevc)
ffmpeg -hide_banner -encoders | grep nvenc V....D av1_nvenc NVIDIA NVENC av1 encoder (codec av1) V....D h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) V....D hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
And the ffmpeg banner:
ffmpeg version 7.0 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13 (SUSE Linux) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include/ffmpeg --extra-cflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --optflags='-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -g' --disable-htmlpages --enable-pic --disable-stripping --enable-shared --disable-static --enable-gpl --enable-version3 --enable-libsmbclient --disable-openssl --enable-gnutls --enable-ladspa --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdc1394 --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libjack --enable-libjxl --enable-librist --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopenh264-dlopen --enable-libopus --enable-libpulse --enable-librav1e --enable-librubberband --enable-libsvtav1 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lto --enable-lv2 --enable-libvpl --enable-vaapi --enable-vdpau --enable-version3 --enable-libfdk-aac-dlopen --enable-nonfree --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libx264 --enable-libx265 --enable-libxvid
Den 16.07.2024 04:51, skrev Андрей Спицын via Cin:
I, too, wonder whether einhander binaries are 8-bit or multibit.
I use the default build scripts with a minor changes, so I think it's 8-bit. Should I change 8-bit version to multibit? Or make a separate 8-bit, multibit and 10-bit version?
Best regards, Andrey
сб, 13 июл. 2024 г., 17:31 Terje J. Hanssen via Cin <[email protected]>:
Den 13.07.2024 13:01, skrev Terje J. Hanssen:
Den 12.07.2024 10:39, skrev Andrea paz:
I, too, wonder whether einhander binaries are 8-bit or multibit.
I did a render test, and it seems to me that this is the 8-bit version. If einander once make a change, I would suggest to put the Cinx Suse version on Slowroll ;)
@Andrey If I understand Phyllis's last post, the default version will get x265 addition of 10 and 12 bit. For me on openSUSE Leap and Slowroll x86_64, this will be the only version I use. Slowroll plus adding the community repo "All of Packman" (not only the Essentials) provide the latest ffmpeg-7, vlc etc. with enabled multimedia libs and codecs. 😉 https://en.opensuse.org/openSUSE:Slowroll https://ftp.fau.de/packman//suse/openSUSE_Slowroll/
Andrea has convinced me that the x265 addition of 10 and 12 bit should be the default (i.e. the compile_multibit_X265.patch automatically in effect). I have now run tests on an older operating system, ubuntu 16, and an older 32-bit 9.1debian system, with no problems. The compile time may be longer and the cin binary is definitely larger, but the X265 8-bit is still an option so there is no loss. I concur that einhander binary is not the multibit version as verified by Terje (tested on Fedora 39). On Fri, Jul 12, 2024 at 2:39 AM Andrea paz <[email protected]> wrote:
I, too, wonder whether einhander binaries are 8-bit or multibit. The underlying theme is that, normally, video editing involves powerful hardware and, I think, the majority have it. However, it is also true that CinGG is suitable for non-powerful hardware and it could be that the majority of its users have dated hardware. A survey of the PCs that CinGG users have would be interesting.
We do not have much feedback when doing surveys.
One possible idea (not important, surely it is better to leave everything as it is now) could be to change the current default (8-bit) to multibit, for example:
So based on Andrea's work and explanation, I will add the 3 patches to GIT so they will be in the source code going forward and get built. It should not be a problem, but if a problem arises, we can handle it accordingly. This means that there will no longer be CinGG-20yymmdd-x86_64-multibit.AppImage from now on. I hope that does not confuse anyone who is used to downloading that version, but it will be noted in the Release Notes and the next News on the website. Not sure if we should remove "multibit" from CinGG-20240630-x86_64-older-distros-multibit.AppImage. Any opinion on that? I would be easier for me to type. And if anyone, for example "me", wants to compile faster they can just delete x265xxx.patch1, x265xxx.patch2, and x265xxx.patch3 in the thirdparty/src directory. (It takes 13 minutes to do a full build without the patches and 21 minutes with them on my laptop.)
Note: the 8-bit limitation only affects encoding with 10-bit x265. I have the following error:
Besides x265 10-bit, 12-bit x265 encoding also errors out on the current default version.
[libx265 @ 0x71dcbc0afac0] Specified pixel format yuv422p10le is not supported by the libx265 encoder. ...
I believe that compiling x265 with the 3 patches just makes it possible to encode 8-bit as usual, as well as the additional encode possibilities of 10-bit and 12-bit. *That is all that is affected *with what we have just been calling "multibit", i.e.: 1. encode ONLY 2. x265 ONLY 3. 8-bit basically the same as without the patches 4. 10-bit and 12-bit additional options for encoding These particular patches were provided by Andrew-R who most likely located the possibility from information found on the internet and created the modset as required specifically for CinGG. *CinX *build was based on a previous and totally different change. In February 2018, per the release notes, x265 had 10-bit incorporated into the code so a special 10-bit version was no longer needed. It can be deleted from the Manual. *Andrey*, I was just going to checkin the 3 patches so that you will not have to do anything different in your builds but since there was so much feedback, I will re-read all of it, do some more tests, and hopefully still check them in a little later. *Tests* - Andrea reported: If it is limited to the encoder then I noticed a small difference (in my tests: 8-bit: 22 fps; multibit: 19 fps). - My results mirror Andrea's. A simple low resolution 1 minute/31 second video when encoded using the regular just 8-bit x265 version had an fps of 112.831 / 104.545 / 113.859 in 3 separate runs.That same video when encoded using the multibit compiled version 8-bit render format had an fps of 114.026 / 112.817 in 2 separate runs. - Results rendering a 4K video (this 1 had no audio) that was a little over 2 minutes were fps=2.757 on the 8-bit compiled version and fps=2.762 on the multibit compiled version. Basically no difference.
Checked into GIT the 3 patches for x265 encode addition of 10 and 12 bit. Einhander packages are partway through the build at: https://github.com/einhander/cin-gg-packages/releases I had to fix my mistake of accidentally forgetting to check in the thirdparty/Makefile at the same time so this slowed things down. On Tue, Jul 16, 2024 at 2:06 PM Phyllis Smith <[email protected]> wrote:
I believe that compiling x265 with the 3 patches just makes it possible to encode 8-bit as usual, as well as the additional encode possibilities of 10-bit and 12-bit. *That is all that is affected *with what we have just been calling "multibit", i.e.: 1. encode ONLY 2. x265 ONLY 3. 8-bit basically the same as without the patches 4. 10-bit and 12-bit additional options for encoding These particular patches were provided by Andrew-R who most likely located the possibility from information found on the internet and created the modset as required specifically for CinGG.
I will change the manual. A few questions: 1- how to do if you want to compile the 8-bit version? 2- Do the appimages reverse their names? multibit --> new std; old std --> 8-bit? 3- Will the einhander repository continue to have only the std version (which will be the multibit from now on)?
Andrea, a few answers below. This just seems confusing, but we should have done this initially when Andrew-R supplied the patch. 1- how to do if you want to compile the 8-bit version?
I would change the section "Multibit build for x265-8/10/12-bit" to note how to compile the 8-bit only version. Although I really do not think anyone would bother to do this. - cd /path_to/cinelerra-5.1/thirdparty - edit the file "Makefile" using the # character at the beginning, comment out the line: x265.cfg_vars?=chmod +x ./configure; chmod +x ./multilib.sh; - then the next 2 lines should be uncommented, that is remove the # sign at the beginning #x265.cfg_vars?=$(call cmake_config,source) #x265.cfg_params?= -DENABLE_SHARED=no -DENABLE_CLI=no - delete or rename the 3 patch files in thirdparty/src (they will be something like x265-xxxxx.patchx)
2- Do the appimages reverse their names? multibit --> new std; old std --> 8-bit?
The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary. I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion. Also, while you are at it, could you update the date on this appimage names? so CinGG-20230131... would be CinGG-20240630, etc. just so more up to date.
3- Will the einhander repository continue to have only the std version (which will be the multibit from now on)?
Yes, einhander version should now be automatically built as the multibit version because he uses the GIT checkin. Also, please delete any references to CinX in the manual as it is irrelevant.
The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary. I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion.
2- Maybe I didn't understand correctly. Do you intend to rename all the 2023/24 appimages, removing the word multibit, and deleting the 8-bit ones? Will only the "older-distros" be left untouched? And the "i386" versions are all 8-bit? I will change the dates from 20230131 to 20240630 in the manual; however, I need the following data: Fedora 29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version of 2024? Question to developers on 8-bit / multibit: I can't find anywhere instructions on how to compile system ffmpeg with 10-bit x265. Is it not that, as std, in ffmpeg all bit-depths are compiled and it is only in CinGG that there is something that prevents this, reducing the compilation to 8-bit only (thus making the 3 patches necessary)? In fact, my system ffmpeg has support for all bit-depths; why doesn't CinGG's ffmpeg (without patches)? In short, if this impediment is found, there would be no more need for the 3 patches and also the compile time would not double (it almost seems like it builds to 8-bit and then overlays a new 10-bit build on top of it).
Andrea, sorry for the confusion. See below. 2- Maybe I didn't understand correctly. Do you intend to rename all
the 2023/24 appimages, removing the word multibit, and deleting the 8-bit ones? Will only the "older-distros" be left untouched? And the "i386" versions are all 8-bit? I will change the dates from 20230131 to 20240630 in the manual; however, I need the following data: Fedora 29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version of 2024?
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change. Only CinGG-20230131-x86_64-multibit.AppImage will be eliminated. Nothing should change in the following except the date and elimination of the 1 named in the previous sentence. We do not even need to note in the Manual that these are now multibit -- it is just like any other modification we make that is just noted in the Release Notes. I still create the appimages on those older Operating Systems of Fedora, Debian, and Ubuntu. CinGG-20240630-x86_64.AppImage
(currently based on Fedora 32, linux kernel 5.8.15, libc version 2.31)CinGG-20230131-x86_64-older-distros.AppImage (currently based on Ubuntu 16.04, libc version 2.23) CinGG-20240630-i686.AppImage (currently based on Debian 9, linux kernel 4.9, use "newer" for Debian 11.0) CinGG-20240630-i686-newer-distros.AppImage (currently based on Debian 11, linux kernel 5.10) CinGG-20240630-x86_64-multibit.AppImage (currently based on Fedora 32, libc version 2.31) CinGG-20240630-x86_64-older-distros-multibit.AppImage (currently based on Fedora 29 -runs on RHEL8 -linux kernel 4.19.9, libc version
→ 2.28)
CinGG-20240630-alternative_shortcuts.AppImage (currently based on Ubuntu 16.04, libc version 2.23)
Question to developers on 8-bit / multibit: I can't find anywhere instructions on how to compile system ffmpeg with 10-bit x265. Is it not that, as std, in ffmpeg all bit-depths are compiled and it is only in CinGG that there is something that prevents this, reducing the compilation to 8-bit only (thus making the 3 patches necessary)? In fact, my system ffmpeg has support for all bit-depths; why doesn't CinGG's ffmpeg (without patches)? In short, if this impediment is found, there would be no more need for the 3 patches and also the compile time would not double (it almost seems like it builds to 8-bit and then overlays a new 10-bit build on top of it).
About the increased build time, I think it is due to not being able to parallel build 8-bit, 10-bit, and 12-bit x265 so that they have to be built sequentially -- usually "The build rule set of dependencies allows for compiling multiple thirdparty programs simultaneously using maximum computer resources. This parallel build speeds up the process considerably."
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le Any idea why not? 1) With einander current rpm cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished. 2) With current Multibit Appimage ./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished. I did a succesful rendering July 13 (as also mentioned before ): ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
вс, 21 июл. 2024 г., 22:04 Terje J. Hanssen via Cin < [email protected]>:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
well, may be this combination of parameters simply not allowed by spec? try to look into ffmpeg/video/AVC_Intra_100.mp4 and try to set high10-422 profile?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, you are right! Guess we should actually "read" the error message of "high10 profile doesn't support 4:2:2". Terje, it should be profile=high422 although it seems to work without listing it. You can read all about this in the "Profile" section at - https://trac.ffmpeg.org/wiki/Encode/H.264 On Sun, Jul 21, 2024 at 2:10 PM Andrew Randrianasulu < [email protected]> wrote:
вс, 21 июл. 2024 г., 22:04 Terje J. Hanssen via Cin < [email protected]>:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
well, may be this combination of parameters simply not allowed by spec?
try to look into
ffmpeg/video/AVC_Intra_100.mp4
and try to set high10-422 profile?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Terje, there is a conflict between ALL of the parameters. If I am not mistaken, you can get the results you want by choosing h264-10bit.mp4, change the down arrow of pixels to yuvp42210le AND most importantly in the text box delete all 5 lines (maybe some can be put back, but I did not experiment with them). Let us know if this does or does not work correctly. On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen <[email protected]> wrote:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
Terje, the conflict is "profile=high10". Interestingly cin_pix_fmt=yuv420p10le conflicting with the choice for the Pixels: box of yuv422p10le does not matter. It must override that. So, just deleting the line "profile-high10" in the text box, seems to work for me. Please confirm. On Sun, Jul 21, 2024 at 2:54 PM Phyllis Smith <[email protected]> wrote:
Terje, there is a conflict between ALL of the parameters. If I am not mistaken, you can get the results you want by choosing h264-10bit.mp4, change the down arrow of pixels to yuvp42210le AND most importantly in the text box delete all 5 lines (maybe some can be put back, but I did not experiment with them). Let us know if this does or does not work correctly.
On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen <[email protected]> wrote:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen <[email protected]> wrote:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
@Andrew, @Phyllis, I've found the explanation: As seen in my last section from the previous successful rendering above: Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, That is the profile used was indeed h264 (High 4:2:2) or "high422" as supported by FFmpeg. That is not "high10" as CinGG reports in the Error message.. I have also been able to reconstruct the successful procedure and result again using Video wrench: compression: h264.mp4, pixels: yuv422p10le IMO the need to use "h264.mp4" here instead of "h264-10bit.mp4" is confusing, because "yuv422p10le" is 10-bit. So my question is if not also "high422" should be placed among "h264-10bit" compression instead?
When I read ffmepg Profile section, it stated "The -profile:v option limits the output to a specific H.264 profile. You usually do not need to use this option and the r*ecommendation is to omit setting the profile* which will allow x264 to automatically select the appropriate profile. So I will eliminate the "profile=high10" from the h264-10bit.mp4 format and then it will work. On Sun, Jul 21, 2024 at 3:58 PM Terje J. Hanssen <[email protected]> wrote:
On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen <[email protected]>
wrote:
On 18.07.2024 23:45, Phyllis Smith wrote:
ALL appimages will now be multibit just as if we had checked these patches into GIT originally. None will be only 8-bit and no names will change.
I did a new test with the current package and Appimage state on openSUSE Leap, but I didn't succed to render to h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench: compression: h264-10bit.mp4, pixels: yuv422p10le
Any idea why not?
1) With einander current rpm
cin Cinelerra Infinity - built: Jul 18 2024 03:04:48 ...... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f09519d9740] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
2) With current Multibit Appimage
./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage Cinelerra Infinity - built: Jun 30 2024 08:31:40 ........... x264 [error]: high10 profile doesn't support 4:2:2 [libx264 @ 0x7f0f1c021100] Error setting profile high10. FFMPEG::open_encoder err: Invalid argument int FFMPEG::open_encoder(const char*, const char*): open failed libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4 Render::render_single: Session finished.
I did a succesful rendering July 13 (as also mentioned before ):
ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'h264-10bit_yuv422p10le_cfhd01.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.1.100 Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown, top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25 fps, 25 tbr, 12800 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0]
@Andrew, @Phyllis,
I've found the explanation:
As seen in my last section from the previous successful rendering above:
Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p10le(pc,
That is the profile used was indeed h264 (High 4:2:2) or "high422" as supported by FFmpeg. That is not "high10" as CinGG reports in the Error message..
I have also been able to reconstruct the successful procedure and result again using
Video wrench: compression: h264.mp4, pixels: yuv422p10le
IMO the need to use "h264.mp4" here instead of "h264-10bit.mp4" is confusing, because "yuv422p10le" is 10-bit. So my question is if not also "high422" should be placed among "h264-10bit" compression instead?
On 22.07.2024 01:23, Phyllis Smith wrote:
When I read ffmepg Profile section, it stated "The |-profile:v| option limits the output to a specific H.264 profile. You usually do not need to use this option and the r*ecommendation is to omit setting the profile* which will allow x264 to automatically select the appropriate profile. So I will eliminate the "profile=high10" from the h264-10bit.mp4 format and then it will work.
If I understand this right, you'll remove the "h264-10bit.mp4" entry from the Compression drop-down menu, and keep only the "h264.entry", which works for all h264 pixel formats (?)
No, I was planning on leaving both formats for now (unless Andrew-R suggests otherwise) and just remove the profile line from h264-10bit.mp4. On Sun, Jul 21, 2024 at 5:47 PM Terje J. Hanssen <[email protected]> wrote:
On 22.07.2024 01:23, Phyllis Smith wrote:
When I read ffmepg Profile section, it stated "The -profile:v option limits the output to a specific H.264 profile. You usually do not need to use this option and the r*ecommendation is to omit setting the profile* which will allow x264 to automatically select the appropriate profile. So I will eliminate the "profile=high10" from the h264-10bit.mp4 format and then it will work.
If I understand this right, you'll remove the "h264-10bit.mp4" entry from the Compression drop-down menu, and keep only the "h264.entry", which works for all h264 pixel formats (?)
пн, 22 июл. 2024 г., 03:53 Phyllis Smith via Cin <[email protected]
:
No, I was planning on leaving both formats for now (unless Andrew-R suggests otherwise) and just remove the profile line from h264-10bit.mp4.
May be I am too conservative, but I'd just commented out (with #) this profile line? They all should be settable via options window, but sometimes even 1 additional step is one action too much ....
On Sun, Jul 21, 2024 at 5:47 PM Terje J. Hanssen <[email protected]> wrote:
On 22.07.2024 01:23, Phyllis Smith wrote:
When I read ffmepg Profile section, it stated "The -profile:v option limits the output to a specific H.264 profile. You usually do not need to use this option and the r*ecommendation is to omit setting the profile* which will allow x264 to automatically select the appropriate profile. So I will eliminate the "profile=high10" from the h264-10bit.mp4 format and then it will work.
If I understand this right, you'll remove the "h264-10bit.mp4" entry from the Compression drop-down menu, and keep only the "h264.entry", which works for all h264 pixel formats (?)
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
чт, 18 июл. 2024 г., 23:44 Andrea paz via Cin <[email protected]>:
The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary. I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion.
2- Maybe I didn't understand correctly. Do you intend to rename all the 2023/24 appimages, removing the word multibit, and deleting the 8-bit ones? Will only the "older-distros" be left untouched? And the "i386" versions are all 8-bit? I will change the dates from 20230131 to 20240630 in the manual; however, I need the following data: Fedora 29/32; Ubuntu 16.04 and Debian 9/11 are changed in the latest version of 2024?
Question to developers on 8-bit / multibit: I can't find anywhere instructions on how to compile system ffmpeg with 10-bit x265.
I think at least on Arch linux x265 build all-bit-depth systemwide: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=x265-mod-patman-git may be you can add "--disable-x265" switch to main cingg configure then add -lx265 to ldflags and "--enable-libx265" to FFMPEG_EXTRA_CFG ? Is it
not that, as std, in ffmpeg all bit-depths are compiled and it is only in CinGG that there is something that prevents this, reducing the compilation to 8-bit only (thus making the 3 patches necessary)? In fact, my system ffmpeg has support for all bit-depths; why doesn't CinGG's ffmpeg (without patches)? In short, if this impediment is found, there would be no more need for the 3 patches and also the compile time would not double (it almost seems like it builds to 8-bit and then overlays a new 10-bit build on top of it). -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith -
Terje J. Hanssen -
Андрей Спицын