[Cin] Test rendering whit x265

Thu Aug 12 20:20:44 CEST 2021

On Thursday, August 12, 2021, Andrea paz <gamberucci.andrea at gmail.com>
wrote:

> I tested with a build where all the patches are present.
>
> > I think 0066 from this series should work even with ffmpeg 4.3...
> > it should fix (hide?) those error messages at the end of fast encoding..
> >
> with x265 I still see several messages about the codec; with h264 I
> don't see them. They don't look like error messages to me, so I don't
> think they're what you're referring to.

yeah, I mean ones about eagain error, not [info] messages from x265..

>
> > then you can test 0067/68  duo..
> >
> unlike my pdf now has the following results: RMB in any Gang mode does
> not apply to unarmed tracks. Do these patches only apply to Gang
> Channels and Gang Media?

i think this is effect of next patch,  for 076/68 yo need to change
ARMED_IN_GANG_MODE 0 to 1 in. bcast5/Cinelerra_rc

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.

> > you already tested 0069 (but it alters historical behavior)
> >
> RMB on Gang None does not apply on unarmed tracks.

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?)

>
> > then you can look into testing 0063 (just small build optimization)
> >
> makefile presents corrections. I don't know what test to do!

just fact build do not break, and  now going a bit faster and takes a bit
less space..

> > 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)
> >
> I'm not sure how to test the seek; I put several dv files, I cut and
> put transitions. the playback runs at the right fps without dips.
> There are no messages to the terminal.

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...

>
> > then 0042 - should be simple in that it adds exr sequence as format for
> background render
> >
> exr sequence option has appeared. Sequence created more slowly. A
> frame in jpeg is 14.7 KB, a frame in exr is 10.6 MB

you can choice another type of compression same way you can select jpeg
quality - by clicking on wrench icon nearby..

>
> > 0041 should provide some speedup on reverse fast playback of i-only
> files (think ffv1?)
> >
> I created a small file ffv1: normal and fast reverse = normal and fast
> forward = same source fps

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?

> > 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)
> >
> if it was what we saw before: I confirm the 16 threads: "filebase cpu
> 16". A render with mpeg2 leads to an error: "error render data". On
> the terminal there are these lines:
> tc: 0.000000
> FileMPEG::open_file: Running
> /home/paz/cinelerra5/cinelerra-5.1/bin//mpeg2enc -v 0  -b 0 -q 15 -a 1
> -F 5 -H --no-constraints -V 500 -I 0 -M 16 -f 3 -g 45 -G 45 -s -R 0 -o
> '/home/paz/test-randrik15.m2v'
> sh: line 1: /home/paz/cinelerra5/cinelerra-5.1/bin//mpeg2enc: No such
> file or directory
> filebase cpu 16
> FFMPEG::open_decoder: some stream have bad times:
> /home/paz/video_editing/prova/1080/ocra.png
> Decoder png does not support device type vaapi.
> HW device init failed, using SW decode.
> file:/home/paz/video_editing/prova/1080/ocra.png
>   err: Operation not permitted
> filebase cpu 16
> signal_entry_recoverable: got SIGPIPE my pid=4313
> signal_entry_recoverable: got SIGPIPE my pid=4313
> signal_entry_recoverable: got SIGPIPE my pid=4313
> signal_entry_recoverable: got SIGPIPE my pid=4313
> signal_entry_recoverable: got SIGPIPE my pid=4313
> signal_entry_recoverable: got SIGPIPE my pid=4313
> Render::render_single: Session finished.

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...)

>
> > 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) ..
> >
> Maybe I don't understand correctly. The render window for y4m presents
> a choice of many pixel_formats. I tried a 422p10le render and it works
> without error.

good...

>
> > 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)
> >
> Never created dvd: I tried it and in Batch Render 2 files were formed.
> I started the render and at 100% of the first file I had a CinGG
> crash. The terminal also closed so I have no error messages. I have no
> dumps. The errors are probably because of me.
>

no, there is unchecked by default option about using ffmpeg. Because
apparently I busted mpeg2 encoder - try to check this option?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210812/9212d936/attachment.htm>