<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Deim: <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, few days back I was with my low-end laptop Acer TravelMate B116-M on <br>
film camp where we helped children to took videos and then we cut them <br>
to final short films. I had weakest device on camp, but must say it <br>
worked quite well. I tested hw acceleration as it was announced here and <br>
it was quite stable </blockquote><div><span class="gmail_default" style="font-size:small">Interesting, thanks for sharing this!</span></div><div><span class="gmail_default" style="font-size:small"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- laptop has Intel CPU and GPU so I used vaapi and <br>
h264_vaapi profile to speed up rendering. I tried to encode from 5 Mbps <br>
to 20 Mbps and noticed the few first frames of this hw encoded videos <br>
was quite low quality then it was better but lot of movement was lower <br>
quality also.<br></blockquote><div><span class="gmail_default" style="font-size:small">"</span>According to an online wiki, hardware encoders usually create output of lower quality than some<br>software encoders like x264, but are much faster and use less CPU.<span class="gmail_default" style="font-size:small">"</span><span class="gmail_default" style="font-size:small"> --- it seems that the hardware acceleration is useful for initial rendering/checking but for quality purposes, the slower software rendering may be better for a final video. I see no technical reason why the first frames would be of lower quality so I will ask GoodGuy if he has an explanation and I will run a test on a vaapi-enabled laptop here.<br></span></div><div><span class="gmail_default" style="font-size:small"></span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Then I loaded all saved parts to project as resources - it loaded saved <br>
parts as clips and all assets to resources. Then I pasted clips on <br>
timeline of final video and made final cut. Then I saved final project. <br>
Closed Cinelerra then I was unable to reopen saved project - it only <br>
showed one of clips on timeline :-(<br></blockquote><div><span class="gmail_default" style="font-size:small">This is of major concern, although there have been no similar reports of "unable to re</span><span class="gmail_default" style="font-size:small">open saved project", as you never want to lose work. If you still have the errant project file, GoodGuy would really like to see it to maybe determine a problem (you can send it to me at <a href="mailto:phylsmith2017@gmail.com">phylsmith2017@gmail.com</a> to keep it private or which ever way works for you).</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I then wanted to run jobs but it warned about mismatch of session/job so <br>
I must render separate :-(<br>
I rendered by jobs before without problems the same way. So I don't know <br>
what the problem was.<br></blockquote><div><span class="gmail_default" style="font-size:small">This error message creates some confusion -- in lots of cases, it is best to uncheck "warn if jobs/session mismatch"</span><span class="gmail_default" style="font-size:small">. So I suggest leave this box unchecked in your case. The "warn if mismatch" checks the timeline and the batch job to see if the user changed something on the timeline and forgot to re-save and thus the changes would be loss - so it is a valuable test. But with multiple jobs, it is probably always a mismatch. A lot of things have changed in Cinelerra, so it is possible that it worked for you before but a redraw or something working a little differently than before may now result in a mismatch.<br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'm using git versions - I work on Gentoo and I'd be happy to have <br>
official ebuild for this. I made first steps for that:<br>
<a href="https://bugs.gentoo.org/691102" rel="noreferrer" target="_blank">https://bugs.gentoo.org/691102</a></blockquote><div><span class="gmail_default" style="font-size:small">I did look at this. That would be great!</span> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think it would be better to build only production versions from git <br>
i.e. if somewhere was some info about what build is last production it <br>
could be somehow in ebuild to decide to build stable or latest git version.<br></blockquote><div><span class="gmail_default" style="font-size:small">We do builds on the last day of each month (currently, but the last day of the month for us in Colorado may actually be the first day of the month in Europe) and we consider this to be a stable release. If you look at the following URL and see the comment as "<b>version update</b>" that is considered a release:</span></div><div><span class="gmail_default" style="font-size:small"> <a href="https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=summary">https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=summary</a></span></div><div><span class="gmail_default" style="font-size:small">However, it may be too much to do a Gentoo build every month - perhaps every 6 months is more reasonable.<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span> </div></div></div>