GG has already stated that it does not know color management. The hope is to find someone who knows how to do it.
I would say that there are two fixed points:
1) CinGG works internally in sRGB, so you have to set the monitor in sRGB.
2) If we use a video with YUV signal we have to set the project in YUV or transcode it as we want. Otherwise we will get darker images that distort the color correction (Mag). Using RGB-Float on a YUV signal should not lead to alterations, but I find them the same as if it were a simple 8-bit RGB.
@GG/Phyllis
Last thing: I found a blog that speaks in a simple and comprehensive way of transcoding between codecs (focus on DNxHR) whit FFmpeg:
https://dovidenko.com/2019/999/ffmpeg-dnxhd-dnxhr-mxf-proxies-and-optimized-media.html
I almost try to study and maybe pull out some presets for the Avid format. But I need to know if you can implement the .mxf container; Phyllis/GG is it proprietary?
Done, same link.
I'm sorry, I'm stupid enough to think you wanted separate paragraphs. So I left them even though I would have preferred a single paragraph 🙁
I think it's best you write whatever comes to mind and wait for a bug report. Then the notifier is obliged to provide the conclusive and verifiable proof and you can use that for the manual. \(^_^)/
I just retranslated CGG from the Git and now get the error message with the given pixel_format "yuv420p10" (10 bit):
> libx265 Specified pixel format yuv420p10le is invalid or not supported.
Seriously guys, after all this time and the hints on the subject?
@Olaf
My fault; I forgot that to encode in x265 at 10 bit you need CinX.
I change the section by changing the pixel_format to yuv420p. Is that okay with you?
And why is CinX necessary, @andreapaz? libx265 supports all bit depths at the same time. I simply delete the current CGG and replace it with the previous one from August 9th. It's just stupid that this fiddling has an effect on the profile from above.
Really? I admit I don't understand anything about it. I had stayed at the decoding of x265 10-bit man does not encode: chapter 2.4 of the Manual and:
https://www.cinelerra-gg.org/forum/help-video/uhd-and-10-bit/
Really. Your FFmpeg/x265 from the distribution probably supports all bit depths, without the need for an additional FFmpeg/x265.
I don't have time for the manual right now, I'm busy with further training
😉
It is unfortunate that I have to learn from the mailing archive that the x265 8bit+10bit+12bit problem is not understood by the developers. As I have already written elsewhere, I don't think that tearing apart the communication about the development is conducive. I cannot answer here, to questions that are asked there. That goes without saying.
Andrea asked if it would be ok to adjust the profile for his manual accordingly. Andrea, it is your manual and therefore your decision. In case of doubt the profile must be executable in any case. Via the Render menu the user can determine the existing profiles himself, this fixed specification is only an "shortcut".
However, I will not change the profile here after careful consideration. After all, it is my profile that I have presented here, in the hope of introducing a thread of user profiles, discussing it and working on improvements if necessary.
@all
We have therefore divided the communication channels so that the simple user does not have to deal with technical details of programming Cinellera. The original idea was to create a separate channel for each Cinelerra target group.
The forum was to become a user-oriented platform. Simple users who are not too technically versed should have their home there. They should not be bombarded with such profound technical questions. They should also not be overwhelmed if many new entries come. The predominant content of this user-oriented channel should have exactly such content. Here he should have the opportunity to exchange non-technical content, such as artistic aspects of his video production. Users should be able to answer questions from users without having to have a lot of technical background.
The bugtracker should really be used to report bugs. This content should not be posted in the forum. Why should a new user see content from bugs fixed several months ago? That doesn't make sense. That's why we split the forum and bugtracker.
The mailing list is for professionals only, so you can communicate directly with the developers and the other professionals. This has the advantage that the simple user has little contact with it and can concentrate on using Cinelerra and does not have to worry about the further development of Cinelerra. Here people with a lot of technical background can exchange their information.
It also has the advantage that from SEO's point of view the forum is not loaded with unnecessary information and you won't be able to find your way around in one or two years because it is loaded with a lot of technical stuff, which is no longer up-to-date. The mailing list, for example, is hardly indexed by search engines, where it is often indexed against the forum.
Originally I wanted to deactivate the mailing list, but I have gone away from the idea, because I see an advantage by this division of the channels. If there's a better idea, I'm happy to talk about it. Nevertheless, our goal is to give simple and professional users a home.
Another important point. The developers simply can't know everything because of the many possibilities and great complexity of video production programming. Even if there is a desire to improve things, they can be discussed on the mailing list or as a feature request (or in the future through another channel). Even the great Linux guru Linus Torvalds doesn't know everything about the Linux kernel, but has to outsource tasks and knowledge on several shoulders.
Here the condition is always to communicate with respect. The developers are not obliged to do anything. Harsh criticism will not motivate anybody, but on the contrary will contribute to this topic not being tackled. The developers have never refused a friendly request and then they try even harder to help the user. These statements are not in any way a criticism, but simply a small reminder how it is probably better to deal with problems about Cinelerra. But please keep in mind that it just takes time, because the to-do list is getting longer and longer and therefore some requests need their time. What is useful is to remind the developers of certain requests from time to time.
As I said, I'm very open to talking about the channels. Maybe there is something better than the mailing list. I welcome everyone to make suggestions at this point.
@all
We have therefore divided the communication channels so that the simple user does not have to deal with technical details of programming Cinellera. The original idea was to create a separate channel for each Cinelerra target group. […]
You mean people like Andrea, you and me? Our names at least are not to be found among the programmers of GG’s Cinelerra. Again to explain, I have presented a profile that doesn't work anymore because of the conditions. This is not the first time this problem has occurred and the experienced readers of the mailing lists should know this. But it is important that the readers of this thread know this and don't have to find it out themselves.
Enjoy!
In my eyes, you are professional users. Your knowledge about video editing goes far beyond normal knowledge and I would say that you are an expert in this field.
Although we are not programmers, we always provide good information and contribute significantly to improving Cinelerra. Also such hints as you described in this post are very valuable.
But in my opinion this is a bug. If the profile worked fine before and not now, then it's a bug. So it would certainly be good to open a ticket. Such problems actually belong in the developer's corner.
The fact that such errors creep in is not surprising with which high speed Cinelerra is developed. The program is already very complex and gets more and more complex. Such errors will appear again and again in the future, despite the intention to avoid it. Such errors do not occur intentionally, but simply because of the complexity of the software.
I think it's good that you mention this problem here. But to keep it in mind, I think a bugtracker ticket would be better in the long run.
Olaf quote ' I have presented a profile that doesn't work anymore because of the conditions'
Works the same on my laptop running Fedora 29 on August 31, 2019 as it did on July 23 as you can see from this demo:
The error message is AND WAS "libx265 Specified pixel format yuv420p10le is invalid or not supported." You can see in the render Preset Video menu, the supported pixel formats by clicking on the down arrow to the right of the word "Pixels". The supported pixel formats list comes directly from FFmpeg and on either day, yuv420p10le is not listed.
If you compile Cinelerra with libx265, i.e. "The third-party library used for x265 must be specially compiled with --bit-depth=10 in order to produce 10-bit rendered output." to create what I am calling "CinX" then the yuv420p10le format is available. This was re-verified here today. So I stand by the information as quoted from the manual and I believe I have shown in my video that no change was made after August that made it so the profile "doesn't work any more".
There is no bug as far as I can tell from the information provided. If a different time stamp for a difference becomes available of a definitive problem with proof positive with sufficient information to reliably produce a problem, I will analyze that.
@Olaf
I keep posting here because I think you didn't subscribe to the mailing list.
I made the change in yuv420p in the manual, at least until I clarify myself the correct operation.
PS: Did you make any of the vimeo videos you posted? I'd be curious to see that. 🙂
