В сообщении от Wednesday 20 January 2021 11:37:19 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
A Cinelerra project always starts with: <?xml version="1.0"?> <EDL VERSION=Infinity PATH=""> Perhaps you can indicate in the code that if the file you find has in the header "EDL VERSION = Infinity" or simply "EDL" ignore this file, do nothing with it and get an error that says "This file is not a batch render"
I see that the batch list headers are different: <?xml version="1.0"?> <JOBS> And they do not contain the EDL attribute. Maybe I'm saying other nonsense because I don't know how to program.
I created this little function: int BatchRenderThread::probe(const char *path) { FILE *fp = fopen(path, "rb"); if( !fp ) return FILE_NOT_FOUND; char data[16]; memset(data,0,sizeof(data)); int ret = fread(data, 1, 16, fp); fclose(fp); if( !ret ) return FILE_NOT_FOUND; if ( !strncmp(&data[0],"<",1) && ( !strncmp(&data[1],"EDL>",4) || !strncmp(&data[1],"HTAL>",5) || !strncmp(&data[1],"?xml",4) )) return FILE_IS_XML; return FILE_UNRECOGNIZED_CODEC; } by literally copy/pasting code around from file.C seems to work, while I still don't have 'this is EDL from Cin5+' *function* . If you feel brave you can try to apply batchrender_current_work_labels-2.diff from my prev. email and see how many things I broke! (but it *hopefully* has this fileprotection part working - try on easy-to-recreate files!) it also should support manually setting IOPOINTED=1 in batchrender's JOB line (and obviously you can hack such file by hand, err by your favourite editor, unlike more compressed and binary config files .... or by script ....)
You are really good, I know, because a person who understands told me that the Cinelerra code requires a person with a lot of knowledge and experience. And you are demonstrating both characteristics and solving everything.
I feel bad for being so perfectionist with these things and always very critical of functions that can damage our work.
The render window is now much better than a few days ago. Above all, safer and easier to use. I keep the option to see dangerous buttons disabled, I don't need them because of the way I wo
El mié, 20 ene 2021 a las 7:42, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Wednesday 20 January 2021 08:59:51 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
I just tried this new version: Observations. - The render works fine again if launched from the terminal.
Cool :}
- I notice that the solution that Andrew proposed for the Insert transitions wizard in local mode has not been included yet. https://www.cinelerra-gg.org/bugtracker/view.php?id=545 Days ago I tried it and it worked satisfactorily.
Recommendations. - The known problem that if using cin -r we point to an EDL project file .xml, it is deleted and a blank xml remains. I think Andrew is working on it. It would be a shame if someone could lose their job due to this issue, since in other applications it is very common that when a render is launched from the terminal it points to the project file.
yes, I'm working on it .... But may be I should extract those two checks ('Is this file XML?' and 'Is this file actually XML Project from compatible Cinelerra?') into function(s) first ...
I take this opportunity to report an error that I have been observing
from
the beginning with the batch render window. This error only occurs on the first use of this wizard and has to do with assigning the extension when choosing FFMPEG. To play it you need to delete or rename, the .bcast5 folder, to simulate that it is the first time we use Cinelerra. And create a new list of EDL's to render, since if we load a list already created, this problem is not reproduced. Let's see if I can explain it so that it is understood. - When we open the Render window for the first time in "File format" it comes as "Unknown". - If I create a new render line, assigning an EDL and an output path, if I choose the FFMPEG option, this option automatically gives me the mp4 extension, and this is precisely the one I want to use and I don't touch anything else. - But when I press the Start button I get an error message with two windows, one says like this: "Couldn't open <file path> file.mp4" And a log message that says like this: "int FFMPEG :: init_encoder (const char *): bat file format: <file path> file.mp4 " [image: b.render.error.png]
[image: imagen.png]
How is it solved? Apparently it is not enough that in File format put FFMPEG, I must also click on choose extension, even if I want to use the same one that is shown, which is mp4 by default. If I display the extensions menu and click on another, or even on mp4, this problem no longer occurs. Conclusions. - If the person who performs a batch render for the first time and wants to export with mp4 will encounter this problem. It will not be the case if, for example, this person chooses another format. Possible solutions. - The sloppy proposal by a person who does not know programming, that is me. Set by default an extension that no one wants to use today, such as .avi, which is also the first on the list. - The elegant one, fix this or failing that, when FFMPEG is chosen, the extension is left blank and forces the user to choose one. With this simplicity, this error no longer occurs.
Yes, i noticed it too .... Will try to fix .... as far as I learn enough :}
Even with the experience I have, I got a little confused with this,
because
I wanted to use mp4 and this was the extension that I saw and I did not realize that I should display this menu and click on it, and this problem repeats itself every time I do tests, because I always rename the .bcast5 folder first to simulate a first use of Cinelerra that is not contaminated with my settings, which I recover again after testing.
I apologize for being such a perfectionist about these things, "fussy" I would say.
El mié, 20 ene 2021 a las 0:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew!
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B
/home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C
batchrender.C >
/home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not
batchrender.xml
AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin