<br><br>On Thursday, August 12, 2021, Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com" target="_blank">gamberucci.andrea@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tested with a build where all the patches are present.<br>
<br>
> I think 0066 from this series should work even with ffmpeg 4.3...<br>
> it should fix (hide?) those error messages at the end of fast encoding..<br>
><br>
with x265 I still see several messages about the codec; with h264 I<br>
don't see them. They don't look like error messages to me, so I don't<br>
think they're what you're referring to.</blockquote><div><br></div><div>yeah, I mean ones about eagain error, not [info] messages from x265.. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> then you can test 0067/68  duo..<br>
><br>
unlike my pdf now has the following results: RMB in any Gang mode does<br>
not apply to unarmed tracks. Do these patches only apply to Gang<br>
Channels and Gang Media?</blockquote><div><br></div><div>i think this is effect of next patch,  for 076/68 yo need to change</div><div>ARMED_IN_GANG_MODE 0 to 1 in. bcast5/Cinelerra_rc</div><div><br></div><div>after this change applying (audio) effect from main menu bar > audio > attach effect will respect armed/disarmed status. But also insert media or media movement will respect such status. May lead to de-sync. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> you already tested 0069 (but it alters historical behavior)<br>
><br>
RMB on Gang None does not apply on unarmed tracks.</blockquote><div><br></div><div>I think it will be true for all gang modes but I can restrict it especially for gang none (but because currently RMB>attach effect only alters one track - is there any difference?) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> then you can look into testing 0063 (just small build optimization)<br>
><br>
makefile presents corrections. I don't know what test to do!</blockquote><div><br></div><div>just fact build do not break, and  now going a bit faster and takes a bit less space.. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> then test 0044 whith as many avi files as you can (esp. big dv files with audio, i had some on my hdd from year 2006-11, seeking was broken there. this hack fixed them for me, by applying same seeking workaround as mkv)<br>
><br>
I'm not sure how to test the seek; I put several dv files, I cut and<br>
put transitions. the playback runs at the right fps without dips.<br>
There are no messages to the terminal.</blockquote><div><br></div><div>for me main error was very audible if i put playhead in the middle (roughly) of file and try to play from there. Basically 'playback after jump-seek' as i termed it... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> then 0042 - should be simple in that it adds exr sequence as format for background render<br>
><br>
exr sequence option has appeared. Sequence created more slowly. A<br>
frame in jpeg is 14.7 KB, a frame in exr is 10.6 MB</blockquote><div><br></div><div>you can choice another type of compression same way you can select jpeg quality - by clicking on wrench icon nearby.. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 0041 should provide some speedup on reverse fast playback of i-only files (think ffv1?)<br>
><br>
I created a small file ffv1: normal and fast reverse = normal and fast<br>
forward = same source fps</blockquote><div><br></div><div>guess your machine just powerful enough - I tested on 4-way amd fx-4300 and there was difference at backward playback/fast backward playback of simple dv file... watch for cpu used? </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 0039 may provide some decoding/encoding speedup in ffmpeg on your machine (cpu not capped to 8) but might break non-ffmpeg encoders like mpeg2 (watch out for this)<br>
><br>
if it was what we saw before: I confirm the 16 threads: "filebase cpu<br>
16". A render with mpeg2 leads to an error: "error render data". On<br>
the terminal there are these lines:<br>
tc: 0.000000<br>
FileMPEG::open_file: Running<br>
/home/paz/cinelerra5/cinelerra<wbr>-5.1/bin//mpeg2enc -v 0  -b 0 -q 15 -a 1<br>
-F 5 -H --no-constraints -V 500 -I 0 -M 16 -f 3 -g 45 -G 45 -s -R 0 -o<br>
'/home/paz/test-randrik15.m2v'<br>
sh: line 1: /home/paz/cinelerra5/cinelerra<wbr>-5.1/bin//mpeg2enc: No such<br>
file or directory<br>
filebase cpu 16<br>
FFMPEG::open_decoder: some stream have bad times:<br>
/home/paz/video_editing/prova/<wbr>1080/ocra.png<br>
Decoder png does not support device type vaapi.<br>
HW device init failed, using SW decode.<br>
file:/home/paz/video_editing/p<wbr>rova/1080/ocra.png<br>
  err: Operation not permitted<br>
filebase cpu 16<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
signal_entry_recoverable: got SIGPIPE my pid=4313<br>
Render::render_single: Session finished.</blockquote><div><br></div><div><br></div><div>aw, guess it tried to use mpeg2enc (i disabled building of this part of mjpegtools because it failed on termux. I was hoping hveg2enc will be used instead.. time for another patch...) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 0034 should give you gui format (pixels) selection in ffmpeg/yuv4mpeg muxer, good for piping non-4.2.0/8 bit data to external ffmpeg, watch out for hw acceleration breackage (should not happen but better to test) ..<br>
><br>
Maybe I don't understand correctly. The render window for y4m presents<br>
a choice of many pixel_formats. I tried a 422p10le render and it works<br>
without error.</blockquote><div><br></div><div>good... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 0033 stamps output (mov/mxf/mpeg?) with timecode of playback position at the time of encode on timeline - not sure how useful, but by manually offsetting timecode start you can easily make wideos with different startv timecode. watch out for dvd/bd creation breackage! (I think it dislikes non-0 start timecode)<br>
><br>
Never created dvd: I tried it and in Batch Render 2 files were formed.<br>
I started the render and at 100% of the first file I had a CinGG<br>
crash. The terminal also closed so I have no error messages. I have no<br>
dumps. The errors are probably because of me.<br>
</blockquote><div><br></div><div>no, there is unchecked by default option about using ffmpeg. Because apparently I busted mpeg2 encoder - try to check this option? </div>