пн, 22 июл. 2024 г., 03:53 Phyllis Smith via Cin :
> 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 shou
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
wrote:
>
>
> On 22.07.2024 01:23, Phyllis Smith wrote:
>
> When I read ffmepg Profile section, it stated
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 automatic
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
el
On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen
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.
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.26
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 2
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
вс, 21 июл. 2024 г., 22:04 Terje J. Hanssen via Cin <
cin@lists.cinelerra-gg.org>:
>
> 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
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 r
чт, 18 июл. 2024 г., 23:44 Andrea paz via Cin :
> > 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 seem
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 cha
> 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-20230
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.
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)?
--
Ci
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 slo
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 basi
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 versio
вт, 16 июл. 2024 г., 17:07 Terje J. Hanssen :
>
>
> Den 16.07.2024 13:19, skrev Andrew Randrianasulu:
>
>
>
> вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen :
>
>>
>>
>> Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
>>
>>
>> вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen :
>>
>>
>>> Does this also m
Den 16.07.2024 13:19, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen :
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen
:
Does this also mean that it is not possible to make a
"smart", com
вт, 16 июл. 2024 г., 13:30 Terje J. Hanssen :
>
>
> Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
>
>
> вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen :
>
>
>> Does this also mean that it is not possible to make a "smart", common
>> CinGG version that has multibit capability for all encoding, x26
Den 16.07.2024 11:46, skrev Andrew Randrianasulu:
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen :
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 *-m
вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen :
> 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'l
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
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)
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
вт, 16 июл. 2024 г., 10:20 Andrea paz via 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.
As far as I understand x265 is *encoder* so playback performance should
stay roughly the same .
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
> 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
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 longe
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 w
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 Sus
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 limi
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 us
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 ffmpe
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 R
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.
Cinefor
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 Format
> 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
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
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?
-
ср, 10 июл. 2024 г., 14:46 Andrea paz :
> @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 o
@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 i
ср, 10 июл. 2024 г., 01:45 Terje J. Hanssen :
>
>
> 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 shoul
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 .
>
>
>> 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 w
вт, 9 июл. 2024 г., 02:35 Terje J. Hanssen via Cin <
cin@lists.cinelerra-gg.org>:
>
> 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.
>
> Bu
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 an
47 matches
Mail list logo
