I've tried to do a few renders with image sequences as output. The render is successful; the index file and all the image-frames are formed. Render::render_single: Session finished. ** rendered 939 frames in 7.719 secs, 121.648 fps I attach the index file. You can see that it is constructed well but it does not contain the link to the various tiff images. So it is not possible to load it in CinGG. I have this error message: /home/paz/list/test%05d.tiff: Not a TIFF or MDI file, bad magic number 19785 (0x4d49). virtual int FileTIFF::read_frame_header(char*): Error while opening "/home/paz/list/test%05d.tiff" for reading. I tried with various tiff settings and other profiles (png and DPX) with the same result. If instead of ffmpeg I use the internal engine I get the expected result: the file list is complete with links to the various image-frames and the loading in CinGG is successful. Tried with tiff, png and openexr. Does it work for you to render image sequences with ffmpeg?
Andrea,
I tried with various tiff settings and other profiles (png and DPX) with the same result. If instead of ffmpeg I use the internal engine I get the expected result: the file list is complete with links to the various image-frames and the loading in CinGG is successful. Tried with tiff, png and openexr. Does it work for you to render image sequences with ffmpeg?
My tests agree with yours, i.e. you must use CinGG's internal engine and I checked the manual to ensure it was clear that you have to not use ffmpeg. However, I am going to work on testing ffmpeg today to see if I can get it to work somehow -- first I have to be able to get it to work from the ffmpeg command line.
I can't determine the version where the problem with the image sequences starts. Appimage 20210930 already has the problem. Previous ones don't work for me in Arch, giving a segv and an empty dump file.
may be it always was like this? (but may be you can spin VM with older distro for testing) may be we need some FFMPEG_LIST subtype of output, calling down into fileffmpeg, so Cinelerra does usual list keeping, and ffmpeg/libav* only encodes/muxes individual files... On Thursday, February 24, 2022, Andrea paz via Cin < [email protected]> wrote:
I can't determine the version where the problem with the image sequences starts. Appimage 20210930 already has the problem. Previous ones don't work for me in Arch, giving a segv and an empty dump file. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
With ffmpeg, as far as I know, it was never even tried so possibly never worked. The native image sequence is the original implementation by HV (1996) which occurred before the initial release of ffmpeg in the year 2000.
may be it always was like this? (but may be you can spin VM with older distro for testing)
I can't determine the version where the problem with the image sequences starts. Appimage 20210930 already has the problem. Previous ones don't work for me in Arch, giving a segv and an empty dump file.\
I am still testing here with little reportable progress.
In VM (ubuntu 18.04) with appimage 20211130-older-distros everything works fine. On my Arch I never had problems, for example when Andrew introduced presets for DPX, they worked fine for me. In December I started having problems: https://lists.cinelerra-gg.org/pipermail/cin/2021-December/004465.html
I think it is a problem of absolute or relative paths: the file-list is formed correctly, but references to image-frames are missing due to unrecognized paths. I had already found the problem previously: https://lists.cinelerra-gg.org/pipermail/cin/2021-December/004335.html Maybe there has been some change (in ffmpeg or in CinGG or in image2) regarding the management of paths?
This is the kind of error I get when rendering with image sequences: FFStream::encode_frame: encode failed. file: /home/paz/list/test%05d.png err: Resource temporarily unavailable FFMPEG::mux_video err: Operation not permitted FFMPEG::open_decoder: some stream times estimated: /home/paz/video_editing/free_video/vp9.webm Render::render_single: Session finished. ** rendered 939 frames in 9.128 secs, 102.870 fps (I remind you that the frames are correctly rendered, but in the TOC there is no reference to these images) If a solution is not found I propose to eliminate presets in CinGG and manual; image sequences are probably not used much, but those who use them are because they follow a very professional workflow, which also involves exchanging with compositing and/or color correction programs, and also switching from film to digital. So, in my opinion, it is better to specify that CinGG does not support DPX than to displease those possible users. I'm hoping for the work proposed by realvi, but that concerns the internal engine and not ffmpeg: https://www.cinelerra-gg.org/forum/everything-else/youtubes-video-edit-with-...
On Thursday, March 3, 2022, Andrea paz via Cin <[email protected]> wrote:
This is the kind of error I get when rendering with image sequences:
FFStream::encode_frame: encode failed. file: /home/paz/list/test%05d.png err: Resource temporarily unavailable FFMPEG::mux_video err: Operation not permitted FFMPEG::open_decoder: some stream times estimated: /home/paz/video_editing/free_video/vp9.webm Render::render_single: Session finished. ** rendered 939 frames in 9.128 secs, 102.870 fps
(I remind you that the frames are correctly rendered, but in the TOC there is no reference to these images)
As temporary workaround TOC can be generated by external script?
If a solution is not found I propose to eliminate presets in CinGG and manual; image sequences are probably not used much, but those who use them are because they follow a very professional workflow, which also involves exchanging with compositing and/or color correction programs, and also switching from film to digital. So, in my opinion, it is better to specify that CinGG does not support DPX than to displease those possible users. I'm hoping for the work proposed by realvi, but that concerns the internal engine and not ffmpeg:
https://www.cinelerra-gg.org/forum/everything-else/ youtubes-video-edit-with-cingg/#post-2078 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Thursday, March 3, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Thursday, March 3, 2022, Andrea paz via Cin <[email protected]> wrote:
This is the kind of error I get when rendering with image sequences:
FFStream::encode_frame: encode failed. file: /home/paz/list/test%05d.png err: Resource temporarily unavailable FFMPEG::mux_video err: Operation not permitted FFMPEG::open_decoder: some stream times estimated: /home/paz/video_editing/free_video/vp9.webm Render::render_single: Session finished. ** rendered 939 frames in 9.128 secs, 102.870 fps
(I remind you that the frames are correctly rendered, but in the TOC there is no reference to these images)
As temporary workaround TOC can be generated by external script?
also, it seems documentation and actual behavior still allow loading 'empty' toc file and corresponding image files: https://cinelerra-gg.org/download/CinelerraGG_Manual/FFmpeg_Image2_Streams.h... === The resulting directory of images can be opened for reading by simply opening the template path. As in: File → Load Files /tmp/tiff_images/img%03d.tiff. You will notice a file named the same as the template, which has been automatically created, is empty, is needed, and has to remain with the set. ==== it works for me, loading 3 bmp images on timeline... file not completely empy, just does not contain file paths... if this loading works may be documentation can be improved? by saying this ffmpeg toc file not the same as usual image sequence toc file?
If a solution is not found I propose to eliminate presets in CinGG and manual; image sequences are probably not used much, but those who use them are because they follow a very professional workflow, which also involves exchanging with compositing and/or color correction programs, and also switching from film to digital. So, in my opinion, it is better to specify that CinGG does not support DPX than to displease those possible users. I'm hoping for the work proposed by realvi, but that concerns the internal engine and not ffmpeg:
https://www.cinelerra-gg.org/forum/everything-else/youtubes- video-edit-with-cingg/#post-2078 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
(My TOC is also not completely empty; just does not contain file paths) Using the command: ffmpeg -i sample_1920x1080.mov test%05d.dpx creates the images, but does not create the TOC. Using image2ffmpeg: - I created the imagelist.sh script (https://cinelerra-gg.org/download/CinelerraGG_Manual/Image_Sequence_Creation...) - I created the sequence of jpgs with the previous command (ffmpeg -i sample_1920x1080.mov test%05d.jpg). I got all the images without TOC. - I created the TOC file with the script: ./imagelist.sh test_list%05d.txt test*.jpg - obtained the TOC file (test_list%05d.txt), this is imported into CinGG without problems.
I tried to make a build using the Makefile and configure.ac made by realvi (manuvi): https://github.com/manuvi/cinelerra/tree/master/cinelerra-5.1 I replaced the "Makefile" in .../cinelerra-5.1/cinelerra/Makefile the "configure.ac" in .../cinelerra-5.1/configure.ac the "Makefile" (thirdparty) in .../cinelerra-5.1/thirdparty/Makefile the "downloads.txt" in .../cinelerra-5.1/thirdparty/downloads.txt and add "libdpx.tar.xz" in .../cinelerra-5.1/thirdparty/src/libdpx.tar.xz [In configure.ac I have seen many changes of "AS_" to "AC_" and also the replacement of "ilmbase" with "imath"] The compile fails and exit. Would you be able to make these changes work, that update the OpenEXR and DPX libraries, as well as introducing the rendering of DPX sequences with CinGG's internal engine? I attach the "cin5.log", "Makefile", "Makefile(thirdparty), "downloads.txt", "libdpx.tar.xz" and "configure.ac" taken from the manuvi git.
very interesting find, Andrea! you can try to download those sources with git, then extract few top patches (use git log for seeing our most up-to-date commit, then use git format-patch this_commit to get somevpatches, look at them, apply relevant ones to your copy of cin-gg with git am) On Friday, March 4, 2022, Andrea paz <[email protected]> wrote:
I tried to make a build using the Makefile and configure.ac made by realvi (manuvi): https://github.com/manuvi/cinelerra/tree/master/cinelerra-5.1 I replaced the "Makefile" in .../cinelerra-5.1/cinelerra/Makefile the "configure.ac" in .../cinelerra-5.1/configure.ac the "Makefile" (thirdparty) in .../cinelerra-5.1/thirdparty/Makefile the "downloads.txt" in .../cinelerra-5.1/thirdparty/downloads.txt and add "libdpx.tar.xz" in .../cinelerra-5.1/thirdparty/src/libdpx.tar.xz
[In configure.ac I have seen many changes of "AS_" to "AC_" and also the replacement of "ilmbase" with "imath"]
The compile fails and exit. Would you be able to make these changes work, that update the OpenEXR and DPX libraries, as well as introducing the rendering of DPX sequences with CinGG's internal engine?
I attach the "cin5.log", "Makefile", "Makefile(thirdparty), "downloads.txt", "libdpx.tar.xz" and "configure.ac" taken from the manuvi git.
( Phyllis): When I used the ffmpeg/tiff render format, it created the toc file but it was empty even then. Also ran the CinGG version of 11/2016 and 2/2018; in both cases the toc file was either empty (the earlier ones) or just the first 4 lines. So I think it never worked right and the workaround as Andrea tested it to create the toc file manually.
Sorry to insist, but I think DPX support is very important. It would take more testing by other users. As I wrote in a previous message, some versions work for me, and even in Arch, DPX and PNG used to work for me (not anymore, now). @IgorBeg Please, can you test the rendering of a sequence of images (it only takes a few seconds), since you normally use Ubuntu 16?
I assume the ffmpeg command line creates it? I have not had the chance to try that yet. Does it?
FFmpeg creates the images with a command (muxer) that implies %05d in the name and then, thanks to the image2 command (demuxer), it reads them (without the need to create a TOC file) and creates the video. It occurs to me that CinGG presets create the images via %05d and then, instead of being read by image2, the TOC file (not the video file!) is created and can be imported into CinGG (or other program). Perhaps a version of "imagelist.sh" is implemented? In short, the difference between ffmpeg and CinGG is the creation of the TOC file. I remember that my hypothesis about the problem is the management of absolute/relative paths, since the TOC is created and works: only the links are missing. Is it possible to trace a patch that has touched the paths? If not, I'll say again that it's better to delete these presets and the related entries in the manual altogether. [ffmpeg reference: https://www.ffmpeg.org/faq.html#How-do-I-encode-single-pictures-into-movies_... https://www.ffmpeg.org/ffmpeg-formats.html#image2-2 https://www.ffmpeg.org/ffmpeg-formats.html#image2-1]
On Monday, March 7, 2022, Andrea paz <[email protected]> wrote:
( Phyllis): When I used the ffmpeg/tiff render format, it created the toc file but it was empty even then. Also ran the CinGG version of 11/2016 and 2/2018; in both cases the toc file was either empty (the earlier ones) or just the first 4 lines. So I think it never worked right and the workaround as Andrea tested it to create the toc file manually.
Sorry to insist, but I think DPX support is very important.
It would take more testing by other users. As I wrote in a previous message, some versions work for me, and even in Arch, DPX and PNG used to work for me (not anymore, now).
@IgorBeg Please, can you test the rendering of a sequence of images (it only takes a few seconds), since you normally use Ubuntu 16?
I assume the ffmpeg command line creates it? I have not had the chance to try that yet. Does it?
FFmpeg creates the images with a command (muxer) that implies %05d in the name and then, thanks to the image2 command (demuxer), it reads them (without the need to create a TOC file) and creates the video. It occurs to me that CinGG presets create the images via %05d and then, instead of being read by image2, the TOC file (not the video file!) is created and can be imported into CinGG (or other program). Perhaps a version of "imagelist.sh" is implemented? In short, the difference between ffmpeg and CinGG is the creation of the TOC file.
I remember that my hypothesis about the problem is the management of absolute/relative paths, since the TOC is created and works: only the links are missing.
I am not sure it was designed as cross-application support? I mean, cingg can load both TOC types, so it works... Are you concerned about more self-contained toc file for inter-application operability or self-documentability reasons? How other apps (like Natron?) handle this?
Is it possible to trace a patch that has touched the paths? If not, I'll say again that it's better to delete these presets and the related entries in the manual altogether.
[ffmpeg reference: https://www.ffmpeg.org/faq.html#How-do-I-encode-single- pictures-into-movies_003f https://www.ffmpeg.org/ffmpeg-formats.html#image2-2 https://www.ffmpeg.org/ffmpeg-formats.html#image2-1]
I am not sure it was designed as cross-application support? I mean, cingg can load both TOC types, so it works...
Are you concerned about more self-contained toc file for inter-application operability or self-documentability reasons?
How other apps (like Natron?) handle this?
Sorry, I don't understand what you're asking. I tried to do a dpx render; it came with all the images and a TOC file that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX). I redid these steps using PNG instead of DPX and the TOC+ works in CinGG; Natron; OpenShot but does not work in Kdenlive.
On Monday, March 7, 2022, Andrea paz <[email protected]> wrote:
I am not sure it was designed as cross-application support? I mean, cingg can load both TOC types, so it works...
Are you concerned about more self-contained toc file for inter-application operability or self-documentability reasons?
How other apps (like Natron?) handle this?
Sorry, I don't understand what you're asking.
yeah, this is info I was asking about - because it seems to me Cingg's imagelist format might be not very universal even in better form with file pathes. I think half-done toc file from image2 muxer kinda normal - this is another corner cut by cingg. She delegates creating sequence itself to libavformat/image2 muxer and then rely on same (ffmpeg's) demuxer to reconstruct real paths to images on loading. it probably fixable, but I do not have clear idea how (ffmpeg module must communicate list of images back to cingg internals) Sorry about this confusion and thanks for actually testing this (cingg's output as input for other apps) file BT about it? I still think dpx-from-ffmpeg a bit useful even if you need to glue two files together manually for now - due to possibility of encoding exact range on timeline (with ffmpeg cmd line you need to know where to set your cut points, less intuitive) sorry about possible misunderstanding, again. May be documentation need some additional sentence sayng that you need to use 'ffmpeg first' if one uses ffmpeg's tiff/png image presets, so native demuxer will not choke over incomplete toc file? I tried to do a dpx render; it came with all the images and a TOC file
that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX).
can you attach both toc files so i can experiment on them? (hopefully just some sed + redirection will be enough - but i do not know those tools from my memory - so i'll search online for manuals / examples)
I redid these steps using PNG instead of DPX and the TOC+ works in CinGG; Natron; OpenShot but does not work in Kdenlive.
The ffmpeg TOC file does not need to contain the list of files. Here is how to test this for TIFF files: 1) render using options: ffmpeg / tif 2) for ease of use, put the files in /tmp/test/test%5d.tif (so create /tmp/test directory first) 3) do the render and you will see that test%5d.tiff will contain ONLY: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 and all of the test00###.tiff files exist in the /tmp/test directory 4) now just add a video track and drag the test%5d.tiff from the Media folder of the Resources window and it works correctly or later just load /tmp/test%5d.tiff and it works. Now for the interesting part, yesterday and this morning DPX was working on my builds and AppImages from October, November, and December UNTIL I switch to using TIFF instead of DPX. Now DPX no longer works so there is something going on and I have not figured it out yet. Also, yesterday, I tried it on Arch dated 10/30/2020 and DPX did not work (have to check to see if TIFF does). The correct contents of the dpx file is: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 with NO listing of each individual dpx files needed.
I tried to do a dpx render; it came with all the images and a TOC file
that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX).
"test%05d.dpx" is created by CinGG; then I pasted the links taken from "toc%05d.txt". The latter was created with imagelist.sh. Out of curiosity I tried to change the first line of "toc%05s.txt" from JPEGLIST to IMAGE2, but it still doesn't work. In short it only serves as a source of links or for jpeg format only.
On Monday, March 7, 2022, Phyllis Smith via Cin <[email protected]> wrote:
The ffmpeg TOC file does not need to contain the list of files.
Here is how to test this for TIFF files: 1) render using options: ffmpeg / tif 2) for ease of use, put the files in /tmp/test/test%5d.tif (so create /tmp/test directory first) 3) do the render and you will see that test%5d.tiff will contain ONLY: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 and all of the test00###.tiff files exist in the /tmp/test directory 4) now just add a video track and drag the test%5d.tiff from the Media folder of the Resources window and it works correctly or later just load /tmp/test%5d.tiff and it works.
Now for the interesting part, yesterday and this morning DPX was working on my builds and AppImages from October, November, and December UNTIL I switch to using TIFF instead of DPX. Now DPX no longer works so there is something going on and I have not figured it out yet.
I think in my case (i tried ffmpeg/bmp seq) Cin just created bmps instead of dpx! for scripting.. I first cp dpx%6d.dpx dpx.dpxs (copied cingg's header/toc into new file) then ls *.dpx > dpx.list (will list all dpx files in current dir including cingg's header/toc one) then cat dpx.list >> dpx.dpxs (glue two files together) then sed '/%d*/d' -i dpx.dpxs (remove cin-gg's header/toc file from resulting file in-place) but because dpx really bmp in my case it failed to work...
Also, yesterday, I tried it on Arch dated 10/30/2020 and DPX did not work (have to check to see if TIFF does). The correct contents of the dpx file is: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 with NO listing of each individual dpx files needed.
I tried to do a dpx render; it came with all the images and a TOC file
that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX).
On Monday, March 7, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Monday, March 7, 2022, Phyllis Smith via Cin < [email protected]> wrote:
The ffmpeg TOC file does not need to contain the list of files.
Here is how to test this for TIFF files: 1) render using options: ffmpeg / tif 2) for ease of use, put the files in /tmp/test/test%5d.tif (so create /tmp/test directory first) 3) do the render and you will see that test%5d.tiff will contain ONLY: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 and all of the test00###.tiff files exist in the /tmp/test directory 4) now just add a video track and drag the test%5d.tiff from the Media folder of the Resources window and it works correctly or later just load /tmp/test%5d.tiff and it works.
Now for the interesting part, yesterday and this morning DPX was working on my builds and AppImages from October, November, and December UNTIL I switch to using TIFF instead of DPX. Now DPX no longer works so there is something going on and I have not figured it out yet.
I think in my case (i tried ffmpeg/bmp seq) Cin just created bmps instead of dpx!
ah, yes, we forgot to select profile (video option wrench > DPX.dpx is only choice... but you must select it manually!)
for scripting..
I first
cp dpx%6d.dpx dpx.dpxs (copied cingg's header/toc into new file)
then
ls *.dpx > dpx.list (will list all dpx files in current dir including cingg's header/toc one)
then
cat dpx.list >> dpx.dpxs (glue two files together) then
sed '/%d*/d' -i dpx.dpxs (remove cin-gg's header/toc file from resulting file in-place)
but because dpx really bmp in my case it failed to work...
Also, yesterday, I tried it on Arch dated 10/30/2020 and DPX did not work (have to check to see if TIFF does). The correct contents of the dpx file is: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 with NO listing of each individual dpx files needed.
I tried to do a dpx render; it came with all the images and a TOC file
that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX).
attached simple 3-line script hardcoded to dpx sequence transformation. does it work (for Natron input) as good as your hand-editing, Andrea? On Monday, March 7, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Monday, March 7, 2022, Phyllis Smith via Cin < [email protected]> wrote:
The ffmpeg TOC file does not need to contain the list of files.
Here is how to test this for TIFF files: 1) render using options: ffmpeg / tif 2) for ease of use, put the files in /tmp/test/test%5d.tif (so create /tmp/test directory first) 3) do the render and you will see that test%5d.tiff will contain ONLY: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 and all of the test00###.tiff files exist in the /tmp/test directory 4) now just add a video track and drag the test%5d.tiff from the Media folder of the Resources window and it works correctly or later just load /tmp/test%5d.tiff and it works.
Now for the interesting part, yesterday and this morning DPX was working on my builds and AppImages from October, November, and December UNTIL I switch to using TIFF instead of DPX. Now DPX no longer works so there is something going on and I have not figured it out yet.
I think in my case (i tried ffmpeg/bmp seq) Cin just created bmps instead of dpx!
for scripting..
I first
cp dpx%6d.dpx dpx.dpxs (copied cingg's header/toc into new file)
then
ls *.dpx > dpx.list (will list all dpx files in current dir including cingg's header/toc one)
then
cat dpx.list >> dpx.dpxs (glue two files together) then
sed '/%d*/d' -i dpx.dpxs (remove cin-gg's header/toc file from resulting file in-place)
but because dpx really bmp in my case it failed to work...
Also, yesterday, I tried it on Arch dated 10/30/2020 and DPX did not work (have to check to see if TIFF does). The correct contents of the dpx file is: IMAGE2 # Frame rate: 29.970030 # Width: 352 # Height: 240 with NO listing of each individual dpx files needed.
I tried to do a dpx render; it came with all the images and a TOC file
that doesn't have the links to the images. Then I created a second TOC file using imagelist.sh. A TOC came up with the links to the dpx images. This doesn't work when imported into CinGG; it's obvious because imagelist.sh uses only jpeg images and not dpx. So I took the first TOC and pasted in the links from the second TOC. This TOC+ works in CinGG and Natron; it doesn't work in Kdenlive and OpenShot (but I don't know if these programs support DPX).
Phyllis found the solution; I'm reposting her letter because lately she's been using only the "reply" button instead of "reply to all" ;-) "OK, the test I provided works for TIFF and I was not able to get DPX working reliably by the time of my last email. BUT now I know how to get it to work, at least 100% of the time for me with DPX, and even tested on ARCH ! 1) shift R - to get to render menu 2) choose ffmpeg / dpx 3) make sure render video tracks is checked 4) click on the video wrench 5) use the down arrow to select which dpx you want (YES, there is only one, but do this anyway) 6) highlight DPX.dpx in the box and click OK (this is what makes it work for me 100%) Now it works. So if you then later do a TIFF instead, you have to make sure to do steps 5 and 6 again. There must be some nuance bug in the code." Now, with this trick, it always works for me without the need to paste the links. It works in Natron too! Thank you all. PS: @Andrew I'll try your script tomorrow; it's always a valuable addition to the manual.
Phyllis found the solution; I'm reposting her letter because lately she's been using only the "reply" button instead of "reply to all" ;-)
OK, ok, I changed my default to "reply all". I never look at the "from" and just assume it is from Cinelerra.GG.
There must be some nuance bug in the code."
Not a bug in the code per se, just needed to add a file called dpx.dfl in the directory ffmpeg/video (like all the rest of the options have). I checked this into GIT just now so it works right without having to remember to do some extra steps (maybe Andrea can verify too). And now I have checked all of them and found the same problem with "jp2" which is also missing "jp2.dfl" so I will check that in next time I power up the desktop.
Now, with this trick, it always works for me without the need to paste the links.
About this:
For me it fails to build with patches, always errors. Even trying to build manuvi git leads to compile errors.
Should I be looking at manuvi git and try to build with Andrew's patches? I need to look back at the email to see what this is all about. I would like to add anything that people are using! Let me know.
I see You all have solved the question. Below my tests on. Because my OS is UbuntuStudio16.04_64bit, I tested on "CinGG-20220228-x86_64-older_distro.AppImage", "CinGG-20220131-x86_64-older_distro.AppImage", and "CinGG-20201031_static_build". It works fine for DPX (there isn't for CinGG20201031), TIFF, and PNG. The file name assigned is "image%05d.dpx" as it was written inside the text window with options and comments. And load that file (image%05d.dpx) in an empty track. IgorBeg PS: Note. To know the info about DPX images, and others, I am using ImageMagick by Command Line: "identify -verbose filename.dpx" Il 07/03/2022 09:25, Andrea paz via Cin ha scritto:
@IgorBeg Please, can you test the rendering of a sequence of images (it only takes a few seconds), since you normally use Ubuntu 16?
I've tried build CinGG from git both with Andrew's 3 patches and without (so with only Phyllis' modification for dpx). In both cases I get errors and the build fails (maybe due to x265 v3.5?). I attach the 2 cin5.logs. PS: I remember that I use Arch which is a rolling release and lately there have been many updates of the graphics libraries. I think it's a new problem of Arch that has nothing to do with the patches tried.
On Tuesday, March 8, 2022, Andrea paz via Cin <[email protected]> wrote:
I've tried build CinGG from git both with Andrew's 3 patches and without (so with only Phyllis' modification for dpx). In both cases I get errors and the build fails (maybe due to x265 v3.5?). I attach the 2 cin5.logs.
PS: I remember that I use Arch which is a rolling release and lately there have been many updates of the graphics libraries. I think it's a new problem of Arch that has nothing to do with the patches tried.
may be compiler error? if you use gcc, try clang instead or other way around? also, new nasm might give some errors.. i see libopus, dav1d, libaom errors... try to disable some of those libs via configure switches tempirary? I look at log files in mcview, and search for 'errore' string....
Andrea, As Andrew stated, first try with just the dpx modification and disable compiling with dav1d to see if that at least builds. You probably have changed the script bld.sh but you can see the disable below in the one I use. Just add --disable-dav1d to the configure line. #!/bin/bash ( ./autogen.sh ./configure --with-single-user --with-booby *--disable-dav1d* make && make install ) 2>&1 | tee log mv Makefile Makefile.cfg cp Makefile.devel Makefile The current dav1d works with NASM 2.13 but I see Arch is at 2.15. That should not make a difference because generally later versions are compatible with earlier versions. Thank you for testing as we need to know if the latest Arch has a problem with CinGG. I've tried build CinGG from git both with Andrew's 3 patches and
without (so with only Phyllis' modification for dpx). In both cases I get errors and the build fails (maybe due to x265 v3.5?). I attach the 2 cin5.logs.
PS: I remember that I use Arch which is a rolling release and lately there have been many updates of the graphics libraries. I think it's a new problem of Arch that has nothing to do with the patches tried.
may be compiler error? if you use gcc, try clang instead or other way around?
also, new nasm might give some errors..
i see libopus, dav1d, libaom errors...
try to disable some of those libs via configure switches tempirary?
I look at log files in mcview, and search for 'errore' string.... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I tried a downgrade to nasm 5.14 but it still produces errors. nasm 5.13 is too old and Arch no longer has it in the archive. However, the month-end build was working fine; it must be an Arch update from the last week. I tried disable-dav1d; disable dav1d + libaom + opus; and finally clang + disable-dav1d. In all 3 cases I get errors. I attach the logs.
Hopefully, Andrew will look at this better than I can but what I see: Looking at the simplest of "cin5_disable_david.log", it looks like you got past the dav1d error by disabling and now have a libvpx error. Disabling parts is not a solution but at least it helps to determine if there is a similar problem in compiling other routines. The error you see below is a compiling error (I think) which is hard to believe that libvpx could have an unbalanced parenthesis or it would not work on other computers. /tmp/ccmCkgcu.s: Assembler messages: /tmp/ccmCkgcu.s:1813: *Error: unbalanced parenthesis in operand 1.* make[4]: *** [Makefile:160: *vp9/encoder*/vp9_temporal_filter.c.o] Errore 1 I will see if I can install Arch on a computer here and try it too, but I have never done this before. On Wed, Mar 9, 2022 at 6:35 AM Andrea paz <[email protected]> wrote:
I tried a downgrade to nasm 5.14 but it still produces errors. nasm 5.13 is too old and Arch no longer has it in the archive. However, the month-end build was working fine; it must be an Arch update from the last week. I tried disable-dav1d; disable dav1d + libaom + opus; and finally clang + disable-dav1d. In all 3 cases I get errors. I attach the logs.
Installing Arch is the most time-consuming and tedious thing (and there's studying the wiki). I don't recommend its installation. If you really want to try, put EndeavourOS which is Arch with only the graphical installer, for the rest use the same repositories of Arch and also AUR.
On Wed, 2022-03-09 at 16:00 +0100, Andrea paz via Cin wrote:
Installing Arch is the most time-consuming and tedious thing (and there's studying the wiki). I don't recommend its installation. If you really want to try, put EndeavourOS which is Arch with only the graphical installer, for the rest use the same repositories of Arch and also AUR.
I second that. At least three times I had Arch go wrong on me, either during install, or later when some update badly damaged the installation. Only because I had it on a multiboot machine I could recover, in a earler VM only a re-install helped me. EndeavourOS is better, but I had that go wrong on me as well. I have now Majaro installed (also Arch based) which seems better (so far). MatN
OK, you2 have convinced me -- I was just curious if I could reproduce the same error as Andrea. I still have other tests I need to do anyway. On Wed, Mar 9, 2022 at 9:13 AM mat <[email protected]> wrote:
On Wed, 2022-03-09 at 16:00 +0100, Andrea paz via Cin wrote:
Installing Arch is the most time-consuming and tedious thing (and there's studying the wiki). I don't recommend its installation. If you really want to try, put EndeavourOS which is Arch with only the graphical installer, for the rest use the same repositories of Arch and also AUR.
I second that. At least three times I had Arch go wrong on me, either during install, or later when some update badly damaged the installation. Only because I had it on a multiboot machine I could recover, in a earler VM only a re-install helped me. EndeavourOS is better, but I had that go wrong on me as well. I have now Majaro installed (also Arch based) which seems better (so far).
MatN
Just did a git pull, and now CinGG does not build anymore on Debian11 32 bit. Did a " make clean", then ./bld.sh . The build hangs on: usr/bin/ld: libavfilter/libavfilter.a(yadif-10.o): warning: relocation in read-only section `.text' MatN
That is strange. I will boot and see if I have the same problem and try to figure out why. On Fri, Mar 25, 2022 at 4:12 AM M Nieuwenhoven <[email protected]> wrote:
Just did a git pull, and now CinGG does not build anymore on Debian11 32 bit. Did a " make clean", then ./bld.sh . The build hangs on: usr/bin/ld: libavfilter/libavfilter.a(yadif-10.o): warning: relocation in read-only section `.text'
MatN
The Debian 11 32-bit build from the latest GIT checkout just finished here and there were no errors in the build and the small test video with audio worked just fine. I am at 5.10.46-4 and have yet to do an update of the latest fixes. Could that be the issue? If you think so, I can install the updates and build again. There really should not be a build issue because the last few checkins of the CinGG source code are very benign. I reviewed them again and the only one I can come up with as being unusual is the removal of libavdevice from ffmpeg and I tested with that mod in quite a lot. Just did a git pull, and now CinGG does not build anymore on Debian11 32
bit. Did a " make clean", then ./bld.sh . The build hangs on: usr/bin/ld: libavfilter/libavfilter.a(yadif-10.o): warning: relocation in read-only section `.text'
MatN
On Wednesday, March 9, 2022, Andrea paz via Cin <[email protected]> wrote:
I tried a downgrade to nasm 5.14 but it still produces errors. nasm 5.13 is too old and Arch no longer has it in the archive. However, the month-end build was working fine; it must be an Arch update from the last week. I tried disable-dav1d; disable dav1d + libaom + opus; and finally clang + disable-dav1d. In all 3 cases I get errors.
is there possibility of hw (ssd, memory/cpu, motherbiard...) error/breakage? does any other big compile finish without errors?
I attach the logs.
is there possibility of hw (ssd, memory/cpu, motherbiard...) error/breakage? does any other big compile finish without errors? I really hope it's not hardware: I don't notice any other problems! The only compilations I do are the AUR ones and so far I don't find any problems there (I tried the big DaVinci Resolve installation).
On Thursday, March 10, 2022, Andrea paz <[email protected]> wrote:
is there possibility of hw (ssd, memory/cpu, motherbiard...) error/breakage? does any other big compile finish without errors? I really hope it's not hardware: I don't notice any other problems! The only compilations I do are the AUR ones and so far I don't find any problems there (I tried the big DaVinci Resolve installation).
well, Arch is not Gentoo, so installing binary pkg most likely just unpack it.... try to run pkgbuild for something like firefox or libreoffice... https://wiki.archlinux.org/title/PKGBUILD ==== Packages in Arch Linux are built using the makepkg utility. When makepkg is run, it searches for a PKGBUILD file in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package archive (pkgname.pkg.tar.zst). The resulting package contains binary files and installation instructions, readily installable with pacman. ==== so, just download pkgbuild for big source package, put it in dir, run makepkg inside this dir, wait for compilation/packaging to finish... also, just in case check for free space on /tmp!
Yes, I do use the "makepkg -si" when installing from the AUR. I used DVR because it's a 2 GB package. I'm trying to figure out what the critical update might be for the last week by looking at the pacman.log. I will let you know. Thanks!
Not being able to solve the problem, I decided to format and reinstall Arch linux. Now the compilation of CinGG is successful! Finally! As an old Arch user, I'm sorry I couldn't figure out the cause... In any case, I apologize for wasting your time behind an issue that was not CinGG's.
On Friday, March 18, 2022, Andrea paz <[email protected]> wrote:
Not being able to solve the problem, I decided to format and reinstall Arch linux. Now the compilation of CinGG is successful! Finally! As an old Arch user, I'm sorry I couldn't figure out the cause... In any case, I apologize for wasting your time behind an issue that was not CinGG's.
well, everything is working now and hopefully will stay this way for long! Thanks for all your work and hope reinstall was just / and not /home!
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
Igor BEGHETTO -
M Nieuwenhoven -
mat
-
Phyllis Smith