Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-13 Thread Andrew Randrianasulu via Cin 
On Saturday, November 13, 2021, Terje J. Hanssen 
wrote:

>
>
> Den 13.11.2021 17:45, skrev Andrew Randrianasulu:
>
>
> 
>>
>>
>>
>>> (Another one for "home-made HD videos" on Blu-ray discs (BDAV):
>>> Will it be possible to record (copy) source 1080iHDV.m2t files
>>> (video and audio) to the BD-R(E) discs?)
>>>
>>>
>>>
>>> I was thinking about integrating tsMuxer but this does not solve problem
>>> about unavailability of pre-encoded packets in cin's vframe for mpeg2..
>>> Probably BC_COMPRESSED  type should be split for mjpeg/dv/mpeg2/h264 types
>>> but this is larger rework than I can attempt from tablet ...
>>>
>>>
>>> If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray
>> for burning on BD-RE disk (and DVD-R), this could make it possible to
>> preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) streams
>> content on the same disc, as described in these papers:
>>
>> Blu-ray Disc, Rewritable Format, Audio Visual Application Format
>> Specifications for BD-RE Version 2.1, March 2008:
>> Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV
>> directory
>> http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Par
>> t3_V2.1_WhitePaper_080406-15271.pdf
>>
>> Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016.
>> ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1.
>> V2.0. BDMV.
>> http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf
>
>
>
> well, if you have player (or friend(s) with player(s)) you can try for
> yourself
>
> https://github.com/justdan96/tsMuxer/commits/master
>
> i think they have pre-compiled version. Be aware in tsmuxer context DV
> usually mean Dolby Vision, not dv as dv video codec.
>
>>
>>
> I downloaded and unpacked an appimage, but could not see BDAV mentioned.
> Have you seen any good user examples for tsMuxer?
>
>
> Terje J. H
>
>
if (qt5) gui works for you you can try following
https://elatom.com/software/tsmuxergui-software-for-ts-muxing-with-mpeg-hevc-uhd-support

 pure cmd line use a bit more involved

from githab page

---
Syntax
The following lines form a list of tracks and their parameters. The format
is as follows: , , . Parameters are
separated with commas, with each parameter consisting of a name and a
value, separated with an equals sign. Example of META file:

MUXOPT --blu-ray
V_MPEG4/ISO/AVC, D:/media/test/stream.h264, fps=25
A_AC3, D:/media/test/stream.ac3, timeshift=-1ms

In this example one AC3 audio stream and one H264 video stream are
multiplexed into BD disc. The input file name can reference an elementary
stream or a track located inside a container.

Supported input containers:

TS/M2TS/MTS
EVO/VOB/MPG/MPEG
MKV
MOV/MP4
MPLS (Blu-ray media play list file)

Names of codecs in the meta file:

Meta File Code Description
V_MPEGI/ISO/VVC H.266/VVC
V_MPEGH/ISO/HEVC H.265/HEVC
V_MPEG4/ISO/AVC H.264/AVC
V_MPEG4/ISO/MVC H.264/MVC
V_MS/VFW/WVC1 VC1
V_MPEG-2 MPEG2
A_AC3 AC3/AC3+/TRUE-HD
A_AAC AAC
A_DTS DTS/DTS-Express/DTS-HD
A_MP3 MPEG audio layer 1/2/3
A_LPCM raw pcm data or PCM WAV file
S_HDMV/PGS Presentation graphic stream (BD subtitle format)
S_TEXT/UTF8 SRT subtitle format. Encoding MUST be UTF-8/UTF-16/UTF-32
Each track may have additional parameters. Track parameters do not have
dashes. If a parameter's value consists of several words, it must be
enclosed in quotes.

---

from old firum thread

https://forum.doom9.org/archive/index.php/t-142559.html
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-13 Thread Terje J. Hanssen via Cin 



Den 13.11.2021 17:45, skrev Andrew Randrianasulu:






    (Another one for "home-made HD videos" on Blu-ray discs
(BDAV):
    Will it be possible to record (copy) source 1080iHDV.m2t files
    (video and audio) to the BD-R(E) discs?)



I was thinking about integrating tsMuxer but this does not
solve problem about unavailability of pre-encoded packets in
cin's vframe for mpeg2.. Probably BC_COMPRESSED  type should
be split for mjpeg/dv/mpeg2/h264 types but this is larger
rework than I can attempt from tablet ...


If tsMuxer (or another dedicated utility) could author a BDAV
Blu-Ray for burning on BD-RE disk (and DVD-R), this could make it
possible to preserve and test playabilty compliance of DV SD and
MPEG-2 HD(V) streams content on the same disc, as described in
these papers:

Blu-ray Disc, Rewritable Format, Audio Visual Application Format
Specifications for BD-RE Version 2.1, March 2008:
Figure 3.1.4.2.3: Stream file and Clip Information file for DV in
BDAV directory

http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Part3_V2.1_WhitePaper_080406-15271.pdf



Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December
2016. ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2.
V2.0. ROM. Part1. V2.0. BDMV.
http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf




well, if you have player (or friend(s) with player(s)) you can try for 
yourself


https://github.com/justdan96/tsMuxer/commits/master 



i think they have pre-compiled version. Be aware in tsmuxer context DV 
usually mean Dolby Vision, not dv as dv video codec.





I downloaded and unpacked an appimage, but could not see BDAV mentioned. 
Have you seen any good user examples for tsMuxer?


Terje J. H

-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-13 Thread Andrew Randrianasulu via Cin 
On Saturday, November 13, 2021, Terje J. Hanssen 
wrote:

>
>
> Den 10.11.2021 00:39, skrev Andrew Randrianasulu:
>
>>
>>
>> On Wednesday, November 10, 2021, Terje J. Hanssen via Cin <
>> [email protected] > wrote:
>>
>>
>>
>> As this source file is a 10-bit 422 video with pcm audio, I think
>> the following render setup could fit automatic:
>> Setting Format: rgb(a)-float color model
>> Render File Format: FFMPEG mp4
>> Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4
>> Pixels : yuv422p10le
>> Bitrate: ?
>> Quality: ?
>> Preset: Medium default w/i.e user purpose adjustment faster/slower
>> Audio: would it be possible and compliant to have the option to
>> just copy the source PCM audio?
>>
>>
>>
>> well, I do not think cinelerra can just pass original audio untouched (
>> May be this can be coded, but IMO Cin's main focus was on re-processing
>> input audio and video, not just cutting. Also, input sources for one
>> session can vary... {this one is less of problem, just so far there is no
>> 'guess' table that can be used for setting up parameters from already-known
>> at encoding time session params}. Maybe encoding profiles can be used for
>> this, need to look..
>>
>>
> Possibly I thought merely on just "ffmpeg first input" and "ffmpeg output"
> (and Cin just as a gui front end).


yeah... I posted link to python script supposedly (if I read desc.
correctly!) cutting files according to edl. Now one might try it and
assemble resulting clips by another ffmpeg command..



> Regarding uncompressed PCM audio, FFMPEG looks to not support PCM in MP4;
> I read only Sony had a solution for that.


heh, it seems one can research this field for day and night)




> -
>
> However I got FFMPEG to copy PCM when I transmuxed to MKV container at the
> same time as the video part was transcoded to x265:


good...


> ffmpeg -i hd01.mov -c:a copy -c:v libx265 hd01_pcm_x265.mkv
>
> du -sh hd01.mov hd01_pcm_x265.mkv
> 1,7Ghd01.mov
> 176Mhd01_pcm_x265.mkv
> --
> ffmpeg -i dv01.dv -c:a copy -c:v libx265 dv01_pcm_x265.mkv
>
> du -sh dv01.dv dv01_pcm_x265.mkv
> 2,0Gdv01.dv
> 209Mdv01_pcm_x265.mkv
>
> 
>
>
>
>> (Another one for "home-made HD videos" on Blu-ray discs (BDAV):
>> Will it be possible to record (copy) source 1080iHDV.m2t files
>> (video and audio) to the BD-R(E) discs?)
>>
>>
>>
>> I was thinking about integrating tsMuxer but this does not solve problem
>> about unavailability of pre-encoded packets in cin's vframe for mpeg2..
>> Probably BC_COMPRESSED  type should be split for mjpeg/dv/mpeg2/h264 types
>> but this is larger rework than I can attempt from tablet ...
>>
>>
>> If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray for
> burning on BD-RE disk (and DVD-R), this could make it possible to preserve
> and test playabilty compliance of DV SD and MPEG-2 HD(V) streams content on
> the same disc, as described in these papers:
>
> Blu-ray Disc, Rewritable Format, Audio Visual Application Format
> Specifications for BD-RE Version 2.1, March 2008:
> Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV
> directory
> http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Par
> t3_V2.1_WhitePaper_080406-15271.pdf
>
> Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016.
> ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1.
> V2.0. BDMV.
> http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf



well, if you have player (or friend(s) with player(s)) you can try for
yourself

https://github.com/justdan96/tsMuxer/commits/master

i think they have pre-compiled version. Be aware in tsmuxer context DV
usually mean Dolby Vision, not dv as dv video codec.

>
> Terje J. H
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-13 Thread Terje J. Hanssen via Cin 



Den 10.11.2021 00:39, skrev Andrew Randrianasulu:



On Wednesday, November 10, 2021, Terje J. Hanssen via Cin 
mailto:[email protected]>> wrote:




As this source file is a 10-bit 422 video with pcm audio, I think
the following render setup could fit automatic:
Setting Format: rgb(a)-float color model
Render File Format: FFMPEG mp4
Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4
Pixels : yuv422p10le
Bitrate: ?
Quality: ?
Preset: Medium default w/i.e user purpose adjustment faster/slower
Audio: would it be possible and compliant to have the option to
just copy the source PCM audio?



well, I do not think cinelerra can just pass original audio untouched (
May be this can be coded, but IMO Cin's main focus was on 
re-processing input audio and video, not just cutting. Also, input 
sources for one session can vary... {this one is less of problem, just 
so far there is no 'guess' table that can be used for setting up 
parameters from already-known at encoding time session params}. Maybe 
encoding profiles can be used for this, need to look..




Possibly I thought merely on just "ffmpeg first input" and "ffmpeg 
output" (and Cin just as a gui front end).
Regarding uncompressed PCM audio, FFMPEG looks to not support PCM in 
MP4; I read only Sony had a solution for that.

-

However I got FFMPEG to copy PCM when I transmuxed to MKV container at 
the same time as the video part was transcoded to x265:


ffmpeg -i hd01.mov -c:a copy -c:v libx265 hd01_pcm_x265.mkv

du -sh hd01.mov hd01_pcm_x265.mkv
1,7G    hd01.mov
176M    hd01_pcm_x265.mkv
--
ffmpeg -i dv01.dv -c:a copy -c:v libx265 dv01_pcm_x265.mkv

du -sh dv01.dv dv01_pcm_x265.mkv
2,0G    dv01.dv
209M    dv01_pcm_x265.mkv






(Another one for "home-made HD videos" on Blu-ray discs (BDAV):
Will it be possible to record (copy) source 1080iHDV.m2t files
(video and audio) to the BD-R(E) discs?)



I was thinking about integrating tsMuxer but this does not solve 
problem about unavailability of pre-encoded packets in cin's vframe 
for mpeg2.. Probably BC_COMPRESSED  type should be split for 
mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt 
from tablet ...



If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray 
for burning on BD-RE disk (and DVD-R), this could make it possible to 
preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) 
streams content on the same disc, as described in these papers:


Blu-ray Disc, Rewritable Format, Audio Visual Application Format 
Specifications for BD-RE Version 2.1, March 2008:
Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV 
directory

http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Part3_V2.1_WhitePaper_080406-15271.pdf

Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016. 
ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. 
Part1. V2.0. BDMV.

http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf

Terje J. H
--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-09 Thread Andrew Randrianasulu via Cin 
On Wednesday, November 10, 2021, Terje J. Hanssen via Cin <
[email protected]> wrote:

>
>
> Den 06.11.2021 23:20, skrev Terje J. Hanssen:
>
>>
>>
>> Den 06.11.2021 22:19, skrev Andrea paz via Cin:
>>
>>> @"Manual"
> I think it could be useful if it is possible to add some overview
> table(s) i.e in the manual section FFmpeg Format Options inside
> CINELERRA-GG:
> That is, valid and Standard Profiles with Compression and Pixels
> properties for actual purposes and media, that works for Cin-GG and
> Cin-GG multibit respectively?
>
 Andrea, do you want to add this or should I try?

>>> Good idea!
>>> The formats and codecs are too many and with too many variables; an
>>> idea could be to collect the ones used by the users; so we could
>>> indicate the combinations surely functional and tested. What do you
>>> say folks, would you like to send the formats and options you use?
>>> PS (@Phyllis): In the meantime I attach you the modify proposed by
>>> Andrew.
>>>
>>>
>> Tip:
>> Pick and compile a list of the most relevant and compatible (standard)
>> file formats/options for Cin-GG/ffmpeg rendering.
>> While I have just used the generic .mp4 container for my test files,
>> Blu-ray and Ultra HD Blu-ray and DVD video discs use other.
>>
>> Some reference articles:
>> https://blog.filestack.com/thoughts-and-knowledge/complete-
>> list-audio-video-file-formats/
>> https://www.computer.org/publications/tech-news/trends/8-
>> best-video-file-formats-for-2020
>> https://www.borrowlenses.com/blog/video-file-formats/
>> https://www.adobe.com/creativecloud/video/discover/best-video-format.html
>> https://support.google.com/youtube/troubleshooter/2888402?hl=en
>> https://en.wikipedia.org/wiki/Video_file_format
>> 
>>
>>
> IMO users often want encoding settings that fit the input file (source)
> quality and easy adjustments for the purpose of the output file.
> If Cin-GG/ffmpeg automatic could setup default format and render
> options/parameters/preset this way, it would be a good starting point.
> Maybe Cin-gg already is not far away from something like this?
>
> Again, to use my source file as an example:
>
> ffprobe hd01.mov
> [...]
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hd01.mov':
>   Metadata:
> creation_time   : 2016-02-23T23:49:21.00Z
>   Duration: 00:01:11.24, start: 0.00, bitrate: 200607 kb/s
>   Stream #0:0(eng): Video: prores (HQ) (apch / 0x68637061),
> yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)),
> 1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn, 2500
> tbc (default)
> Metadata:
>   creation_time   : 2016-02-23T23:49:21.00Z
>   handler_name: Apple Video Media Handler
>   vendor_id   : appl
>   encoder : Apple ProRes 422 (HQ)
>   Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16
> channels, s32 (24 bit), 18432 kb/s (default)
> Metadata:
>   creation_time   : 2016-02-23T23:49:21.00Z
>   handler_name: Apple Sound Media Handler
>   vendor_id   : [0][0][0][0]
>
>
> As this source file is a 10-bit 422 video with pcm audio, I think the
> following render setup could fit automatic:
> Setting Format: rgb(a)-float color model
> Render File Format: FFMPEG mp4
> Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4
> Pixels : yuv422p10le
> Bitrate: ?
> Quality: ?
> Preset: Medium default w/i.e user purpose adjustment faster/slower
> Audio: would it be possible and compliant to have the option to just copy
> the source PCM audio?



well, I do not think cinelerra can just pass original audio untouched (
May be this can be coded, but IMO Cin's main focus was on re-processing
input audio and video, not just cutting. Also, input sources for one
session can vary... {this one is less of problem, just so far there is no
'guess' table that can be used for setting up parameters from already-known
at encoding time session params}. Maybe encoding profiles can be used for
this, need to look..


> (Another one for "home-made HD videos" on Blu-ray discs (BDAV):
> Will it be possible to record (copy) source 1080iHDV.m2t files (video and
> audio) to the BD-R(E) discs?)



I was thinking about integrating tsMuxer but this does not solve problem
about unavailability of pre-encoded packets in cin's vframe for mpeg2..
Probably BC_COMPRESSED  type should be split for mjpeg/dv/mpeg2/h264 types
but this is larger rework than I can attempt from tablet ...

May be for cuts-only you can export edl and then use ffmpeg's copy/mux mode
? (no ready to use script for this, sorry)

>
> ---
>
> Terje J. H
>
>
>
>
>
>
>
>
> --
> Cin mailing list
> [email protected]
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-09 Thread Terje J. Hanssen via Cin 



Den 06.11.2021 23:20, skrev Terje J. Hanssen:



Den 06.11.2021 22:19, skrev Andrea paz via Cin:

@"Manual"
I think it could be useful if it is possible to add some overview
table(s) i.e in the manual section FFmpeg Format Options inside
CINELERRA-GG:
That is, valid and Standard Profiles with Compression and Pixels
properties for actual purposes and media, that works for Cin-GG and
Cin-GG multibit respectively?

Andrea, do you want to add this or should I try?

Good idea!
The formats and codecs are too many and with too many variables; an
idea could be to collect the ones used by the users; so we could
indicate the combinations surely functional and tested. What do you
say folks, would you like to send the formats and options you use?
PS (@Phyllis): In the meantime I attach you the modify proposed by 
Andrew.




Tip:
Pick and compile a list of the most relevant and compatible (standard) 
file formats/options for Cin-GG/ffmpeg rendering.
While I have just used the generic .mp4 container for my test files, 
Blu-ray and Ultra HD Blu-ray and DVD video discs use other.


Some reference articles:
https://blog.filestack.com/thoughts-and-knowledge/complete-list-audio-video-file-formats/ 

https://www.computer.org/publications/tech-news/trends/8-best-video-file-formats-for-2020 


https://www.borrowlenses.com/blog/video-file-formats/
https://www.adobe.com/creativecloud/video/discover/best-video-format.html
https://support.google.com/youtube/troubleshooter/2888402?hl=en
https://en.wikipedia.org/wiki/Video_file_format




IMO users often want encoding settings that fit the input file (source) 
quality and easy adjustments for the purpose of the output file.
If Cin-GG/ffmpeg automatic could setup default format and render 
options/parameters/preset this way, it would be a good starting point.

Maybe Cin-gg already is not far away from something like this?

Again, to use my source file as an example:

ffprobe hd01.mov
[...]
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hd01.mov':
  Metadata:
    creation_time   : 2016-02-23T23:49:21.00Z
  Duration: 00:01:11.24, start: 0.00, bitrate: 200607 kb/s
  Stream #0:0(eng): Video: prores (HQ) (apch / 0x68637061), 
yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 
1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn, 2500 
tbc (default)

    Metadata:
  creation_time   : 2016-02-23T23:49:21.00Z
  handler_name    : Apple Video Media Handler
  vendor_id   : appl
  encoder : Apple ProRes 422 (HQ)
  Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16 
channels, s32 (24 bit), 18432 kb/s (default)

    Metadata:
  creation_time   : 2016-02-23T23:49:21.00Z
  handler_name    : Apple Sound Media Handler
  vendor_id   : [0][0][0][0]


As this source file is a 10-bit 422 video with pcm audio, I think the 
following render setup could fit automatic:

Setting Format: rgb(a)-float color model
Render File Format: FFMPEG mp4
Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4
Pixels : yuv422p10le
Bitrate: ?
Quality: ?
Preset: Medium default w/i.e user purpose adjustment faster/slower
Audio: would it be possible and compliant to have the option to just 
copy the source PCM audio?


(Another one for "home-made HD videos" on Blu-ray discs (BDAV):
Will it be possible to record (copy) source 1080iHDV.m2t files (video 
and audio) to the BD-R(E) discs?)


---

Terje J. H








--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-09 Thread Terje J. Hanssen via Cin 



Den 06.11.2021 19:47, skrev Phyllis Smith via Cin:


Terje, I have not been following this thread very closely, but have a 
couple of comments.



A minor visual notice, why differ the Render button geometries
between
my two workstations with the same, latest Cin-GG appimage
installation?
See the attached screenshot,  the top Render window with square and
round buttons vs the bottom Render window with romb buttons.



Your 2 different workstations have 2 different $HOME/.bcast5 so you 
must have set one to "S.U.V" and the other to "unflat" in 
Settings->Preferences, Appearance tab, theme selection in top left 
hand corner.





Phyllis, thanks that was correct, and I was not aware of this before I 
verified it. My second  workstation (which previously was my office ws 
before I retired) has a really 2015 old .bcast and Cinelerra_rc with 
S.U.V theme set.


Terje J. H



--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-07 Thread Terje J. Hanssen via Cin 



Den 07.11.2021 04:55, skrev Andrew Randrianasulu:



On Sunday, November 7, 2021, Terje J. Hanssen > wrote:




Den 06.11.2021 19:09, skrev Andrew Randrianasulu:

On Saturday, November 6, 2021, Terje J. Hanssen
mailto:[email protected]>
>> wrote:


[.]

        @Andrea
        I succeeded to rendered further combinations and
cleaned up
        my file name syntax as follows:

        du -sh hd01.mov hd01*app*.mp4

        1,7G    hd01.mov (input 10bit ProRes HQ file)
        --
        70M   
hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
        72M    hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
        80M    hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
        82M    hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
        0   
hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed)
        26M    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
        26M    hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
        --
        26M   
hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
        26M   
hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
        26M   
hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
        26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4


    but how they look visually? I found it a bit strange
how h264
    compresses to different sizes yet h265 is all the
same.. you
    tried with rgb(a) - float project setting in all
cases, yes?




    The file quality (sharpness) looks fine against the input
hd01.mov
    file, the file colors varies a bit between greenish and
    yellow-brownish.

    I didn't change the default project setting, just loaded the
    hd01.mov file once, and rendered all files from it.
    The default Setting > Format color model is RGBA-8bit
    Obviously it should have been set to the higher
RGB(A)-Float for
    this 10-bit 422 ProRes HQ file format?


    Terje J. H



I think yes, there even was bugreport about it but back in
time it was said fine-tuning project settings (from
auto/default at media load) is user responsibility...


I have re-rendered all h65 files with Setting>Format>Color
model=RGB-Float or RGBA-Float and OK.
I'm not sure this is right or wrong, because all h265 file sizes
and Bit rate become still practical the same size as with RGBA-8.

Here two examples:

du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
26240    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
26268
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4


And here follows comparision (diff) of Mediainfo output for the
same files:

diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo
2c2
< Complete name   : hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
---
> Complete name   :
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
9c9
< Overall bit rate : 3 015 kb/s
---
> Overall bit rate : 3 018 kb/s
20c20
< Bit rate    : 2 685 kb/s
---
> Bit rate    : 2 687 kb/s
28c28
< Bit depth    : 8 bits
---
> Bit depth    : 10 bits
34,35c34,35
< Writing library    : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64
bit] 8bit
< Encoding settings   : cpuid=039 / frame-threads=3 / wpp /
no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2
/ input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0
/ high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance /
no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 /
no-temporal-layers / open-gop / min-keyint=30 / keyint=30 /
gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid /
bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40
/ hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64
/ min-cu-size=8 / no-rect / no-amp / max-tu-size=32 /
tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 /
dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 /
nr-inter=0 / no-constrained-intra / strong-intra-smoothing /
max-merge=3 / limit-refs=1 / no-limit-m

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Andrew Randrianasulu via Cin 
On Sunday, November 7, 2021, Terje J. Hanssen 
wrote:

>
>
> Den 06.11.2021 19:09, skrev Andrew Randrianasulu:
>
> On Saturday, November 6, 2021, Terje J. Hanssen > > wrote:
>>
>
> [.]
>>
>> @Andrea
>>> I succeeded to rendered further combinations and cleaned up
>>> my file name syntax as follows:
>>>
>>> du -sh hd01.mov hd01*app*.mp4
>>>
>>> 1,7Ghd01.mov (input 10bit ProRes HQ file)
>>> --
>>> 70Mhd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
>>> 72Mhd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
>>> 80Mhd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
>>> 82Mhd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
>>> 0hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
>>> (failed)
>>> 26Mhd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
>>> 26Mhd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
>>> --
>>> 26Mhd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
>>> 26Mhd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
>>> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
>>> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
>>>
>>>
>>> but how they look visually? I found it a bit strange how h264
>>> compresses to different sizes yet h265 is all the same.. you
>>> tried with rgb(a) - float project setting in all cases, yes?
>>>
>>>
>>>
>>>
>> The file quality (sharpness) looks fine against the input hd01.mov
>> file, the file colors varies a bit between greenish and
>> yellow-brownish.
>>
>> I didn't change the default project setting, just loaded the
>> hd01.mov file once, and rendered all files from it.
>> The default Setting > Format color model is RGBA-8bit
>> Obviously it should have been set to the higher RGB(A)-Float for
>> this 10-bit 422 ProRes HQ file format?
>>
>>
>> Terje J. H
>>
>>
>>
>> I think yes, there even was bugreport about it but back in time it was
>> said fine-tuning project settings (from auto/default at media load) is user
>> responsibility...
>>
>
> I have re-rendered all h65 files with Setting>Format>Color model=RGB-Float
> or RGBA-Float and OK.
> I'm not sure this is right or wrong, because all h265 file sizes and Bit
> rate become still practical the same size as with RGBA-8.
>
> Here two examples:
>
> du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
> hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
> 26240hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
> 26268 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
>
>
> And here follows comparision (diff) of Mediainfo output for the same files:
>
> diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo
> hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo
> 2c2
> < Complete name:
> hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
> ---
> > Complete name:
> hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
> 9c9
> < Overall bit rate : 3 015 kb/s
> ---
> > Overall bit rate : 3 018 kb/s
> 20c20
> < Bit rate : 2 685 kb/s
> ---
> > Bit rate : 2 687 kb/s
> 28c28
> < Bit depth: 8 bits
> ---
> > Bit depth: 10 bits
> 34,35c34,35
> < Writing library  : x265
> 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 8bit
> < Encoding settings: cpuid=039 /
> frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2
> / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 /
> level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance /
> no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 /
> no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0
> / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 /
> lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice /
> no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp /
> max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 /
> rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip /
> nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing /
> max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 /
> temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb /
> no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 /
> selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast /
> no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 /
> psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 /
> r

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Terje J. Hanssen via Cin 



Den 06.11.2021 19:09, skrev Andrew Randrianasulu:

On Saturday, November 6, 2021, Terje J. Hanssen 
mailto:[email protected]>> wrote:



[.]


@Andrea
I succeeded to rendered further combinations and cleaned up
my file name syntax as follows:

du -sh hd01.mov hd01*app*.mp4

1,7G    hd01.mov (input 10bit ProRes HQ file)
--
70M    hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
72M    hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
80M    hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
82M    hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
0    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed)
26M    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
26M    hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
--
26M    hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4


but how they look visually? I found it a bit strange how h264
compresses to different sizes yet h265 is all the same.. you
tried with rgb(a) - float project setting in all cases, yes?





The file quality (sharpness) looks fine against the input hd01.mov
file, the file colors varies a bit between greenish and
yellow-brownish.

I didn't change the default project setting, just loaded the
hd01.mov file once, and rendered all files from it.
The default Setting > Format color model is RGBA-8bit
Obviously it should have been set to the higher RGB(A)-Float for
this 10-bit 422 ProRes HQ file format?


Terje J. H



I think yes, there even was bugreport about it but back in time it was 
said fine-tuning project settings (from auto/default at media load) is 
user responsibility...


I have re-rendered all h65 files with Setting>Format>Color 
model=RGB-Float or RGBA-Float and OK.
I'm not sure this is right or wrong, because all h265 file sizes and Bit 
rate become still practical the same size as with RGBA-8.


Here two examples:

du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4

26240    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
26268 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4


And here follows comparision (diff) of Mediainfo output for the same files:

diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo 
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo

2c2
< Complete name    : 
hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4

---
> Complete name    : 
hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4

9c9
< Overall bit rate : 3 015 kb/s
---
> Overall bit rate : 3 018 kb/s
20c20
< Bit rate : 2 685 kb/s
---
> Bit rate : 2 687 kb/s
28c28
< Bit depth    : 8 bits
---
> Bit depth    : 10 bits
34,35c34,35
< Writing library  : x265 
3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 8bit
< Encoding settings    : cpuid=039 / 
frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / 
log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / 
total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / 
no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd 
/ info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / 
keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / 
bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / 
hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / 
min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / 
tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / 
no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / 
no-constrained-intra / strong-intra-smoothing / max-merge=3 / 
limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / 
temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / 
no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / 
selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / 
no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / 
psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / 
rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 
/ ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / 
zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / 
qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / 
colorprim=9 / tr

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Terje J. Hanssen via Cin 




Den 06.11.2021 22:19, skrev Andrea paz via Cin:

@"Manual"
I think it could be useful if it is possible to add some overview
table(s) i.e in the manual section FFmpeg Format Options inside
CINELERRA-GG:
That is, valid and Standard Profiles with Compression and Pixels
properties for actual purposes and media, that works for Cin-GG and
Cin-GG multibit respectively?

Andrea, do you want to add this or should I try?

Good idea!
The formats and codecs are too many and with too many variables; an
idea could be to collect the ones used by the users; so we could
indicate the combinations surely functional and tested. What do you
say folks, would you like to send the formats and options you use?
PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.



Tip:
Pick and compile a list of the most relevant and compatible (standard) 
file formats/options for Cin-GG/ffmpeg rendering.
While I have just used the generic .mp4 container for my test files, 
Blu-ray and Ultra HD Blu-ray and DVD video discs use other.


Some reference articles:
https://blog.filestack.com/thoughts-and-knowledge/complete-list-audio-video-file-formats/
https://www.computer.org/publications/tech-news/trends/8-best-video-file-formats-for-2020
https://www.borrowlenses.com/blog/video-file-formats/
https://www.adobe.com/creativecloud/video/discover/best-video-format.html
https://support.google.com/youtube/troubleshooter/2888402?hl=en
https://en.wikipedia.org/wiki/Video_file_format


Terje J. H



--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Andrea paz via Cin 
>> @"Manual"
>> I think it could be useful if it is possible to add some overview
>> table(s) i.e in the manual section FFmpeg Format Options inside
>> CINELERRA-GG:
>> That is, valid and Standard Profiles with Compression and Pixels
>> properties for actual purposes and media, that works for Cin-GG and
>> Cin-GG multibit respectively?
>
> Andrea, do you want to add this or should I try?

Good idea!
The formats and codecs are too many and with too many variables; an
idea could be to collect the ones used by the users; so we could
indicate the combinations surely functional and tested. What do you
say folks, would you like to send the formats and options you use?
PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.
\chapter{Performance and other Tips}%
\label{cha:performance_tips}

Performance of \CGG{} is related to the software and video format being used in conjunction with your computer system hardware -- the number of CPUs and its speed, I/O bus speed, graphics card, and amount of available memory. A basic, less powerful system will be sufficient for users working with audio only or lower resolution video formats.  Higher end computers will be needed when playing and working with higher resolution formats, like 1080p or 4k. Adding effects and multiple tracks will require more cpu, memory, and various other resources to 
perform at an acceptable level.

Perhaps the easiest method for determining if your performance could be improved is to look at the numerical value displayed as \textit{Framerate achieved}.  Good performance means that when \textit{Play every frame} is set 
in \texttt{Settings $\rightarrow$ Preferences, Playback A} tab, the frames/second (frames per second or fps) in playback might be almost always at the maximum rate of your project setting and/or video frame rate. You can check this in \texttt{Settings $\rightarrow$ Preferences, Playback A}, by watching \textit{Framerate achieved} while playing forward.  A higher number is better, up to the format frame rate of the video.

Some computer hardware factors to consider for better performance are listed here:
\begin{itemize}
	\item Multi-core and more SMP processors greatly improve \CGG{} speed by making use of threads.
	\item A large amount of free memory available can help speed up operations by avoiding unnecessary disk
	swaps and keeping videos easily accessible in memory.
	\item Video editing is almost always I/O intensive. To create longer running videos at high resolution
	you will want to have a lot of disk space available on fast access disks.
	\item \CGG{} benefits from OpenGL hardware acceleration. A good graphics card is worthwhile to have.
	\item Multiple monitors really come in handy to increase productivity as you can see more information and
	in bigger windows so you do not have to keep moving windows around.
\end{itemize}
Besides the above hardware recommendations, this section covers tips for performance improvements and tips on how to perform some specific tasks, often for older media.

\section{Hardware video acceleration}%
\label{sec:hardware_video_acceleration}
\index{hardware!acceleration}

With certain newer, more powerful graphics boards and newer device drivers, there is the potential for enhanced \textit{decode} and \textit{encode} performance.   Decode refers to loading and playing video in \CGG{}. The GPU, Graphics Processing Unit, on the graphics board is accessed via one of the following libraries: vdpau or vaapi. The hardware acceleration done by the graphics card increases performance by activating certain functions in connection with a few of the FFmpeg decoders. This use makes it possible for the graphics card to decode video, thus offloading the CPU.  Decode operations are described here next.  
Encode refers to rendering video and is described at the end of this section
under \hyperref[sub:gpu_hardware_encoding]{GPU hardware encoding}.

VDPAU, Video Decode and Presentation API for Unix, is an open source library to offload portions of the video decoding process and video post-processing to the GPU of graphics boards, such as Nvidia.  It may also apply to Nouveau and Amdgpu boards (by wrapper), but that has not been verified.

VA-API, Video Acceleration API, is an open source library which provides both hardware accelerated video encoding and decoding for use mostly with Intel (and AMD) graphics boards. 


Currently only the most common codecs, such as MPEG-1, MPEG-2, MPEG-4, H.264 /MPEG-4 and h265 (hevc), are accelerated/optimized by the graphics card to play these particular video formats efficiently. The other formats are not optimized so you will see no performance improvement since the CPU will handle them as before, just as if no hardware acceleration was activated. There are many different graphics cards and computer systems setup, so you will have to test which specific settings work best for you.  So far this has been tested at least with Nvidia, Radeon, and Broadwell graph

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Phyllis Smith via Cin 
Terje, I have not been following this thread very closely, but have a
couple of comments.

> A minor visual notice, why differ the Render button geometries between
> my two workstations with the same, latest Cin-GG appimage installation?
> See the attached screenshot,  the top Render window with square and
> round buttons vs the bottom Render window with romb buttons.
>
Your 2 different workstations have 2 different $HOME/.bcast5 so you must
have set one to "S.U.V" and the other to "unflat" in Settings->Preferences,
Appearance tab, theme selection in top left hand corner.

@"Manual"
> I think it could be useful if it is possible to add some overview
> table(s) i.e in the manual section FFmpeg Format Options inside
> CINELERRA-GG:
> That is, valid and Standard Profiles with Compression and Pixels
> properties for actual purposes and media, that works for Cin-GG and
> Cin-GG multibit respectively?
>
Andrea, do you want to add this or should I try?
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Andrew Randrianasulu via Cin 
On Saturday, November 6, 2021, Terje J. Hanssen 
wrote:

>
>
> Den 06.11.2021 17:15, skrev Andrew Randrianasulu:
>
>
>
> On Saturday, November 6, 2021, Terje J. Hanssen 
> wrote:
>
>>
>>
>> Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
>>
>>>
>>>
>>> On Saturday, November 6, 2021, Terje J. Hanssen via Cin <
>>> [email protected] > wrote:
>>>
>>>
>>>
>>> Den 05.11.2021 11:55, skrev Andrea paz:
>>>
>>> @Terje
>>> If I understand correctly, you used only the h264.mp4 and
>>> h265.mp4
>>> presets, changing the "Pixels" option from "420 8-bit" to "422
>>> 10-bit"
>>> each time. Also, try using the 8, 10 and 12-bit h265 presets;
>>> they are
>>> Andrew's new ones that work for me in the non-multibit version.
>>> I've tried non-multibit and I can render h264.mp4 at 8 and
>>> 10-bit and
>>> h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
>>> version always behaves as a sum of multibit and non-multibit.
>>>
>>>
>>> @Andrea and All
>>> I had a look into the Manual: Modifying FFmpeg Format Options
>>> inside CINELERRA-GG
>>> Figure 9.2: FFmpeg wrench, video preset, view and format options
>>> https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifyi
>>> ng_FFmpeg_Format_Opt.html
>>> >> ing_FFmpeg_Format_Opt.html>
>>>
>>> and tried to indicate cin version and parameters in my test file
>>> names (no warranty the syntax is quite consistent), i.e
>>>
>>> hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
>>> File > Render | File format: FFMPEG mp4 | Video Wrench
>>> > Video Preset | Compression: h264-10bit.mp4 | Pixels: yuv422p10le
>>>
>>> While this rendered OK on one of my workstation, another
>>> installation wouldn't render at all with the following
>>> Message log:
>>> virtual void Render::handle close event(int):
>>>  Create new at labels checked, but no labels
>>> (or other Failure)
>>>
>>>
>>>
>>> guess in this case you (accidently?) selected rendering option making
>>> new file at each label (3rd radiobutton out of four) instead of rendering
>>> whole file/ in-out region
>>>
>>>
>>>
>> @Andrew
>> Thx, that's right - I don't know why or how the Render "Make new file
>> box" was checked on my MSI workstation.
>> Unchecked it and the above file rendered ok.
>>
>> A minor visual notice, why differ the Render button geometries between my
>> two workstations with the same, latest Cin-GG appimage installation?
>> See the attached screenshot,  the top Render window with square and round
>> buttons vs the bottom Render window with romb buttons.
>
>
> guess: because different Cin instances used different themes?
>
>
>> One render option combination that Cin-gg regular reported error message
>> (invalid or not supported), was as shown on the screenshot
>> h265-10bit.mp4 compression and yuv422p10le pixels
>> Is this correct?
>
>
> well, it was motivation for me to write my patches, but apparently not all
> systems behave like this...
>
>>
>>
>> @Andrea
>> I succeeded to rendered further combinations and cleaned up my file name
>> syntax as follows:
>>
>> du -sh hd01.mov hd01*app*.mp4
>>
>> 1,7Ghd01.mov (input 10bit ProRes HQ file)
>> --
>> 70Mhd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
>> 72Mhd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
>> 80Mhd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
>> 82Mhd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
>> 0hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed)
>> 26Mhd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
>> 26Mhd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
>> --
>> 26Mhd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
>> 26Mhd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
>> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
>> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
>
>
> but how they look visually? I found it a bit strange how h264 compresses
> to different sizes yet h265 is all the same.. you tried with rgb(a) - float
> project setting in all cases, yes?
>
>>
>>
>>
> The file quality (sharpness) looks fine against the input hd01.mov file,
> the file colors varies a bit between greenish and yellow-brownish.
>
> I didn't change the default project setting, just loaded the hd01.mov file
> once, and rendered all files from it.
> The default Setting > Format color model is RGBA-8bit
> Obviously it should have been set to the higher RGB(A)-Float for this
> 10-bit 422 ProRes HQ file format?
>
>
> Terje J. H
>


I think yes, there even was bugreport about it but back in time it was said
fine-tuning project settings (from auto/default at media load) is user
responsibility...
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Terje J. Hanssen via Cin 



Den 06.11.2021 17:15, skrev Andrew Randrianasulu:



On Saturday, November 6, 2021, Terje J. Hanssen 
mailto:[email protected]>> wrote:




Den 06.11.2021 00:29, skrev Andrew Randrianasulu:



On Saturday, November 6, 2021, Terje J. Hanssen via Cin
mailto:[email protected]>
>> wrote:



    Den 05.11.2021 11:55, skrev Andrea paz:

        @Terje
        If I understand correctly, you used only the h264.mp4
and h265.mp4
        presets, changing the "Pixels" option from "420 8-bit"
to "422
        10-bit"
        each time. Also, try using the 8, 10 and 12-bit h265
presets;
        they are
        Andrew's new ones that work for me in the non-multibit
version.
        I've tried non-multibit and I can render h264.mp4 at 8 and
        10-bit and
        h265.mp4 at 8 and 10-bit. In short, in my case the
non-multibit
        version always behaves as a sum of multibit and
non-multibit.


    @Andrea and All
    I had a look into the Manual: Modifying FFmpeg Format Options
    inside CINELERRA-GG
    Figure 9.2: FFmpeg wrench, video preset, view and format
options

https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html


   

>

    and tried to indicate cin version and parameters in my
test file
    names (no warranty the syntax is quite consistent), i.e

    hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
    File > Render | File format: FFMPEG mp4 | Video Wrench
    > Video Preset | Compression: h264-10bit.mp4 | Pixels:
yuv422p10le

    While this rendered OK on one of my workstation, another
    installation wouldn't render at all with the following
    Message log:
    virtual void Render::handle close event(int):
     Create new at labels checked, but no labels
    (or other Failure)



guess in this case you (accidently?) selected rendering option
making new file at each label (3rd radiobutton out of four)
instead of rendering whole file/ in-out region



@Andrew
Thx, that's right - I don't know why or how the Render "Make new
file box" was checked on my MSI workstation.
Unchecked it and the above file rendered ok.

A minor visual notice, why differ the Render button geometries
between my two workstations with the same, latest Cin-GG appimage
installation?
See the attached screenshot,  the top Render window with square
and round buttons vs the bottom Render window with romb buttons.


guess: because different Cin instances used different themes?


One render option combination that Cin-gg regular reported error
message (invalid or not supported), was as shown on the screenshot
h265-10bit.mp4 compression and yuv422p10le pixels
Is this correct?


well, it was motivation for me to write my patches, but apparently not 
all systems behave like this...




@Andrea
I succeeded to rendered further combinations and cleaned up my
file name syntax as follows:

du -sh hd01.mov hd01*app*.mp4

1,7G    hd01.mov (input 10bit ProRes HQ file)
--
70M    hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
72M    hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
80M    hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
82M    hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
0    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed)
26M    hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
26M    hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
--
26M    hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4


but how they look visually? I found it a bit strange how h264 
compresses to different sizes yet h265 is all the same.. you tried 
with rgb(a) - float project setting in all cases, yes?






The file quality (sharpness) looks fine against the input hd01.mov file, 
the file colors varies a bit between greenish and yellow-brownish.


I didn't change the default project setting, just loaded the hd01.mov 
file once, and rendered all files from it.

The default Setting > Format color model is RGBA-8bit
Obviously it should have been set to th

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-06 Thread Andrew Randrianasulu via Cin 
On Saturday, November 6, 2021, Terje J. Hanssen 
wrote:

>
>
> Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
>
>>
>>
>> On Saturday, November 6, 2021, Terje J. Hanssen via Cin <
>> [email protected] > wrote:
>>
>>
>>
>> Den 05.11.2021 11:55, skrev Andrea paz:
>>
>> @Terje
>> If I understand correctly, you used only the h264.mp4 and h265.mp4
>> presets, changing the "Pixels" option from "420 8-bit" to "422
>> 10-bit"
>> each time. Also, try using the 8, 10 and 12-bit h265 presets;
>> they are
>> Andrew's new ones that work for me in the non-multibit version.
>> I've tried non-multibit and I can render h264.mp4 at 8 and
>> 10-bit and
>> h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
>> version always behaves as a sum of multibit and non-multibit.
>>
>>
>> @Andrea and All
>> I had a look into the Manual: Modifying FFmpeg Format Options
>> inside CINELERRA-GG
>> Figure 9.2: FFmpeg wrench, video preset, view and format options
>> https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifyi
>> ng_FFmpeg_Format_Opt.html
>> > ing_FFmpeg_Format_Opt.html>
>>
>> and tried to indicate cin version and parameters in my test file
>> names (no warranty the syntax is quite consistent), i.e
>>
>> hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
>> File > Render | File format: FFMPEG mp4 | Video Wrench
>> > Video Preset | Compression: h264-10bit.mp4 | Pixels: yuv422p10le
>>
>> While this rendered OK on one of my workstation, another
>> installation wouldn't render at all with the following
>> Message log:
>> virtual void Render::handle close event(int):
>>  Create new at labels checked, but no labels
>> (or other Failure)
>>
>>
>>
>> guess in this case you (accidently?) selected rendering option making new
>> file at each label (3rd radiobutton out of four) instead of rendering whole
>> file/ in-out region
>>
>>
>>
> @Andrew
> Thx, that's right - I don't know why or how the Render "Make new file box"
> was checked on my MSI workstation.
> Unchecked it and the above file rendered ok.
>
> A minor visual notice, why differ the Render button geometries between my
> two workstations with the same, latest Cin-GG appimage installation?
> See the attached screenshot,  the top Render window with square and round
> buttons vs the bottom Render window with romb buttons.


guess: because different Cin instances used different themes?


> One render option combination that Cin-gg regular reported error message
> (invalid or not supported), was as shown on the screenshot
> h265-10bit.mp4 compression and yuv422p10le pixels
> Is this correct?


well, it was motivation for me to write my patches, but apparently not all
systems behave like this...

>
>
> @Andrea
> I succeeded to rendered further combinations and cleaned up my file name
> syntax as follows:
>
> du -sh hd01.mov hd01*app*.mp4
>
> 1,7Ghd01.mov (input 10bit ProRes HQ file)
> --
> 70Mhd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4
> 72Mhd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
> 80Mhd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
> 82Mhd01_cin_appimage_ffmpeg_h264_yuv422p.mp4
> 0hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed)
> 26Mhd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4
> 26Mhd01_cin_appimage_ffmpeg_h265_yuv422p.mp4
> --
> 26Mhd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
> 26Mhd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4
> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
> 26Mhd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4


but how they look visually? I found it a bit strange how h264 compresses to
different sizes yet h265 is all the same.. you tried with rgb(a) - float
project setting in all cases, yes?

>
>
> @"Manual"
> I think it could be useful if it is possible to add some overview table(s)
> i.e in the manual section FFmpeg Format Options inside CINELERRA-GG:
> That is, valid and Standard Profiles with Compression and Pixels
> properties for actual purposes and media, that works for Cin-GG and Cin-GG
> multibit respectively?
>
> -
> Terje J. H
>
>
>
>
>
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread Andrew Randrianasulu via Cin 
On Tuesday, November 2, 2021, Andrea paz via Cin 
wrote:

> All perfect installation and appimage. Thank you.
> Two questions:
> 1- I also tried to build OpenCV along with the source and had no
> errors. But the plugins don't appear in the plugins list. Instead
> putting manually the plugins in ".../bin/plugins" everything works
> normally. (PS: OpenCV has been updated recently, is it possible to
> create the most updated copies of the plugins?)


try to configure cin with opencv=sys,  if you have latest installed?

https://cinelerra-gg.org/download/CinelerraGG_Manual/How_Build_OpenCV_Plugins.html#SECTION00121222000

(may be download location for opencv sources should be consistent with
github releases urls? sourceforge tend to ban some locations... solvable
via vpn, but meh)



> 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?
>
> PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to
> me.
> --
> Cin mailing list
> [email protected]
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread Terje J. Hanssen via Cin 



Den 05.11.2021 11:55, skrev Andrea paz:

@Terje
If I understand correctly, you used only the h264.mp4 and h265.mp4
presets, changing the "Pixels" option from "420 8-bit" to "422 10-bit"
each time. Also, try using the 8, 10 and 12-bit h265 presets; they are
Andrew's new ones that work for me in the non-multibit version.
I've tried non-multibit and I can render h264.mp4 at 8 and 10-bit and
h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
version always behaves as a sum of multibit and non-multibit.



@Andrea and All
I had a look into the Manual: Modifying FFmpeg Format Options inside 
CINELERRA-GG

Figure 9.2: FFmpeg wrench, video preset, view and format options
https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html

and tried to indicate cin version and parameters in my test file names 
(no warranty the syntax is quite consistent), i.e


hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
File > Render | File format: FFMPEG mp4 | Video Wrench
> Video Preset | Compression: h264-10bit.mp4 | Pixels: yuv422p10le

While this rendered OK on one of my workstation, another installation 
wouldn't render at all with the following

Message log:
virtual void Render::handle close event(int):
 Create new at labels checked, but no labels
(or other Failure)



Regarding ffmpeg (before going further with testing):
Is it a somewhat correct understanding that rendering (encoding) inside 
Cin-GG (AppImage) works as a GUI front-end for its statical linked ffmepg?


Even if my local system's ffmpeg is not used, I think 3 ffmpeg commands 
(applied from stackexchange) possibly add understanding also for 
rendering via Cin-GG:


-
1) To see what pixel formats and bit depths are supported by libx264:

ffmpeg -h encoder=libx264 | grep Supported

ffmpeg version 4.4 Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 7 (SUSE Linux)
 [ffmpeg text header .]  --enable-libx264 --enable-libx265 
--enable-librtmp --enable-libxvid


    Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p 
yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray 
gray10le


(It seems to me that both libx264 and libx265 are enabled in this case)

Is it possible that Cin and Cin-multi have statical linked ffmpeg with 
both libx enabled?



2) and by libx265, here with suppressed ffmpeg text header (-v quiet):

ffmpeg -v quiet -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


In both cases 10-bit pixel formats are those that end with 10le.

---
3) ffmpeg with the -codec switch, you will get an output of (all) codecs 
it understands. The codecs are prefaced with letter codes that describe 
their function. 'D' means Decode, meaning that particular codec has 
decoding capability (read). While 'E' means Encode, or compiling/writing 
capability using that particular codec.


ffmpeg -v quiet -codecs | egrep "x264|x265"

 DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 
(decoders: h264 h264_v4l2m2m h264_qsv ) (encoders: libx264 libx264rgb 
h264_qsv h264_v4l2m2m h264_vaapi )
 DEV.L. hevc H.265 / HEVC (High Efficiency Video 
Coding) (decoders: hevc hevc_qsv hevc_v4l2m2m ) (encoders: libx265 
hevc_qsv hevc_v4l2m2m hevc_vaapi )





Terje J. H



















--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread Andrea paz via Cin 
Tried starting CinGG (build = non-multibit) with LD_DEBUG=libs; then
rendered with the h265-12bit.mp4 preset.
For the little I understand about it, it seems that it really looks
for libx265 on the system and not in thirdparty.
See x265.txt file.
[BOOT CinGG]:

  LD_DEBUG=libs CIN_CONFIG=/home/paz/.bcast6 
/home/paz/cinelerra5/cinelerra-5.1/bin/./cin

 16760: find library=libX11.so.6 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libX11.so.6
 16760:
 16760: find library=libXext.so.6 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libXext.so.6
 16760:
 16760: find library=libXinerama.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libXinerama.so.1
 16760:
 16760: find library=libXfixes.so.3 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libXfixes.so.3
 16760:
 16760: find library=libbz2.so.1.0 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libbz2.so.1.0
 16760:
 16760: find library=libfontconfig.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libfontconfig.so.1
 16760:
 16760: find library=libfreetype.so.6 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libfreetype.so.6
 16760:
 16760: find library=liblzma.so.5 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/liblzma.so.5
 16760:
 16760: find library=libpng16.so.16 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libpng16.so.16
 16760:
 16760: find library=libpthread.so.0 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libpthread.so.0
 16760:
 16760: find library=libz.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libz.so.1
 16760:
 16760: find library=libvdpau.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libvdpau.so.1
 16760:
 16760: find library=libva.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libva.so.2
 16760:
 16760: find library=libva-x11.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libva-x11.so.2
 16760:
 16760: find library=libva-drm.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libva-drm.so.2
 16760:
 16760: find library=libGL.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libGL.so.1
 16760:
 16760: find library=libGLU.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libGLU.so.1
 16760:
 16760: find library=libXv.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libXv.so.1
 16760:
 16760: find library=libXft.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libXft.so.2
 16760:
 16760: find library=libasound.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libasound.so.2
 16760:
 16760: find library=libpulse-simple.so.0 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libpulse-simple.so.0
 16760:
 16760: find library=libpulse.so.0 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libpulse.so.0
 16760:
 16760: find library=libusb-1.0.so.0 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libusb-1.0.so.0
 16760:
 16760: find library=libdl.so.2 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libdl.so.2
 16760:
 16760: find library=libnuma.so.1 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libnuma.so.1
 16760:
 16760: find library=libstdc++.so.6 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libstdc++.so.6
 16760:
 16760: find library=libm.so.6 [0]; searching
 16760:  search cache=/etc/ld.so.cache
 16760:   trying file=/usr/lib/libm.so.6
 16760:
 16760: find library=libmvec.so.1 [0]; searching

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread mnieuw--- via Cin 
@Andrea
You should not have to compile as root. If there is a difference in
behaviour between user and root build, it should be fixed.

> 
@Andrew,
both static and AppImage do not include all libraries. If static
included enough, maybe the AppImage would not be needed, if newer
system libraries are backwards compatible enough.
On the other hand, it would get much bigger.

MatN

-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread Andrew Randrianasulu via Cin 
On Friday, November 5, 2021, Andrea paz via Cin 
wrote:

> @Terje
> If I understand correctly, you used only the h264.mp4 and h265.mp4
> presets, changing the "Pixels" option from "420 8-bit" to "422 10-bit"
> each time. Also, try using the 8, 10 and 12-bit h265 presets; they are
> Andrew's new ones that work for me in the non-multibit version.
> I've tried non-multibit and I can render h264.mp4 at 8 and 10-bit and
> h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
> version always behaves as a sum of multibit and non-multibit.
> @all
> I'm thinking that it's the fault of my system that "gets" the 10-bit
> even when it shouldn't


in https://www.cinelerra-gg.org/bugtracker/view.php?id=596

you can see use of LD_DEBUG=libs,  where appimage apparently tries to
initialize libx265_main10/12.so system files  lately (at encodiing stage?),
so may be it was not visible to initial ldd?

I wonder if those files come from appimage or real system?

you and Terje can try to compare  output of this LD_DEBUG=libs path_to_cin
command for 10/12 bit h265 encoding..

Not sure if package manager will allow you to delete system-wide x265
development files (so Cin will have nothing but her own x265.a lib to use
at least after self-build).

It seems even with static switch some shared system libs are used (may be
because there was no  static a archives in some distro packages?)..






> When I compile a new CinGG I usually delete the old cinelerra5
> directory and then do a git clone. That way it shouldn't encounter any
> residue from the previous installation. Am I wrong? Maybe the fact
> that I compile not as root (except few times I use Valgrind or other
> tests) can be the cause of the behavior of my CinGGs?
> --
> Cin mailing list
> [email protected]
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-05 Thread Andrea paz via Cin 
@Terje
If I understand correctly, you used only the h264.mp4 and h265.mp4
presets, changing the "Pixels" option from "420 8-bit" to "422 10-bit"
each time. Also, try using the 8, 10 and 12-bit h265 presets; they are
Andrew's new ones that work for me in the non-multibit version.
I've tried non-multibit and I can render h264.mp4 at 8 and 10-bit and
h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
version always behaves as a sum of multibit and non-multibit.
@all
I'm thinking that it's the fault of my system that "gets" the 10-bit
even when it shouldn't
When I compile a new CinGG I usually delete the old cinelerra5
directory and then do a git clone. That way it shouldn't encounter any
residue from the previous installation. Am I wrong? Maybe the fact
that I compile not as root (except few times I use Valgrind or other
tests) can be the cause of the behavior of my CinGGs?
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-04 Thread Terje J. Hanssen via Cin 



Den 02.11.2021 17:20, skrev Andrea paz via Cin:

try to encode 8 and/or 12 bit h265 with normal and multibit build??

Test done several times before. Each result is the same for multibit
and unpatched build.
(I think it's better that way too, with everything always working. As
long as the same happens to others)



I recorded a 10-bit ProsRes HQ file (hd01.mov) in 2016 and rendered it 
to mp4 with the 2019 packaged rpm Cin (h264) and CinX (h265) on openSUSE 
Leap. Now I've  tested to render it correspondigly with the latest Cin 
regular and Cin-multi appimage versions.


--

For me it seems that  Cin is able to render both 8-bit and 10-bit with 
h264, while only CinX (multibit) is able to render with h265 compression.
For this test I've used File>Render | Video Wrench to select Compression 
and Pixels (color depth), and have not explored other format details 
especially.



Attach below some file properies and extracted output from Mediainfo:

du -sh hd01*

70M    hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
80M    hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
92M    hd01_cin_ffmpeg_h264_yuv422p10le.mp4
26M    hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
20M    hd01_cinx_ffmpeg_h265_yuv422p10le.mp4

ls -la hd01*

-rw-r--r-- 1 terje users   73189134 nov.   4 19:04 
hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4
-rw-r--r-- 1 terje users   82863073 nov.   4 19:30 
hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
-rw-r--r-- 1 terje users   96422147 feb.   2  2019 
hd01_cin_ffmpeg_h264_yuv422p10le.mp4
-rw-r--r-- 1 terje users   27078948 nov.   4 19:47 
hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4
-rw-r--r-- 1 terje users   20114981 feb.   4  2019 
hd01_cinx_ffmpeg_h265_yuv422p10le.mp4

-rwxrwxrwx 1 terje users 1786412681 feb.  24  2016 hd01.mov

file hd01*

hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4:   ISO Media, MP4 Base 
Media v1 [IS0 14496-12:2003]
hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4:   ISO Media, MP4 Base 
Media v1 [IS0 14496-12:2003]
hd01_cin_ffmpeg_h264_yuv422p10le.mp4:    ISO Media, MP4 Base 
Media v1 [IS0 14496-12:2003]
hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4: ISO Media, MP4 Base 
Media v1 [IS0 14496-12:2003]
hd01_cinx_ffmpeg_h265_yuv422p10le.mp4:   ISO Media, MP4 Base 
Media v1 [IS0 14496-12:2003]
hd01.mov:    Apple QuickTime 
movie (unoptimized)




mediainfo hd01.mov | egrep "Codec|Format|Chroma|Bit"

Format   : QuickTime
Format/Info  : Original Apple specifications
Format   : ProRes
Format version   : Version 0
Format profile   : 422 HQ
Codec ID : apch
Bit rate mode    : Variable
Bit rate : 182 Mb/s
Chroma subsampling   : 4:2:2
Bits/(Pixel*Frame)   : 3.513
Format   : PCM
Format settings  : Little / Signed
Codec ID : lpcm
Bit rate mode    : Constant
Bit rate : 18.4 Mb/s
Bit depth    : 24 bits



mediainfo hd01_cin_ffmpeg_h264_yuv422p10le.mp4 | egrep 
"Codec|Format|Chroma|Bit"


Format   : MPEG-4
Format profile   : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : High 4:2:2@L4
Format settings  : CABAC / 4 Ref Frames
Format settings, CABAC   : Yes
Format settings, Reference frames    : 4 frames
Format settings, GOP : M=4, N=25
Codec ID : avc1
Codec ID/Info    : Advanced Video Coding
Bit rate : 10.5 Mb/s
Chroma subsampling   : 4:2:2
Bit depth    : 10 bits
Bits/(Pixel*Frame)   : 0.202
Codec configuration box  : avcC
Format   : AAC LC
Format/Info  : Advanced Audio Codec Low 
Complexity

Codec ID : mp4a-40-2
Bit rate mode    : Variable
Bit rate : 328 kb/s

==

mediainfo hd01_cinx_ffmpeg_h265_yuv422p10le.mp4 | egrep 
"Codec|Format|Chroma|Bit"


Format   : MPEG-4
Format profile   : Base Media
Codec ID : isom (isom/iso2/mp41)
Format   : HEVC
Format/Info  

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrea paz via Cin 
> try to encode 8 and/or 12 bit h265 with normal and multibit build??

Test done several times before. Each result is the same for multibit
and unpatched build.
(I think it's better that way too, with everything always working. As
long as the same happens to others)
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrew Randrianasulu via Cin 
ah, apparently only command line x265 encoder prints this line as I
remember it:

x265 [error]: No input file. Run x265 --help for a list of options.
$ thirdparty/x265_3.5/8bit/x265 --version
x265 [info]: HEVC encoder version 3.5+1-f0c1022b6
x265 [info]: build info [Linux][clang 12.0.0][32 bit][noasm]
8bit+10bit+12bit
x265 [info]: using cpu capabilities: none!

confusing!

On Tuesday, November 2, 2021, Andrew Randrianasulu 
wrote:

> still a bit strange, shouldn't encoder string from mediainfo indicate
> 8+10+12 bit instead of just 10?
>
> 'x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit'
>
> try to encode 8 and/or 12 bit h265 with normal and multibit build??
>
>
> full mediainfo:
>
>
> $ mediainfo ~/storage/downloads/Browser/test-multibit1.mp4
> General
> Complete name : /data/data/com.termux/files/home/storage/downloads/
> Browser/test-multibit1.mp4
> Format : MPEG-4
> Format profile : Base Media
> Codec ID : isom (isom/iso2/mp41)
> File size : 1.66 MiB
> Duration : 35 s 280 ms
> Overall bit rate mode : Variable
> Overall bit rate : 395 kb/s
> Writing application : Lavf58.76.100
>
> Video
> ID : 1
> Format : HEVC
> Format/Info : High Efficiency Video Coding
> Format profile : Format Range@L3@Main
> Codec ID : hev1
> Codec ID/Info : High Efficiency Video Coding
> Duration : 35 s 240 ms
> Bit rate : 386 kb/s
> Width : 854 pixels
> Height : 480 pixels
> Display aspect ratio : 16:9
> Frame rate mode : Constant
> Frame rate : 25.000 FPS
> Color space : YUV
> Chroma subsampling : 4:2:2
> Bit depth : 10 bits
> Bits/(Pixel*Frame) : 0.038
> Stream size : 1.62 MiB (98%)
> Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit
> Encoding settings : cpuid=039 / frame-threads=4 / wpp / no-pmode /
> no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=854x480
> / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 /
> ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud /
> no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 /
> keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid /
> bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 /
> hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 /
> min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 /
> tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd
> / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra /
> strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1
> / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp /
> no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock /
> rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast
> / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 /
> psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 /
> rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 /
> ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree /
> zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 /
> qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=160:161 /
> overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 /
> colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 /
> max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info /
> slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps /
> no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 /
> no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt
> / no-idr-recovery-sei / analysis-reuse-level=0 /
> analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0
> / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 /
> no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 /
> copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei /
> no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 /
> scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 /
> decoder-max-rate=0 / no-vbv-live-multi-pass
> Color range : Full
> Color primaries : BT.2020
> Transfer characteristics : BT.2020 (10-bit)
> Matrix coefficients : BT.2020 constant
> Codec configuration box : hvcC
>
> Audio
> ID : 2
> Format : AAC LC
> Format/Info : Advanced Audio Codec Low Complexity
> Codec ID : mp4a-40-2
> Duration : 35 s 280 ms
> Source duration : 35 s 301 ms
> Source_Duration_LastFrame : -5 ms
> Bit rate mode : Variable
> Bit rate : 2 278 b/s
> Maximum bit rate : 128 kb/s / 128 kb/s
> Channel(s) : 2 channels
> Channel layout : L R
> Sampling rate : 48.0 kHz
> Frame rate : 46.875 FPS (1024 SPF)
> Compression mode : Lossy
> Stream size : 9.81 KiB (1%)
> Source stream size : 9.82 KiB (1%)
> Language : Italian
> Default : Yes
> Alternate group : 1
> mdhd_Duration : 35280
>
>
> $
>
>
> On Tuesday, November 2, 2021, Andrea paz via

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrew Randrianasulu via Cin 
still a bit strange, shouldn't encoder string from mediainfo indicate
8+10+12 bit instead of just 10?

'x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit'

try to encode 8 and/or 12 bit h265 with normal and multibit build??


full mediainfo:


$ mediainfo ~/storage/downloads/Browser/test-multibit1.mp4
General
Complete name :
/data/data/com.termux/files/home/storage/downloads/Browser/test-multibit1.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/mp41)
File size : 1.66 MiB
Duration : 35 s 280 ms
Overall bit rate mode : Variable
Overall bit rate : 395 kb/s
Writing application : Lavf58.76.100

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L3@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 35 s 240 ms
Bit rate : 386 kb/s
Width : 854 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.038
Stream size : 1.62 MiB (98%)
Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit
Encoding settings : cpuid=039 / frame-threads=4 / wpp / no-pmode /
no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=854x480
/ interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 /
ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud /
no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 /
keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid /
bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 /
hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 /
min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 /
tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd
/ signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra /
strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1
/ subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp /
no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock /
rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast
/ no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 /
psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 /
rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 /
ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree /
zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 /
qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=160:161 /
overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 /
colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 /
max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info /
slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps /
no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 /
no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt
/ no-idr-recovery-sei / analysis-reuse-level=0 /
analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0
/ refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 /
no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 /
copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei /
no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 /
scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 /
decoder-max-rate=0 / no-vbv-live-multi-pass
Color range : Full
Color primaries : BT.2020
Transfer characteristics : BT.2020 (10-bit)
Matrix coefficients : BT.2020 constant
Codec configuration box : hvcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 35 s 280 ms
Source duration : 35 s 301 ms
Source_Duration_LastFrame : -5 ms
Bit rate mode : Variable
Bit rate : 2 278 b/s
Maximum bit rate : 128 kb/s / 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 9.81 KiB (1%)
Source stream size : 9.82 KiB (1%)
Language : Italian
Default : Yes
Alternate group : 1
mdhd_Duration : 35280


$


On Tuesday, November 2, 2021, Andrea paz via Cin 
wrote:

> Sorry, I forgot the videos.
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread mnieuw--- via Cin 
If you have built in that directory before, do a "make clean" before
building. The build process might not detect all changes.

MatN

On Tue, 2 Nov 2021 18:53:13 +0300
Andrew Randrianasulu via Cin  wrote:

> hm, yes, no libx265 in sight... so, hopefully your cin build uses
> statically-linked ffmpeg/x265... but then I have no idea why it works
> for you even without patches... anyway, working is better than
> non-working!
> 
> I also have no idea why appimage (32 bit) fail for you.. may be
> deleting (!) some -dev packages on build server will force Cin to
> build and link to static libs (but if this works - then configure
> option for building everything as static as possible does not work as
> it should?)
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrew Randrianasulu via Cin 
hm, yes, no libx265 in sight... so, hopefully your cin build uses
statically-linked ffmpeg/x265... but then I have no idea why it works for
you even without patches... anyway, working is better than non-working!

I also have no idea why appimage (32 bit) fail for you.. may be deleting
(!) some -dev packages on build server will force Cin to  build and link to
static libs (but if this works - then configure option for building
everything as static as possible does not work as it should?)

On Tuesday, November 2, 2021, Andrea paz 
wrote:

> Doesn't seem to me.
> (I also attach the log of the CinGG build; I don't know if it will help)
> $ ldd cin
>linux-vdso.so.1 (0x7ffc852d2000)
>libX11.so.6 => /usr/lib/libX11.so.6 (0x7efe4197b000)
>libXext.so.6 => /usr/lib/libXext.so.6 (0x7efe41966000)
>libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x7efe41961000)
>libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x7efe41958000)
>libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x7efe41945000)
>libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
> (0x7efe418f6000)
>libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x7efe4182a000)
>liblzma.so.5 => /usr/lib/liblzma.so.5 (0x7efe41801000)
>libpng16.so.16 => /usr/lib/libpng16.so.16 (0x7efe417ca000)
>libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7efe417a9000)
>libz.so.1 => /usr/lib/libz.so.1 (0x7efe4178f000)
>libvdpau.so.1 => /usr/lib/libvdpau.so.1 (0x7efe4178a000)
>libva.so.2 => /usr/lib/libva.so.2 (0x7efe4175b000)
>libva-x11.so.2 => /usr/lib/libva-x11.so.2 (0x7efe41753000)
>libva-drm.so.2 => /usr/lib/libva-drm.so.2 (0x7efe4174e000)
>libGL.so.1 => /usr/lib/libGL.so.1 (0x7efe416c8000)
>libGLU.so.1 => /usr/lib/libGLU.so.1 (0x7efe41672000)
>libXv.so.1 => /usr/lib/libXv.so.1 (0x7efe4166a000)
>libXft.so.2 => /usr/lib/libXft.so.2 (0x7efe4165)
>libasound.so.2 => /usr/lib/libasound.so.2 (0x7efe41568000)
>libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0
> (0x7efe41561000)
>libpulse.so.0 => /usr/lib/libpulse.so.0 (0x7efe4150c000)
>libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x7efe414ee000)
>libdl.so.2 => /usr/lib/libdl.so.2 (0x7efe414e7000)
>libnuma.so.1 => /usr/lib/libnuma.so.1 (0x7efe414d7000)
>libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7efe412c1000)
>libm.so.6 => /usr/lib/libm.so.6 (0x7efe4117d000)
>libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7efe41151000)
>libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7efe41136000)
>libc.so.6 => /usr/lib/libc.so.6 (0x7efe40f6a000)
>libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7efe40f3e000)
>libexpat.so.1 => /usr/lib/libexpat.so.1 (0x7efe40f0e000)
>libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x7efe40e36000)
>libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x7efe40e28000)
>/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
> (0x7efe467ac000)
>libdrm.so.2 => /usr/lib/libdrm.so.2 (0x7efe40e13000)
>libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0
> (0x7efe40d59000)
>libGLX.so.0 => /usr/lib/libGLX.so.0 (0x7efe40d26000)
>libOpenGL.so.0 => /usr/lib/libOpenGL.so.0 (0x7efe40cfa000)
>libXrender.so.1 => /usr/lib/libXrender.so.1 (0x7efe40ced000)
>librt.so.1 => /usr/lib/librt.so.1 (0x7efe40ce2000)
>libpulsecommon-15.0.so =>
> /usr/lib/pulseaudio/libpulsecommon-15.0.so (0x7efe40c57000)
>libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7efe40c02000)
>libudev.so.1 => /usr/lib/libudev.so.1 (0x7efe40bd8000)
>libXau.so.6 => /usr/lib/libXau.so.6 (0x7efe40bd3000)
>libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x7efe40bcb000)
>libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x7efe40ba4000)
>libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7efe40a6e000)
>libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1
> (0x7efe40a4b000)
>libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x7efe409c9000)
>libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x7efe40904000)
>libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x7efe408fa000)
>libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7efe40883000)
>libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x7efe407d8000)
>libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x7efe40799000)
>libopus.so.0 => /usr/lib/libopus.so.0 (0x7efe4073b000)
>libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x7efe4070b000)
>libogg.so.0 => /usr/lib/libogg.so.0 (0x7efe4070)
>libzstd.so.1 => /usr/lib/libzstd.so.1 (0x7efe405f1000)
>liblz4.so.1 => /usr/lib/liblz4.so.1 (0x7efe405ce000)
>

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrew Randrianasulu via Cin 
On Tuesday, November 2, 2021, Andrea paz 
wrote:

> I wouldn't know where to use ldd; could you give me the exact command?


ldd path_to_cin?

and see if it links with external libx265..

But I mostly hoped Phyllis will look into this.

> I tried the following paths:
>
> $ cd /home/paz/cinelerra5/cinelerra-5.1/thirdparty/x265_3.5
> $ ldd x265
> linux-vdso.so.1 (0x7ffc797f4000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f6f51401000)
> librt.so.1 => /usr/lib/librt.so.1 (0x7f6f513f6000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x7f6f513ef000)
> libnuma.so.1 => /usr/lib/libnuma.so.1 (0x7f6f513e1000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f6f511cb000)
> libm.so.6 => /usr/lib/libm.so.6 (0x7f6f51087000)
> libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7f6f51059000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f6f5103e000)
> libc.so.6 => /usr/lib/libc.so.6 (0x7f6f50e72000)
> /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
> (0x7f6f519fd000)
>
> And:
> $ cd /lib
> $ ldd libx265.so
> linux-vdso.so.1 (0x7ffd8bff7000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7faeb0b3b000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x7faeb0b34000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7faeb091e000)
> libm.so.6 => /usr/lib/libm.so.6 (0x7faeb07da000)
> libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7faeb07ae000)
> libc.so.6 => /usr/lib/libc.so.6 (0x7faeb05e2000)
> /usr/lib64/ld-linux-x86-64.so.2 (0x7faeb1e1f000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7faeb05c5000)
>
>
> And then:
> $ ldd libx265.so.199
> linux-vdso.so.1 (0x7fffec574000)
> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7feab9098000)
> libdl.so.2 => /usr/lib/libdl.so.2 (0x7feab9091000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7feab8e7b000)
> libm.so.6 => /usr/lib/libm.so.6 (0x7feab8d37000)
> libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7feab8d0b000)
> libc.so.6 => /usr/lib/libc.so.6 (0x7feab8b3f000)
> /usr/lib64/ld-linux-x86-64.so.2 (0x7feaba37c000)
> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7feab8b22000)
>
> I can't interpret the results or even if I found the right command.
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrea paz via Cin 
I wouldn't know where to use ldd; could you give me the exact command?
I tried the following paths:

$ cd /home/paz/cinelerra5/cinelerra-5.1/thirdparty/x265_3.5
$ ldd x265
linux-vdso.so.1 (0x7ffc797f4000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f6f51401000)
librt.so.1 => /usr/lib/librt.so.1 (0x7f6f513f6000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x7f6f513ef000)
libnuma.so.1 => /usr/lib/libnuma.so.1 (0x7f6f513e1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f6f511cb000)
libm.so.6 => /usr/lib/libm.so.6 (0x7f6f51087000)
libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7f6f51059000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f6f5103e000)
libc.so.6 => /usr/lib/libc.so.6 (0x7f6f50e72000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
(0x7f6f519fd000)

And:
$ cd /lib
$ ldd libx265.so
linux-vdso.so.1 (0x7ffd8bff7000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7faeb0b3b000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x7faeb0b34000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7faeb091e000)
libm.so.6 => /usr/lib/libm.so.6 (0x7faeb07da000)
libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7faeb07ae000)
libc.so.6 => /usr/lib/libc.so.6 (0x7faeb05e2000)
/usr/lib64/ld-linux-x86-64.so.2 (0x7faeb1e1f000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7faeb05c5000)


And then:
$ ldd libx265.so.199
linux-vdso.so.1 (0x7fffec574000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7feab9098000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x7feab9091000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7feab8e7b000)
libm.so.6 => /usr/lib/libm.so.6 (0x7feab8d37000)
libmvec.so.1 => /usr/lib/libmvec.so.1 (0x7feab8d0b000)
libc.so.6 => /usr/lib/libc.so.6 (0x7feab8b3f000)
/usr/lib64/ld-linux-x86-64.so.2 (0x7feaba37c000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7feab8b22000)

I can't interpret the results or even if I found the right command.
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrew Randrianasulu via Cin 
On Tuesday, November 2, 2021, Andrea paz via Cin 
wrote:

> > CinX
>
> Recently Andrew has worked on many patches to extend the encoding of
> CinGG; for example the "compile_multibit_X265.txt" patch. I guess
> compiling CinGG with this patch is equivalent to using
> CinGG-multibit.AppImage. I produced "test-multibit1.mp4" with the
> multibit appimage and I produced "test-multibit2.mp4" with CinGG
> compiled WITHOUT the patch. For both I used the preset:
> "h265-10bit.mp4". The results are the same: both files are encoded
> correctly at 10-bit. There is something I can't understand about the
> functioning of the patches I tried!


well, may be cin in both cases linked to system's libx265 (and this one was
already compiled as multibit)?  Can you check with ldd?


-- 
> Cin mailing list
> [email protected]
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrea paz via Cin 
> CinX

Recently Andrew has worked on many patches to extend the encoding of
CinGG; for example the "compile_multibit_X265.txt" patch. I guess
compiling CinGG with this patch is equivalent to using
CinGG-multibit.AppImage. I produced "test-multibit1.mp4" with the
multibit appimage and I produced "test-multibit2.mp4" with CinGG
compiled WITHOUT the patch. For both I used the preset:
"h265-10bit.mp4". The results are the same: both files are encoded
correctly at 10-bit. There is something I can't understand about the
functioning of the patches I tried!
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Terje J. Hanssen via Cin 



Den 02.11.2021 11:53, skrev Andrea paz via Cin:

All perfect installation and appimage. Thank you.
Two questions:
1- I also tried to build OpenCV along with the source and had no
errors. But the plugins don't appear in the plugins list. Instead
putting manually the plugins in ".../bin/plugins" everything works
normally. (PS: OpenCV has been updated recently, is it possible to
create the most updated copies of the plugins?)
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?

PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to me.



Re 2-
I am not sure about the later route to Cin "multi-bit", but initial the 
Cin "10-bit" (Cinx) was based on x265 (i.e for Blu-ray rendering), while 
the regular Cin is and was 8-bit based on x264, as clarified by Phyllis 
in this earlier thread

https://lists.cinelerra-gg.org/pipermail/cin/2019-January/000121.html

Terje J. H


--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrea paz via Cin 
All perfect installation and appimage. Thank you.
Two questions:
1- I also tried to build OpenCV along with the source and had no
errors. But the plugins don't appear in the plugins list. Instead
putting manually the plugins in ".../bin/plugins" everything works
normally. (PS: OpenCV has been updated recently, is it possible to
create the most updated copies of the plugins?)
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?

PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to me.
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin

Re: [Cin] Updated CinGG release for downloading the AppImage

2021-11-02 Thread Andrea paz via Cin 
Il giorno dom 31 ott 2021 alle ore 21:39 Phyllis Smith via Cin
 ha scritto:
>
> The October 31, 2021 CinGG releases are at:
>
> https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64.AppImage
> https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64-older_distros.AppImage
> https://cinelerra-gg.org/download/images/CinGG-20211031-multibit.AppImage
> https://cinelerra-gg.org/download/images/CinGG-20211031-i386.AppImage
>
> GIT for Cinelerra-GG has the following changes from 10/01/2021-10/31/2021
> The instructions for using AppImage in the file, README_appimage.txt, was 
> updated by Terje.
> Cineform, DPX, MXF additional render formats have been provided as used in 
> ffmpeg by Andrea.
> Title video plugin now correctly fades in/out as reported by Camille. This 
> bug had been around a
>   very long time (see BT #559) with the fix now done by a Freelancer.
> Many plugins were being reloaded in the AppImage on every start which could 
> take awhile on some
>  computers. MatN has expertly fixed this and changed that of the 
> Cinelerra_plugins also. Note that
>  any time a new release/build is started for the first time, it will always 
> reload the plugins but each
>  subsequent usage of that image will no longer require reloads as long as you 
> use the same .bcast5.
> Andrew-R contributions:
>  Opus and aom thirdparty libraries have had the examples and extras deleted 
> to save build time.
>  In support of Android/Termux CinGG compile, patches for libwepb and libaom 
> have been added.
>  Defaults for mxf render format have now been established.
> Hungarian translation as created using google with a 90% automated procedure 
> is now available. To
> use, keyin the following in a window: LANGUAGE=hu 
> ./CinGG-20211031-x86_64.AppImage
>
>
> --
> Cin mailing list
> [email protected]
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- 
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin