В сообщении от 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 at 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 at 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 at 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 at lists.cinelerra-gg.org
> > > >> https://lists.cinelerra-gg.org/mailman/listinfo/cin
> > > >>
> > > > --
> > > > Cin mailing list
> > > > Cin at lists.cinelerra-gg.org
> > > > https://lists.cinelerra-gg.org/mailman/listinfo/cin
> > > >
> > >
> >
> >
> > --
> > Cin mailing list
> > Cin at lists.cinelerra-gg.org
> > https://lists.cinelerra-gg.org/mailman/listinfo/cin
> >
>