another set of test profiles
hopefully with very silly top-line-as-comment error fixed SORRY!
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders? On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input. Only 1) av1_qsv.webm of them worked, so hopefully I have installed and tested them correctly(?) 1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12 works with pixelformats nv12 AND p010le 2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12 doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format 3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main not available? 4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12 doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format: 5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12 doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format: 6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video with cin launched as bin/cin from this directory? sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked. may be you need additional dfl file in ffmpeg/audio ? can you test without audio (checkbox audio unchecked)? Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
with cin launched as bin/cin from this directory?
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
can you test without audio (checkbox audio unchecked)?
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
A bit of nuclear option: attached ALL profiles I am testing in /usr/share/cin/fmpeg/ Note that you need to check permissions too! or root-copied profile will be not readable by user so far test "worked" (note that this is without any real usable GPU implementation for oneVPL): bash-5.1$ cin Cinelerra Infinity - built: Oct 13 2024 22:20:38 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2024 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc61.3.100 Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. RenderFarmClient::main_loop: client started [av1_qsv @ 0xc82a24c0] Error creating a MFX session: -9. FFMPEG::open_encoder err: Unknown error occurred int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/dev/shm/yuv-test-reenc-rgba8-mpeg-range.webm Render::render_single: Session finished. [h264_qsv @ 0xe8ceaf80] Error creating a MFX session: -9. FFMPEG::open_encoder err: Unknown error occurred int FFMPEG::open_encoder(const char*, const char*): open failed h264_qsv:/dev/shm/yuv-test-reenc-rgba8-mpeg-range.mp4 Render::render_single: Session finished. [hevc_qsv @ 0xd2c3c240] Error creating a MFX session: -9. FFMPEG::open_encoder err: Unknown error occurred int FFMPEG::open_encoder(const char*, const char*): open failed hevc_qsv:/dev/shm/yuv-test-reenc-rgba8-mpeg-range.mp4 Render::render_single: Session finished. int FFMPEG::init_encoder(const char*): mismatch audio/video file format: /dev/shm/yuv-test-reenc-rgba8-mpeg-range.mp4 Render::render_single: Session finished. [av1_qsv @ 0xd41ed980] Error creating a MFX session: -9. FFMPEG::open_encoder err: Unknown error occurred int FFMPEG::open_encoder(const char*, const char*): open failed av1_qsv:/dev/shm/yuv-test-reenc-rgba8-mpeg-range.mp4 Render::render_single: Session finished. On Mon, Oct 14, 2024 at 9:03 PM Andrew Randrianasulu < [email protected]> wrote:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
with cin launched as bin/cin from this directory?
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
can you test without audio (checkbox audio unchecked)?
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu <[email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?" But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm That is no av1_qsv.dfl there!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally. on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install. so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video! Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
Den 14.10.2024 21:30, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu <[email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
Sorry, my fault that I had "lost" that bin level in the path. Actually I also found the mentioned dfl file there.. I save the complete set of test profiles from this first post in /home/cinelerra/cinelerra-5.1/bin/ffmpeg/video and retest them
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally.
on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install.
so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video!
Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg
sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
Den 14.10.2024 21:53, skrev Terje J. Hanssen:
Den 14.10.2024 21:30, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu <[email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
Sorry, my fault that I had "lost" that bin level in the path. Actually I also found the mentioned dfl file there.. I save the complete set of test profiles from this first post in /home/cinelerra/cinelerra-5.1/bin/ffmpeg/video and retest them
That went much better. Now 5 of 6 profiles work, except 2) that still not work: 2) dv01_07_av1_qsv.mp4 Audio preset: h264.mp4 Video compression: av1_qsv.mp4 Pixels: nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format: /Videoklipp/QSV/dv01_07_av1_qsv.mp4 Doesn't work with Audio disabled either
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally.
on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install.
so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video!
Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg
sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
пн, 14 окт. 2024 г., 23:55 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 21:53, skrev Terje J. Hanssen:
Den 14.10.2024 21:30, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
Sorry, my fault that I had "lost" that bin level in the path. Actually I also found the mentioned dfl file there.. I save the complete set of test profiles from this first post in /home/cinelerra/cinelerra-5.1/bin/ffmpeg/video and retest them
That went much better. Now 5 of 6 profiles work, except 2) that still not work:
2) dv01_07_av1_qsv.mp4 Audio preset: h264.mp4 Video compression: av1_qsv.mp4 Pixels: nv12
int FFMPEG::init_encoder(const char*): mismatch audio/video file format: /Videoklipp/QSV/dv01_07_av1_qsv.mp4
Doesn't work with Audio disabled either
can you double-check that first line in this file reads mp4 av1_qsv and comment (line starting with #) is second? may be I missed this one ...
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally.
on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install.
so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video!
Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg
sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
Den 14.10.2024 22:58, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 23:55 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 21:53, skrev Terje J. Hanssen:
Den 14.10.2024 21:30, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu <[email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
Sorry, my fault that I had "lost" that bin level in the path. Actually I also found the mentioned dfl file there.. I save the complete set of test profiles from this first post in /home/cinelerra/cinelerra-5.1/bin/ffmpeg/video and retest them
That went much better. Now 5 of 6 profiles work, except 2) that still not work:
2) dv01_07_av1_qsv.mp4 Audio preset: h264.mp4 Video compression: av1_qsv.mp4 Pixels: nv12
int FFMPEG::init_encoder(const char*): mismatch audio/video file format: /Videoklipp/QSV/dv01_07_av1_qsv.mp4
Doesn't work with Audio disabled either
can you double-check that first line in this file reads
mp4 av1_qsv
and comment (line starting with #) is second?
may be I missed this one ...
No, the # comment line was first (see initial 2) below here). I edited it and now it works :) Your last "all-profiles.tar.gz" I have temporary extracted and saved in $HOME/tmp/usr/share/cin/ffmpeg/ Can I copy all those (video and audio) to my /home/cinelerra/cinelerra-5.1/bin/ffmpeg to access them from custom /home/cinelerra/cinelerra-5.1/bin/cin ? I verified that av1_qsv.mp4 is corrected here.
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally.
on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install.
so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video!
Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg
sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
вт, 15 окт. 2024 г., 00:29 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 22:58, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 23:55 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 21:53, skrev Terje J. Hanssen:
Den 14.10.2024 21:30, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 22:20 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 20:03, skrev Andrew Randrianasulu:
On Mon, Oct 14, 2024 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
пн, 14 окт. 2024 г., 18:58 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
> hopefully with very silly top-line-as-comment error fixed > > SORRY! > >
I saved the 6 profiles in ffmpeg/video and tested them with SD-DV input.
in cinelerra-5.1/bin/ffmpeg/video
Yes, in /home/cinelerra/cinelerra-5.1/ffmpeg/video
you need either execute make install or put them in cinelerra/bin/ffmpeg/video manually
Sorry, my fault that I had "lost" that bin level in the path. Actually I also found the mentioned dfl file there.. I save the complete set of test profiles from this first post in /home/cinelerra/cinelerra-5.1/bin/ffmpeg/video and retest them
That went much better. Now 5 of 6 profiles work, except 2) that still not work:
2) dv01_07_av1_qsv.mp4 Audio preset: h264.mp4 Video compression: av1_qsv.mp4 Pixels: nv12
int FFMPEG::init_encoder(const char*): mismatch audio/video file format: /Videoklipp/QSV/dv01_07_av1_qsv.mp4
Doesn't work with Audio disabled either
can you double-check that first line in this file reads
mp4 av1_qsv
and comment (line starting with #) is second?
may be I missed this one ...
No, the # comment line was first (see initial 2) below here). I edited it and now it works :)
\o/
Your last "all-profiles.tar.gz" I have temporary extracted and saved in $HOME/tmp/usr/share/cin/ffmpeg/ Can I copy all those (video and audio) to my /home/cinelerra/cinelerra-5.1/bin/ffmpeg to access them from custom /home/cinelerra/cinelerra-5.1/bin/cin ? I verified that av1_qsv.mp4 is corrected here.
you probably can save current working set (full ffmpeg folder) before copying ones I "packaged". But, again, may be better to resume such activity after some good sleep.
with cin launched as bin/cin from this directory?
/home/cinelerra/cinelerra-5.1# bin/cin (all testing as root)
so, permission problem is not for you .....
sorry for such pedantry, but I get same mismatch and generally just moving commentary to second line worked.
may be you need additional dfl file in ffmpeg/audio ?
You remember I also got - and thought I saved 13/10: "can you test those two attached files (profile for av1_qsv.webm and default file for av1_qsv, put both in bin/ffmpeg/video) ?"
But I have only /home/cinelerra/cinelerra-5.1/ffmpeg/video # lls -1 av1*qsv* av1_qsv.mp4 av1_qsv.webm
That is no av1_qsv.dfl there!
note, cinelerra-5.1/ffmpeg is that git controls, normally.
on make install files from there copied to bin/ffmpeg if single-user or into /usr/share/cin/ffmpeg if system install.
so please double-check that files you get from me in bin/ffmpeg/video, not just in ffmpeg/video!
Also check out nuclear option (tar.gz) You can see into it via say midnight commander (enter on archive) and copy files you need to cinelerra-5.1/bin/ffmpeg
sorry for confusion!
can you test without audio (checkbox audio unchecked)?
Tested 2) below without audio (unchecked): same error
Only 1) av1_qsv.webm of them worked, so hopefully I have installed and
tested them correctly(?)
1) av1_qsv.webm: webm av1_qsv # only usable with ext. ffmpeg cin_pix_fmt=nv12
works with pixelformats nv12 AND p010le
2) av1_qsv.mp4 # only usable with ext. ffmpeg mp4 av1_qsv cin_pix_fmt=nv12
doesn't work: pixelformat nv12 int FFMPEG::init_encoder(const char*): mismatch audio/video file format
does adding attached file into ffmpeg/audio/ fix this?
Sorry, no change for 2) But is the attached av1_qsv.webm for av1_qsv.mp4 also, where audio preset is h264.mp4 and no libvorbis visible option cat /home/cinelerra/cinelerra-5.1/ffmpeg/audio/av1_qsv.webm webm libvorbis
3) av1_vaapi.mp4 mp4 av1_vaapi cin_hw_dev=vaapi profile=main
not available?
4) h264_qsv.mp4 mp4 h264_qsv # only usable with ext. ffmpeg profile=high cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
5) hevc_qsv.mp4 mp4 hevc_qsv # only usable with ext. ffmpeg, another pixfmt is yuyv422 profile=main cin_pix_fmt=nv12
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
6) cat vp9_qsv.mp4 mp4 vp9_qsv # only usable with ext. ffmpeg
doesn't work: int FFMPEG::init_encoder(const char*): mismatch audio/video file format:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone. For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva. QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me). speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system). But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <
[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements. In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
On Sun, Oct 13, 2024 at 2:36 PM Andrew Randrianasulu via Cin <
[email protected]> wrote:
hopefully with very silly top-line-as-comment error fixed
SORRY!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrey replied to me in a previous thread: Hardware acceleration methods Sat, 14 Sep 2024 08:55:11 +0300 https://lists.cinelerra-gg.org/pipermail/cin/2024-September/008621.html
Is there something that prevent typical QSV to be prebuilt in the CinGG/FFmpeg rpm?
The ffmpeg not installed on my suse build host. If you how to enable QSV, I'll change the build script.
Is this a "path" we can continue with here?
Den 18.10.2024 11:33, skrev Terje J. Hanssen:
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrey replied to me in a previous thread: Hardware acceleration methods Sat, 14 Sep 2024 08:55:11 +0300 https://lists.cinelerra-gg.org/pipermail/cin/2024-September/008621.html
Is there something that prevent typical QSV to be prebuilt in the CinGG/FFmpeg rpm?
The ffmpeg not installed on my suse build host. If you how to enable QSV, I'll change the build script.
Is this a "path" we can continue with here?
Isn't it so that to apply oneVPL in prebuilt and packaged Cingg, it's internal ffmpeg has to be enabled with oneVPL? Please correct me and explain better ......
пт, 18 окт. 2024 г., 13:48 Terje J. Hanssen <[email protected]>:
Den 18.10.2024 11:33, skrev Terje J. Hanssen:
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrey replied to me in a previous thread: Hardware acceleration methods Sat, 14 Sep 2024 08:55:11 +0300 https://lists.cinelerra-gg.org/pipermail/cin/2024-September/008621.html
Is there something that prevent typical QSV to be prebuilt in the CinGG/FFmpeg rpm?
The ffmpeg not installed on my suse build host. If you how to enable QSV, I'll change the build script.
Is this a "path" we can continue with here?
Isn't it so that to apply oneVPL in prebuilt and packaged Cingg, it's internal ffmpeg has to be enabled with oneVPL? Please correct me and explain better ......
There should be another patch I sent both to list and you, it should enable building internal ffmpeg with onevpl if it present on host system ..... can you try it?
From a previous thread: Re: [Cin] another set of test profiles Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz so replace 2020 something with 20241031 but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime Appimage should be simpler from existing source directory just run bld_appimage.sh but be sure to get additional file and put it where it belong as described in comment: ===== # Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool". ==== probably /usr/local/bin will be simplest place to put it as root?
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg -- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " Thanks, I think I got AppImage(?) built and it seemingly runs OK. That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage" /Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory Cin # du -sh AppDir 216M AppDir /Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share /Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps --------------------------- So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage ./CinGG-20241031-x86_64.AppImage I notice the prebuild has no symlink as in the above AppDir My own built appimage has not startup errors: (AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ? How to possibly build an equivalent single AppImage file directly?
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed? I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed. Cin # zypper se squash Loading repository data... Reading installed packages... S | Name | Summary | Type ---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more: /Cin # sh ./bld_appimage.sh ..........snip Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN -- Deploying icons -- Deploying icon image/cin.svg -- Deploying desktop files -- Deploying desktop file image/cin.desktop -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg -- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so) ====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?) Squashfs image uses (null) compression, this version supports only xz, zlib. ERROR: appimage_shall_not_be_integrated : sqfs_open_image error: /usr/local/bin/appimagetool-x86_64.AppImage AppImageLauncher error: appimage_shall_not_be_integrated() failed (returned -1) Squashfs image uses (null) compression, this version supports only xz, zlib. ERROR: appimage_is_terminal_app : sqfs_open_image error: /usr/local/bin/appimagetool-x86_64.AppImage AppImageLauncher error: appimage_is_terminal_app() failed (returned -1) fusermount3 version: 3.16.2 execv error: No such file or directory localhost:/Cin # localhost:/Cin # du -sh AppDir 216M AppDir localhost:/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 02:50 . drwxr-xr-x 31 root root 4096 Dec 6 02:50 .. lrwxrwxrwx 1 root root 11 Dec 6 02:50 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 02:50 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 02:50 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 02:50 usr localhost:/Cin # localhost:/Cin # ls /usr/local/bin/appimagetool-x86_64.AppImage /usr/local/bin/appimagetool-x86_64.AppImage localhost:/Cin # localhost:/Cin # ls -la /usr/local/bin/appimagetool-x86_64.AppImage -rwxr-xr-x 1 root root 12718856 Dec 6
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type
---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602 ==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either --comp xz or --comp gzip to appimagetool to have it work with AppImageLauncher. ===== workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Squashfs image uses (null) compression, this version supports only xz, zlib. ERROR: appimage_shall_not_be_integrated : sqfs_open_image error: /usr/local/bin/appimagetool-x86_64.AppImage AppImageLauncher error: appimage_shall_not_be_integrated() failed (returned -1) Squashfs image uses (null) compression, this version supports only xz, zlib. ERROR: appimage_is_terminal_app : sqfs_open_image error: /usr/local/bin/appimagetool-x86_64.AppImage AppImageLauncher error: appimage_is_terminal_app() failed (returned -1) fusermount3 version: 3.16.2 execv error: No such file or directory localhost:/Cin # localhost:/Cin # du -sh AppDir 216M AppDir localhost:/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 02:50 . drwxr-xr-x 31 root root 4096 Dec 6 02:50 .. lrwxrwxrwx 1 root root 11 Dec 6 02:50 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 02:50 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 02:50 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 02:50 usr localhost:/Cin # localhost:/Cin # ls /usr/local/bin/appimagetool-x86_64.AppImage /usr/local/bin/appimagetool-x86_64.AppImage localhost:/Cin # localhost:/Cin # ls -la /usr/local/bin/appimagetool-x86_64.AppImage -rwxr-xr-x 1 root root 12718856 Dec 6
Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 render format (after successfully tested of course); but what about the QSV encoders?
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602
==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either |--comp xz| or |--comp gzip| to appimagetool to have it work with AppImageLauncher.
=====
workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Yes, I have also had the impression that Appimagelauncher are old and outdated. So I remove it here, but keep the appimaged installed (?) # zypper se appimage Loading repository data... Reading installed packages... S | Name | Summary | Type ---+-----------------------+----------------------------------------+----------- i+ | appimaged | Daemon handles (un)registering AppIm-> | package | appimaged | Daemon handles (un)registering AppIm-> | srcpackage | appimaged-debuginfo | Debug information for package appima-> | package | appimaged-debugsource | Debug sources for package appimaged | package i+ | appimagelauncher | AppImageLauncher built using CMake | package | obs-service-appimage | Handles source downloads defined in -> | package # zypper se -is appimage Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+------------------+---------+----------------------+--------+------------------------- i+ | appimaged | package | 10-2.1 | x86_64 | openSUSE-Slowroll-Update i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 | x86_64 | (System Packages) # zypper rm appimagelauncher ----------------------------- /Cin # sh ./bld_appimage.sh ......snip -- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher not found at /usr/bin/AppImageLauncher, launching AppImage directly: /usr/local/bin/appimagetool-x86_64.AppImage [appimagelauncher-binfmt-bypass/lib] WARNING: could not find preload library path, using temporary file fusermount3 version: 3.16.2 execv error: No such file or directory ----------- Error and still no AppImage file has been created: /Cin # du -sh AppDir 216M AppDir /Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 11:00 . drwxr-xr-x 31 root root 4096 Dec 6 10:59 .. lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>:
> Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 > render format (after successfully tested of course); but what about the QSV > encoders? >
wait for Terje's testing OR try to build oneVPL-cpu (it sort of circles back to different branch of ffmpeg, so ffmpeg will think it uses qsv but it in fact will use another ffmpeg .... well, in theory! it does not work for me on 32-bit!)
> > I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type
---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602
==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either --comp xz or --comp gzip to appimagetool to have it work with AppImageLauncher.
=====
workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Yes, I have also had the impression that Appimagelauncher are old and outdated. So I remove it here, but keep the appimaged installed (?)
# zypper se appimage Loading repository data... Reading installed packages...
S | Name | Summary | Type
---+-----------------------+----------------------------------------+----------- i+ | appimaged | Daemon handles (un)registering AppIm-> | package | appimaged | Daemon handles (un)registering AppIm-> | srcpackage | appimaged-debuginfo | Debug information for package appima-> | package | appimaged-debugsource | Debug sources for package appimaged | package i+ | appimagelauncher | AppImageLauncher built using CMake | package | obs-service-appimage | Handles source downloads defined in -> | package
# zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+----------------------+--------+------------------------- i+ | appimaged | package | 10-2.1 | x86_64 | openSUSE-Slowroll-Update i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 | x86_64 | (System Packages)
# zypper rm appimagelauncher
-----------------------------
/Cin # sh ./bld_appimage.sh ......snip
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher not found at /usr/bin/AppImageLauncher, launching AppImage directly: /usr/local/bin/appimagetool-x86_64.AppImage [appimagelauncher-binfmt-bypass/lib] WARNING: could not find preload library path, using temporary file fusermount3 version: 3.16.2 execv error: No such file or directory
-----------
Error and still no AppImage file has been created:
/Cin # du -sh AppDir 216M AppDir
/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 11:00 . drwxr-xr-x 31 root root 4096 Dec 6 10:59 .. lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
there must be appimage.log in same directory with bld_appumage.sh check it? appimage should appear in same directory, in other words our source tree root. I think something still not installed. squashfstools-ng ? /usr/local/bin/appimagetool-x86_64.AppImage may be this one does have --help parameter? if it allows for setting compression may be rename it new name, and made script calling renamed binary with hardcoded compression argument? sorry, appimage does not work on termux or on NetBSD, so I am a bit out of help here.
Den 06.12.2024 11:48, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected]>:
Den 14.10.2024 00:38, skrev Andrew Randrianasulu: > > пн, 14 окт. 2024 г., 01:36 Phyllis Smith > <[email protected]>: > > Andrew, so it seems prudent to check > into GIT, the av1_vaapi.mp4 render > format (after successfully tested of > course); but what about the QSV > encoders? > > > > wait for Terje's testing OR try to build > oneVPL-cpu (it sort of circles back to > different branch of ffmpeg, so ffmpeg > will think it uses qsv but it in fact > will use another ffmpeg .... well, in > theory! it does not work for me on 32-bit!) > >
I wonder if Hw accellerated encoding support via Vaapi and QSV is to be embedded in future Cingg Appimage and/or packages if possible? What about a list of supported dGPUs/iGPUs?
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602
==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either |--comp xz| or |--comp gzip| to appimagetool to have it work with AppImageLauncher.
=====
workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Yes, I have also had the impression that Appimagelauncher are old and outdated. So I remove it here, but keep the appimaged installed (?)
# zypper se appimage Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+-----------------------+----------------------------------------+----------- i+ | appimaged | Daemon handles (un)registering AppIm-> | package | appimaged | Daemon handles (un)registering AppIm-> | srcpackage | appimaged-debuginfo | Debug information for package appima-> | package | appimaged-debugsource | Debug sources for package appimaged | package i+ | appimagelauncher | AppImageLauncher built using CMake | package | obs-service-appimage | Handles source downloads defined in -> | package
# zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------+---------+----------------------+--------+------------------------- i+ | appimaged | package | 10-2.1 | x86_64 | openSUSE-Slowroll-Update i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 | x86_64 | (System Packages)
# zypper rm appimagelauncher
-----------------------------
/Cin # sh ./bld_appimage.sh ......snip
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher not found at /usr/bin/AppImageLauncher, launching AppImage directly: /usr/local/bin/appimagetool-x86_64.AppImage [appimagelauncher-binfmt-bypass/lib] WARNING: could not find preload library path, using temporary file fusermount3 version: 3.16.2 execv error: No such file or directory
-----------
Error and still no AppImage file has been created:
/Cin # du -sh AppDir 216M AppDir
/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 11:00 . drwxr-xr-x 31 root root 4096 Dec 6 10:59 .. lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
there must be appimage.log in same directory with bld_appumage.sh
check it?
Yes, appimage.log is there, but indeed smaller than my own saved terminal output to bld_appimage.log The tail is identical in both as shown above.
appimage should appear in same directory, in other words our source tree root.
I think something still not installed.
squashfstools-ng ?
No such package available; the most similar is the installed squashfuse-tools. All squash packages available and installed are S | Name | Summary | Type ---+------------------+----------------------------------------------------+------ i+ | libsquashfuse0 | FUSE module to mount squashfs images | pakke i | squashfs | A Read-Only File System with Efficient Compression | pakke i+ | squashfuse | FUSE module to mount squashfs images | pakke i+ | squashfuse-devel | FUSE module to mount squashfs images | pakke i+ | squashfuse-tools | Squafs Tools for squashfsfuse | pakke
/usr/local/bin/appimagetool-x86_64.AppImage
may be this one does have --help parameter?
if it allows for setting compression may be rename it new name, and made script calling renamed binary with hardcoded compression argument?
The --help didn't output compression setting. However the Readme contains among Application Options: https://github.com/AppImage/appimagetool?tab=readme-ov-file#appimagetool--- --comp Squashfs compression
sorry, appimage does not work on termux or on NetBSD, so I am a bit out of help here.
Yes, I'm stuck and put Appimage file on hold (yet, the AppDir binary looked promising) -------------
пт, 6 дек. 2024 г., 18:12 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 11:48, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen <[email protected] >:
> > Den 14.10.2024 00:38, skrev Andrew Randrianasulu: > > > пн, 14 окт. 2024 г., 01:36 Phyllis Smith <[email protected]>: > >> Andrew, so it seems prudent to check into GIT, the av1_vaapi.mp4 >> render format (after successfully tested of course); but what about the QSV >> encoders? >> > > > wait for Terje's testing OR try to build oneVPL-cpu (it sort of > circles back to different branch of ffmpeg, so ffmpeg will think it uses > qsv but it in fact will use another ffmpeg .... well, in theory! it does > not work for me on 32-bit!) > >> >> > I wonder if Hw accellerated encoding support via Vaapi and QSV is to > be embedded in future Cingg Appimage and/or packages if possible? > What about a list of supported dGPUs/iGPUs? >
Problem is - QSV/vaapi basically search for driver component and this one might be in different location on different distros, and interface between two also not set in stone.
For appimage you can just unpack them and remove libva.so so on startup cingg will link to system's libva.
QSV as we learned is another layer with their own runtime path for yet another set of driver components. So, while building libvpl itself is relatively easily making sure it finds its drivers is not easy (at least for me).
speaking about GPU list I think it will be fairly short, you,Phyllis and Andrea probably only ones who use it and report back. Stephan noticed some troubles and reverted back to software. I can test nvdec/nvenc on livecd but this is not my everyday setup (Nvidia proprietary drivers enforce 64-bit system).
But well, feel free to post short summary of that works on your GPUs in cingg as another thread, hopefully others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type
---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602
==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either --comp xz or --comp gzip to appimagetool to have it work with AppImageLauncher.
=====
workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Yes, I have also had the impression that Appimagelauncher are old and outdated. So I remove it here, but keep the appimaged installed (?)
# zypper se appimage Loading repository data... Reading installed packages...
S | Name | Summary | Type
---+-----------------------+----------------------------------------+----------- i+ | appimaged | Daemon handles (un)registering AppIm-> | package | appimaged | Daemon handles (un)registering AppIm-> | srcpackage | appimaged-debuginfo | Debug information for package appima-> | package | appimaged-debugsource | Debug sources for package appimaged | package i+ | appimagelauncher | AppImageLauncher built using CMake | package | obs-service-appimage | Handles source downloads defined in -> | package
# zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+----------------------+--------+------------------------- i+ | appimaged | package | 10-2.1 | x86_64 | openSUSE-Slowroll-Update i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 | x86_64 | (System Packages)
# zypper rm appimagelauncher
-----------------------------
/Cin # sh ./bld_appimage.sh ......snip
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher not found at /usr/bin/AppImageLauncher, launching AppImage directly: /usr/local/bin/appimagetool-x86_64.AppImage [appimagelauncher-binfmt-bypass/lib] WARNING: could not find preload library path, using temporary file fusermount3 version: 3.16.2 execv error: No such file or directory
-----------
Error and still no AppImage file has been created:
/Cin # du -sh AppDir 216M AppDir
/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 11:00 . drwxr-xr-x 31 root root 4096 Dec 6 10:59 .. lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
there must be appimage.log in same directory with bld_appumage.sh
check it?
Yes, appimage.log is there, but indeed smaller than my own saved terminal output to bld_appimage.log The tail is identical in both as shown above.
appimage should appear in same directory, in other words our source tree root.
I think something still not installed.
squashfstools-ng ?
No such package available; the most similar is the installed squashfuse-tools. All squash packages available and installed are
S | Name | Summary | Type
---+------------------+----------------------------------------------------+------ i+ | libsquashfuse0 | FUSE module to mount squashfs images | pakke i | squashfs | A Read-Only File System with Efficient Compression | pakke i+ | squashfuse | FUSE module to mount squashfs images | pakke i+ | squashfuse-devel | FUSE module to mount squashfs images | pakke i+ | squashfuse-tools | Squafs Tools for squashfsfuse | pakke
/usr/local/bin/appimagetool-x86_64.AppImage
may be this one does have --help parameter?
if it allows for setting compression may be rename it new name, and made script calling renamed binary with hardcoded compression argument?
The --help didn't output compression setting. However the Readme contains among Application Options: https://github.com/AppImage/appimagetool?tab=readme-ov-file#appimagetool ---
--comp Squashfs compression
sorry, appimage does not work on termux or on NetBSD, so I am a bit out of help here.
Yes, I'm stuck and put Appimage file on hold (yet, the AppDir binary looked promising) -------------
may be run appimagetool manually with appdir directory as argument, like in this question? https://stackoverflow.com/questions/64564820/how-to-use-appimagetool-to-crea... it should output long text saying among other things "Generating squashfs..." if this does not work may be try older appimagetool and not latest (from 2021 instead of 2023)?
Den 06.12.2024 23:06, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 18:12 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 11:48, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 13:35 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 04:32, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 05:14 Terje J. Hanssen <[email protected]>:
Den 06.12.2024 01:08, skrev Andrew Randrianasulu:
пт, 6 дек. 2024 г., 02:06 Terje J. Hanssen <[email protected]>:
Den 03.12.2024 22:20, skrev Andrew Randrianasulu:
вт, 3 дек. 2024 г., 23:59 Terje J. Hanssen <[email protected]>:
From a previous thread: Re: [Cin] another set of test profiles
Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <[email protected]>:
Den 17.10.2024 13:51, skrev Andrew Randrianasulu: > > чт, 17 окт. 2024 г., 13:40 Terje J. > Hanssen <[email protected]>: > > > Den 14.10.2024 00:38, skrev Andrew > Randrianasulu: >> >> пн, 14 окт. 2024 г., 01:36 Phyllis >> Smith <[email protected]>: >> >> Andrew, so it seems prudent to >> check into GIT, the >> av1_vaapi.mp4 render format >> (after successfully tested of >> course); but what about the QSV >> encoders? >> >> >> >> wait for Terje's testing OR try to >> build oneVPL-cpu (it sort of >> circles back to different branch of >> ffmpeg, so ffmpeg will think it >> uses qsv but it in fact will use >> another ffmpeg .... well, in >> theory! it does not work for me on >> 32-bit!) >> >> > > I wonder if Hw accellerated encoding > support via Vaapi and QSV is to be > embedded in future Cingg Appimage > and/or packages if possible? > What about a list of supported > dGPUs/iGPUs? > > > Problem is - QSV/vaapi basically search > for driver component and this one might > be in different location on different > distros, and interface between two also > not set in stone. > > For appimage you can just unpack them > and remove libva.so so on startup cingg > will link to system's libva. > > QSV as we learned is another layer with > their own runtime path for yet another > set of driver components. So, while > building libvpl itself is relatively > easily making sure it finds its drivers > is not easy (at least for me). > > speaking about GPU list I think it will > be fairly short, you,Phyllis and Andrea > probably only ones who use it and report > back. Stephan noticed some troubles and > reverted back to software. I can test > nvdec/nvenc on livecd but this is not my > everyday setup (Nvidia proprietary > drivers enforce 64-bit system). > > But well, feel free to post short > summary of that works on your GPUs in > cingg as another thread, hopefully > others will chime in!
If we get available a packaged Cingg test build (rpm/Leap for me), it would be more useful to do this test. Then I have available three gen. Intel, legacy Skylake/Kabylake iGPUs and current DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks like it past away.
I think you can build rpm yourself, but for this we need to update spec file, so it will point at new source and add openvpl as requirements.
In meantime you can just make your own appimage from just build cingg-with-system-ffmpeg, so it hopefully will not be lost after few system updates.
Andrew, I don't know how busy you are currently with other tasks, but i case you have time, I would be interested to fulfill this rpm and (possibly Appimage) exercise? That is from my current build with third-party (internal) ffmpeg7.0.
for rpm you need to edit blds/cinelerra.spec at the very top there is date, I think latest tar version is
https://cinelerra-gg.org/download/src/cin_5.1.20241031-src.tgz
so replace 2020 something with 20241031
but then it need to be patched up, and I do not have tested procedure for doing this. Probably rpm should wait until new tagged release .... you can search for rpmbuild command on your system and read its manpage/help and may be test run it on some other (faster to rebuild) .spec file in meantime
Appimage should be simpler from existing source directory
just run
bld_appimage.sh
but be sure to get additional file and put it where it belong as described in comment: =====
# Get the appropriate appimagetool from https://github.com/AppImage/AppImageKit/releases # and put it in your path. Only install the version for your platform # and mark it executable. The file name must start with "appimagetool".
====
probably /usr/local/bin will be simplest place to put it as root?
/Cin # sh ./bld_appimage.sh .....snip -- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" "
Thanks, I think I got AppImage(?) built and it seemingly runs OK.
That is when I found the CinGG executable file, because I expected a file somewhere with a name "CinGG*.AppImage"
/Cin # file -sh AppDir/* AppDir/AppRun: symbolic link to usr/bin/cin AppDir/cin.desktop: symbolic link to usr/share/applications/cin.desktop AppDir/cin.svg: symbolic link to usr/share/icons/hicolor/scalable/apps/cin.svg AppDir/usr: directory
Cin # du -sh AppDir 216M AppDir
/Cin # du -sh AppDir/*/* 198M AppDir/usr/bin 19M AppDir/usr/lib 100K AppDir/usr/share
/Cin # AppDir/usr/bin/cin Cinelerra Infinity - built: Nov 20 2024 22:06:05 ....... BC_DisplayInfo::gl_fb_config failed build plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/plugins PluginFFilter::new_ffilter(overlay_qsv) err: Input/output error PluginFFilter::new_ffilter(hstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(vstack_qsv) err: Operation not permitted PluginFFilter::new_ffilter(xstack_qsv) err: Operation not permitted build lv2 index for: $CIN_PATH/lv2 build ladspa plugin index for: /home/cinelerra/cinelerra-5.1/AppDir/usr/bin/ladspa
Loaded hdv09_04.m2t (tff interlaced) Tested rendering using preset hevc_qsv_10b420 which worked fine
libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 19.320 secs, 309.110 fps
---------------------------
So some questions when comparing the above AppDir result with the pre-build Appimage file I download to and run from
du -sh ~/Applications/Cin* 171M CinGG-20241031-x86_64.AppImage
./CinGG-20241031-x86_64.AppImage
I notice the prebuild has no symlink as in the above AppDir
My own built appimage has not startup errors:
(AppImageLauncher:127697): GdkPixbuf-CRITICAL **: 23:56:28.831: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
I wonder the larger total space 216M vs 171M is due to oneVPL and maybe some other additional libs ?
How to possibly build an equivalent single AppImage file directly?
make sure you have mksquashfs installed?
No "mksquashfs" package installed or found, but "quashfs" was installed.
Cin # zypper se squash Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+------------------+----------------------------------------------------+-------- | libsquashfuse0 | FUSE module to mount squashfs images | package i | squashfs | A Read-Only File System with Efficient Compression | package | squashfuse | FUSE module to mount squashfs images | package | squashfuse-devel | FUSE module to mount squashfs images | package | squashfuse-tools | Squafs Tools for squashfsfuse | package
Not sure if they are required, but add-installed also the other on this list.
I think last part (compressing appdir into single file and bolting on run-time decompressor to it) failed in your case .....
Tried bld_appimage once more:
/Cin # sh ./bld_appimage.sh
..........snip
Setting rpath in ELF file AppDir/usr/lib/libz.so.1.3.1 to $ORIGIN
-- Deploying icons -- Deploying icon image/cin.svg
-- Deploying desktop files -- Deploying desktop file image/cin.desktop
-- Copying files into AppDir -- Copying file image/cin.desktop to AppDir/usr/share/applications/cin.desktop Copying file image/cin.svg to AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " /usr/bin/AppImageLauncher: /lib64/libcurl.so.4: no version information available (required by /usr/bin/../lib/x86_64-linux-gnu/appimagelauncher/libappimageupdate.so)
====>>>> AppImageLauncher popup here and want to integrate/run, and maybe break something (?)
https://github.com/TheAssassin/AppImageLauncher/issues/602
==== AppImageLauncher would need to be updated to support Zstd, unsure why it still doesn't support it yet (is AppImageLauncher still maintained?). But for now AppImage authors need to use another compression format than the default one by passing either |--comp xz| or |--comp gzip| to appimagetool to have it work with AppImageLauncher.
=====
workaround is to remove (temporarily?) AppImagelauncher until it fixed ... see end of issue, it was still not done as of 2 weeks ago.
Yes, I have also had the impression that Appimagelauncher are old and outdated. So I remove it here, but keep the appimaged installed (?)
# zypper se appimage Loading repository data... Reading installed packages...
S | Name | Summary | Type ---+-----------------------+----------------------------------------+----------- i+ | appimaged | Daemon handles (un)registering AppIm-> | package | appimaged | Daemon handles (un)registering AppIm-> | srcpackage | appimaged-debuginfo | Debug information for package appima-> | package | appimaged-debugsource | Debug sources for package appimaged | package i+ | appimagelauncher | AppImageLauncher built using CMake | package | obs-service-appimage | Handles source downloads defined in -> | package
# zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------+---------+----------------------+--------+------------------------- i+ | appimaged | package | 10-2.1 | x86_64 | openSUSE-Slowroll-Update i+ | appimagelauncher | package | 2.2.0-gha111~d9d4c73 | x86_64 | (System Packages)
# zypper rm appimagelauncher
-----------------------------
/Cin # sh ./bld_appimage.sh ......snip
-- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " [appimagelauncher-binfmt-bypass/interpreter] AppImageLauncher not found at /usr/bin/AppImageLauncher, launching AppImage directly: /usr/local/bin/appimagetool-x86_64.AppImage [appimagelauncher-binfmt-bypass/lib] WARNING: could not find preload library path, using temporary file fusermount3 version: 3.16.2 execv error: No such file or directory
-----------
Error and still no AppImage file has been created:
/Cin # du -sh AppDir 216M AppDir
/Cin # ls -la AppDir total 12 drwxr-xr-x 3 root root 4096 Dec 6 11:00 . drwxr-xr-x 31 root root 4096 Dec 6 10:59 .. lrwxrwxrwx 1 root root 11 Dec 6 11:00 AppRun -> usr/bin/cin lrwxrwxrwx 1 root root 34 Dec 6 11:00 cin.desktop -> usr/share/applications/cin.desktop lrwxrwxrwx 1 root root 45 Dec 6 11:00 cin.svg -> usr/share/icons/hicolor/scalable/apps/cin.svg drwxr-xr-x 5 root root 4096 Dec 6 10:59 usr
there must be appimage.log in same directory with bld_appumage.sh
check it?
Yes, appimage.log is there, but indeed smaller than my own saved terminal output to bld_appimage.log The tail is identical in both as shown above.
appimage should appear in same directory, in other words our source tree root.
I think something still not installed.
squashfstools-ng ?
No such package available; the most similar is the installed squashfuse-tools. All squash packages available and installed are
S | Name | Summary | Type ---+------------------+----------------------------------------------------+------ i+ | libsquashfuse0 | FUSE module to mount squashfs images | pakke i | squashfs | A Read-Only File System with Efficient Compression | pakke i+ | squashfuse | FUSE module to mount squashfs images | pakke i+ | squashfuse-devel | FUSE module to mount squashfs images | pakke i+ | squashfuse-tools | Squafs Tools for squashfsfuse | pakke
/usr/local/bin/appimagetool-x86_64.AppImage
may be this one does have --help parameter?
if it allows for setting compression may be rename it new name, and made script calling renamed binary with hardcoded compression argument?
The --help didn't output compression setting. However the Readme contains among Application Options: https://github.com/AppImage/appimagetool?tab=readme-ov-file#appimagetool---
--comp Squashfs compression
sorry, appimage does not work on termux or on NetBSD, so I am a bit out of help here.
Yes, I'm stuck and put Appimage file on hold (yet, the AppDir binary looked promising) -------------
may be run appimagetool manually with appdir directory as argument, like in this question?
https://stackoverflow.com/questions/64564820/how-to-use-appimagetool-to-crea...
it should output long text saying among other things
"Generating squashfs..."
if this does not work may be try older appimagetool and not latest (from 2021 instead of 2023)?
Yes, thanks, the latter worked much better. I downloaded the absolete, legacy version from 2020, and only 2.07MB https://github.com/AppImage/AppImageKit/releases/download/13/appimagetool-x8... and replaced the recommended quite new version since 3 days and 12.1 MB large https://github.com/AppImage/appimagetool/releases/download/continuous/appima... This old one ran bld_appimage without issues: -- Deploying files into AppDir root directory -- Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/cin.desktop Deploying desktop file to AppDir root: AppDir/usr/share/applications/cin.desktop Creating symlink for file AppDir/usr/share/applications/cin.desktop in/as AppDir Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/cin.svg in/as AppDir Deploying AppRun symlink for executable in AppDir root: AppDir/usr/bin/cin Creating symlink for file AppDir/usr/bin/cin in/as AppDir/AppRun Found appimagetool: /usr/local/bin/appimagetool-x86_64.AppImage Running command: /usr/local/bin/appimagetool-x86_64.AppImage "appimagetool" "AppDir" " appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC WARNING: appstreamcli command is missing, please install it if you want to use AppStream metadata /home/cinelerra/cinelerra-5.1/AppDir/cin.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated Using architecture x86_64 Deleting pre-existing .DirIcon Creating .DirIcon symlink based on information from desktop file WARNING: AppStream upstream metadata is missing, please consider creating it in usr/share/metainfo/cin.appdata.xml Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sec... for more information or use the generator at http://output.jsbin.com/qoqukof. Generating squashfs... Parallel mksquashfs: Using 20 processors Creating 4.0 filesystem on cin-x86_64.AppImage, block size 131072. [=============================================================/] 3122/3122 100% Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072 compressed data, compressed metadata, compressed fragments, compressed xattrs, compressed ids duplicates are removed Filesystem size 92375.82 Kbytes (90.21 Mbytes) 42.67% of uncompressed filesystem size (216509.91 Kbytes) Inode table size 20123 bytes (19.65 Kbytes) 31.66% of uncompressed inode table size (63565 bytes) Directory table size 18018 bytes (17.60 Kbytes) 45.57% of uncompressed directory table size (39543 bytes) Number of duplicate files found 53 Number of inodes 1790 Number of files 1706 Number of fragments 266 Number of symbolic links 4 Number of device nodes 0 Number of fifo nodes 0 Number of socket nodes 0 Number of directories 80 Number of ids (unique uids + gids) 1 Number of uids 1 root (0) Number of gids 1 root (0) Embedding ELF... Marking the AppImage as executable... Embedding MD5 digest Success Please consider submitting your AppImage to AppImageHub, the crowd-sourced central directory of available AppImages, by opening a pull request at https://github.com/AppImage/appimage.github.io /home/cinelerra/cinelerra-5.1/AppDir should be packaged as cin-x86_64.AppImage ============ ~/Applications> ./cin-x86_64.AppImage ...... tested the same tff interlaced hdv09_04.m2t file and rendered it using hevc_qsv_10b420 ....... libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 libva info: VA-API version 1.22.0 libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_22 libva info: va_openDriver() returns 0 Render::render_single: Session finished. ** rendered 5972 frames in 29.555 secs, 202.064 fps audio0 pad 64 0 (64)
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Terje J. Hanssen