I did some tests with the new and old x265. I report some data, while the terminal output is attached in test-x265.txt. I used a 5 min video in h264 4.2.0 but good quality. Size= 471 MB. x265-10bit: CPU 50-80% (multithread) 27.5 fps file size 46 MB x265-12bit: CPU 50-80% (multi) 25.5 fps file size 45 MB x265-Hi: CPU 80-90% (multi) 10.6 fps file size 1.7 GB x265-Lo(w): CPU 40-70% (single/multi) 34 fps file size 67.5 MB HEVC-vaapi CPU 0-50% (single) 85.8 fps file size 117 MB (I could not see the GPU engagement) Only in x265-lo do I perceive a small decay in quality compared to the original. All others are comparable. For me a great news (thanks Andrew!) is the exploitation of multithread; on the terminal you can read the sentence: "Thread pool created using 16 threads" I have a CPU 8c/16t. The only thing I regret is that the new x265 drivers introduce a CinGG build delay of 15 min. Before my entire compile was 5 min, now it's 20 min.
On Tuesday, July 27, 2021, Andrea paz via Cin <[email protected]> wrote:
I did some tests with the new and old x265. I report some data, while the terminal output is attached in test-x265.txt.
I used a 5 min video in h264 4.2.0 but good quality. Size= 471 MB.
x265-10bit: CPU 50-80% (multithread) 27.5 fps file size 46 MB
x265-12bit: CPU 50-80% (multi) 25.5 fps file size 45 MB
x265-Hi: CPU 80-90% (multi) 10.6 fps file size 1.7 GB
wow, this one is big!
x265-Lo(w): CPU 40-70% (single/multi) 34 fps file size 67.5 MB
HEVC-vaapi CPU 0-50% (single) 85.8 fps file size 117 MB (I could not see the GPU engagement)
Only in x265-lo do I perceive a small decay in quality compared to the original. All others are comparable.
For me a great news (thanks Andrew!) is the exploitation of multithread; on the terminal you can read the sentence: "Thread pool created using 16 threads" I have a CPU 8c/16t.
it also seems to use assembler as planned) but a bit of concern difference between reported number of encoded frames by x265 itself and Cinelerra: encoded 7470 frames in 272.39s (27.42 fps), 1167.83 kb/s, Avg QP:32.61 Render::render_single: Session finished. ** rendered 7500 frames in 272.418 secs, 27.531 fps does this mean you lost 30 frames somewhere? was this bug/difference present in unpatched Cin?
The only thing I regret is that the new x265 drivers introduce a CinGG build delay of 15 min. Before my entire compile was 5 min, now it's 20 min.
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
thanks! (but remembering history of my hacks it never hurt to test a bit more...)
I did some more tests with x265. The details can be found in the attached file, here I put a summary table where "Before" are the results of the previous test that used a build with ffmpeg-4.4 but without the latest patch. "Build" represents the test with ffmpeg-4.4 with the latest patch applied and "AppImage" represents the test done with appimage-multibit which has ffmpeg-4.3 with the latest patch. There are no big differences. Strange thing is that with "AppImage" we have correspondence of the project frames ("7500"), with the "Build" we still have the difference 7470 and 7500 that we had also in "Before". Shouldn't the "Build" with the "AppImage" be the same? Before Build AppImage x265-10-bit 27.5 fps 28.2 fps 27.8 fps x265-12-bit 25.5 fps 25.8 fps 25.35 fps x265-hi 10.6 fps 10.6 fps 10.9 fps If you have more specific tests to request, please let me know.
Andrea, thank you for doing the tests. It is worrisome about the 7470 versus 7500 frames. Are the generated files the same size? Does ydiff show any non-zero difference in the output? (cd to cinelerra directory; type "make ydiff"; then type "./ydiff video1.mp4 video2.mp4") I will do some small test also. On Mon, Aug 2, 2021 at 8:19 AM Andrea paz via Cin < [email protected]> wrote:
I did some more tests with x265. The details can be found in the attached file, here I put a summary table where "Before" are the results of the previous test that used a build with ffmpeg-4.4 but without the latest patch. "Build" represents the test with ffmpeg-4.4 with the latest patch applied and "AppImage" represents the test done with appimage-multibit which has ffmpeg-4.3 with the latest patch. There are no big differences. Strange thing is that with "AppImage" we have correspondence of the project frames ("7500"), with the "Build" we still have the difference 7470 and 7500 that we had also in "Before". Shouldn't the "Build" with the "AppImage" be the same?
Before Build AppImage
x265-10-bit 27.5 fps 28.2 fps 27.8 fps
x265-12-bit 25.5 fps 25.8 fps 25.35 fps
x265-hi 10.6 fps 10.6 fps 10.9 fps
If you have more specific tests to request, please let me know. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, Is there a flag when compiling x265 so that the user does not have to see these informational messages? I know they are good for us -- but most users will not want to see them. x265 [info]: HEVC encoder version 3.4 x265 [info]: build info [Linux][GCC 10.2.1][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main profile, Level-2 (Main tier) x265 [info]: Thread pool created using 16 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(4 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3 ,,,
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
thanks! (but remembering history of my hacks it never hurt to test a bit more...)
On Monday, August 2, 2021, Phyllis Smith via Cin <[email protected]> wrote:
Andrew, Is there a flag when compiling x265 so that the user does not have to see these informational messages? I know they are good for us -- but most users will not want to see them. x265 [info]: HEVC encoder version 3.4 x265 [info]: build info [Linux][GCC 10.2.1][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main profile, Level-2 (Main tier) x265 [info]: Thread pool created using 16 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(4 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
it seems at least part of this info printed by Encoder::printSummary() function in thirdparty/x265_3.5/source/encoder/encoder.cpp try to just unconditionally return from very first lines in it? like commenting out this 'if' line, while leaving return in place... $ cat thirdparty/x265_3.5/source/encoder/encoder.cpp | grep Summary -A 10 void Encoder::printSummary() { if (m_param->logLevel < X265_LOG_INFO) return;
,,,
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
thanks! (but remembering history of my hacks it never hurt to test a bit more...)
On Monday, August 2, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Monday, August 2, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, Is there a flag when compiling x265 so that the user does not have to see these informational messages? I know they are good for us -- but most users will not want to see them. x265 [info]: HEVC encoder version 3.4 x265 [info]: build info [Linux][GCC 10.2.1][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main profile, Level-2 (Main tier) x265 [info]: Thread pool created using 16 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(4 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
it seems at least part of this info printed by Encoder::printSummary() function in thirdparty/x265_3.5/source/encoder/encoder.cpp
try to just unconditionally return from very first lines in it?
like commenting out this 'if' line, while leaving return in place...
$ cat thirdparty/x265_3.5/source/encoder/encoder.cpp | grep Summary -A 10 void Encoder::printSummary() { if (m_param->logLevel < X265_LOG_INFO) return;
also you can try and disable some printing at thirdparty/x265_3.5/source/encoder/api.cpp look for x265_encoder function and lines x265_copy_params(zoneParam, p); x265_log(param, X265_LOG_INFO, "HEVC encoder version %s\n", PFX(ver x265_log(param, X265_LOG_INFO, "build info %s\n", PFX(build_info_st and call for 'x265_print_params(param);' and in x265_encoder_close call to encoder->printSummary(); sorry, this info printing a bit spread around x265's codebase
,,,
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
thanks! (but remembering history of my hacks it never hurt to test a bit more...)
On Tuesday, August 3, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Monday, August 2, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Monday, August 2, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, Is there a flag when compiling x265 so that the user does not have to see these informational messages? I know they are good for us -- but most users will not want to see them. x265 [info]: HEVC encoder version 3.4 x265 [info]: build info [Linux][GCC 10.2.1][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main profile, Level-2 (Main tier) x265 [info]: Thread pool created using 16 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(4 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
it seems at least part of this info printed by Encoder::printSummary() function in thirdparty/x265_3.5/source/encoder/encoder.cpp
try to just unconditionally return from very first lines in it?
like commenting out this 'if' line, while leaving return in place...
$ cat thirdparty/x265_3.5/source/encoder/encoder.cpp | grep Summary -A 10 void Encoder::printSummary() { if (m_param->logLevel < X265_LOG_INFO) return;
also you can try and disable some printing at
thirdparty/x265_3.5/source/encoder/api.cpp
look for x265_encoder function and lines
x265_copy_params(zoneParam, p); x265_log(param, X265_LOG_INFO, "HEVC encoder version %s\n", PFX(ver x265_log(param, X265_LOG_INFO, "build info %s\n", PFX(build_info_st
and call for 'x265_print_params(param);'
and in x265_encoder_close call to encoder->printSummary();
sorry, this info printing a bit spread around x265's codebase
you can also try to edit $ mcedit thirdparty/ffmpeg-4.4/libavcodec/libx265.c and just add this line .... ctx->params->logLevel = X265_LOG_NONE; just before ctx->encoder = ctx->api->encoder_open(ctx->params); it compiles but I currently can't test it - termux is rolling distro and right now xfwm4 apparently broken..
,,,
On Sunday, August 1, 2021, Andrea paz <[email protected]> wrote:
The correct frames are "7500", that is the ones reported by CinGG encoding. I verified on the timeline!
thanks! (but remembering history of my hacks it never hurt to test a bit more...)
The difference between appimage and build is that the former uses ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference between the 2 renders, see mediainfo test-1.txt (appimage) and test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The real video source has 7500 frame (5min 0sec at 25 fps)! (Note: as usual, I can't install ydiff, sorry! [paz@arch-paz cinelerra-5.1]$ make ydiff make: *** No rules for generating the "ydiff" target. Arrest.) PS: I think most users don't look at the messages on the terminal: appimage you have to specify it if you want to run from shell. If you compile from terminal, having multiple messages should not be a problem. In my opinion we can leave the messages without hiding them.
On Tuesday, August 3, 2021, Andrea paz <[email protected]> wrote:
The difference between appimage and build is that the former uses ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference between the 2 renders, see mediainfo test-1.txt (appimage) and test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The real video source has 7500 frame (5min 0sec at 25 fps)!
yeah, it seems last or 1 or 2 sec of stream is lost ( bad... i'll look into ffmpeg's mail list and other projects to see if there anything easy enough to fix. for now it seems upgrade to 4.4 still not good idea...
(Note: as usual, I can't install ydiff, sorry! [paz@arch-paz cinelerra-5.1]$ make ydiff make: *** No rules for generating the "ydiff" target. Arrest.)
PS: I think most users don't look at the messages on the terminal: appimage you have to specify it if you want to run from shell. If you compile from terminal, having multiple messages should not be a problem. In my opinion we can leave the messages without hiding them.
On Tuesday, August 3, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, August 3, 2021, Andrea paz <[email protected]> wrote:
The difference between appimage and build is that the former uses ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference between the 2 renders, see mediainfo test-1.txt (appimage) and test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The real video source has 7500 frame (5min 0sec at 25 fps)!
yeah, it seems last or 1 or 2 sec of stream is lost (
bad...
i'll look into ffmpeg's mail list and other projects to see if there anything easy enough to fix.
I tried to slightly alter condition in FFStream::encode_frame now it does not display flush errors at the end of encoding... if encode was much faster than timeline fps (still with 4.4) problem is, for me encoded avi/mov actually have correct number of frames, i checked with mediainfo and internal cingg info window.. but i am on 32-bit arm machine...
for now it seems upgrade to 4.4 still not good idea...
(Note: as usual, I can't install ydiff, sorry! [paz@arch-paz cinelerra-5.1]$ make ydiff make: *** No rules for generating the "ydiff" target. Arrest.)
PS: I think most users don't look at the messages on the terminal: appimage you have to specify it if you want to run from shell. If you compile from terminal, having multiple messages should not be a problem. In my opinion we can leave the messages without hiding them.
On Tuesday, August 3, 2021, Andrea paz <[email protected]> wrote:
The difference between appimage and build is that the former uses ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference between the 2 renders, see mediainfo test-1.txt (appimage) and test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The real video source has 7500 frame (5min 0sec at 25 fps)!
yeah, it seems last or 1 or 2 sec of stream is lost (
bad...
i'll look into ffmpeg's mail list and other projects to see if there anything easy enough to fix.
I tried to slightly alter condition in FFStream::encode_frame
*The Bad News*: In testing the attached patch, I could not find a difference in the video before and after or even with 4.3 versus 4.4. I think *Andrea* needs to test this because he has a definitive case that shows the problem. I tested 3 cases but they are all little files -- I think I did some the drop of the last frames a couple of days ago, but I was concentrating on testing something else at the time and had to keep focus on what I was doing. *The Good News:* Just a guess but if the root cause is found, it could conceivably be the problem with the bluray patch2 which was dropping the last few frames. now it does not display flush errors at the end of encoding... if encode
was much faster than timeline fps (still with 4.4)
problem is, for me encoded avi/mov actually have correct number of frames, i checked with mediainfo and internal cingg info window.. but i am on 32-bit arm machine...
for now it seems upgrade to 4.4 still not good idea...
More testing needed -- I was really hoping to get 4.4 in the July 31 upgrade but was waiting to hear back from the freelancer on a bluray patch 2 fix -- probably a good thing we held off.
PS: I think most users don't look at the messages on the terminal: appimage you have to specify it if you want to run from shell. If you compile from terminal, having multiple messages should not be a problem. In my opinion we can leave the messages without hiding them.
The messages do come in handy so I suppose it is better to leave them.
It is just now with AppImage, a lot of the users might just be typing in the executable from a terminal window instead of just clicking on an icon.
I have tried rendering in DNxHR_sq; ffv1 and VP9 and confirm that there are no issues with dropped frames. [Note (OT): if you remember my other tests with x265, the encoding fps were around 25 fps (T about 85°C). Even with VP9 they are around 24 fps and in fact it is a compressed codec, LonGOP and interframe like x265. Instead DNxHR and ffv1 are codecs studied just for editing and their greater efficiency is evident. DNxHR rendered at 111 fps with much lower temperatures (67°C) and with a CPU occupation of 20-30%. Ffv1 rendered at 88 fps; CPU 40% and T 70°C (I'm not sure but it seems to me that it also uses the GPU). The difference with compressed codecs in terms of quality and efficiency is huge. Even on the timeline they are much more efficient and playback is smoother. The only disadvantage is that they produce files of 4.3 GB instead of a few tens or hundreds of MB.]
Andrea, in a followup, to your email below. Does this mean that the patch, ffmpeg_flush_tmp.diff, fixed ffmpeg 4.4 so that it works the same as 4.3? I was confused if you had applied this patch or not or had just changed render formats. On Wed, Aug 4, 2021 at 1:31 AM Andrea paz <[email protected]> wrote:
I have tried rendering in DNxHR_sq; ffv1 and VP9 and confirm that there are no issues with dropped frames.
[Note (OT): if you remember my other tests with x265, the encoding fps were around 25 fps (T about 85°C). Even with VP9 they are around 24 fps and in fact it is a compressed codec, LonGOP and interframe like x265. Instead DNxHR and ffv1 are codecs studied just for editing and their greater efficiency is evident. DNxHR rendered at 111 fps with much lower temperatures (67°C) and with a CPU occupation of 20-30%. Ffv1 rendered at 88 fps; CPU 40% and T 70°C (I'm not sure but it seems to me that it also uses the GPU). The difference with compressed codecs in terms of quality and efficiency is huge. Even on the timeline they are much more efficient and playback is smoother. The only disadvantage is that they produce files of 4.3 GB instead of a few tens or hundreds of MB.]
Andrea, in a followup, to your email below. Does this mean that the patch, ffmpeg_flush_tmp.diff, fixed ffmpeg 4.4 so that it works the same as 4.3? I > was confused if you had applied this patch or not or had just changed render formats.
It seems to me that this patch is not in randrik14, so I didn't put it in. Where can I find it? What other randrik14 patches should I put for ffmpeg-4.4? Sorry for the confusion!
On Wednesday, August 11, 2021, Andrea paz via Cin < [email protected]> wrote:
Andrea, in a followup, to your email below. Does this mean that the patch, ffmpeg_flush_tmp.diff, fixed ffmpeg 4.4 so that it works the same as 4.3? I > was confused if you had applied this patch or not or had just changed render formats.
It seems to me that this patch is not in randrik14, so I didn't put it in. Where can I find it? What other randrik14 patches should I put for ffmpeg-4.4? Sorry for the confusion!
hopefully attached (I send it separately) --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I tried compiling the latest git by putting in the following patches: compile_multibit_X265.txt; ffmpeg_flush_tmp.diff and disallow_inserting_effect_if_disarmed.diff. I deleted ffmpeg-4.3 and its patches and added ffmpeg-4.4.tar.xz. The compilation fails; I attach cin5.log
On Wednesday, August 11, 2021, Andrea paz <[email protected]> wrote:
I tried compiling the latest git by putting in the following patches: compile_multibit_X265.txt; ffmpeg_flush_tmp.diff and disallow_inserting_effect_if_disarmed.diff. I deleted ffmpeg-4.3 and its patches and added ffmpeg-4.4.tar.xz. The compilation fails; I attach cin5.log
i guess some more patching from my series (randrik14) still required. will remake series...
The build was done without errors. But I'm not good at testing a patch, with 69 patches I really don't know what to do. Maybe it would be better to introduce the Cinelerra-CV method, in which you test single patch (or at least on a single feature), and then the result of the tests is discussed and possibly implemented. Only after that we move on to other patches.... What do you think?
On Wednesday, August 11, 2021, Andrea paz <[email protected]> wrote:
The build was done without errors. But I'm not good at testing a patch, with 69 patches I really don't know what to do. Maybe it would be better to introduce the Cinelerra-CV method, in which you test single patch (or at least on a single feature), and then the result of the tests is discussed and possibly implemented. Only after that we move on to other patches.... What do you think?
yeah.. 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.. then you can test 0067/68 duo.. you already tested 0069 (but it alters historical behavior) then you can look into testing 0063 (just small build optimization) 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) then 0042 - should be simple in that it adds exr sequence as format for background render 0041 should provide some speedup on reverse fast playback of i-only files (think ffv1?) 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) 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) .. 0033 stamps output (mov/mxfmmpeg?) 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) enough for now, other patches at least buildable on x86..
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.
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?
you already tested 0069 (but it alters historical behavior)
RMB on Gang None does not apply on unarmed tracks.
then you can look into testing 0063 (just small build optimization)
makefile presents corrections. I don't know what test to do!
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.
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
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
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.
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.
0033 stamps output (mov/mxfmmpeg?) 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.
On Thursday, August 12, 2021, Andrea paz <[email protected]> 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?
I'll try 70 tomorrow....
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?)
I would leave these 3 patches alone: better to stay with the original behavior...
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?
% CPU (top) about 23-30% in forward and 35-48% in reverse. 30-52% in fast forward and 60-120% in fast reverse.
no, there is unchecked by default option about using ffmpeg. Because apparently I busted mpeg2 encoder - try to check this option? I had already activated "ffmpeg". I tried again as root (last time I wasn't) and I still have crashes. I have dvdauthor but I didn't put the external dvd player (I should get it back, who knows where it is!). See image. At the terminal I have these messages:
tc: 7.933333 filebase cpu 16 filebase cpu 16 filebase cpu 16 filebase cpu 16 filebase cpu 16 Render::render_single: Session finished. ** rendered 695 frames in 11.879 secs, 58.507 fps running /home/paz/dvd_20210812-221356/dvd.sh INFO: [mplex] mplex version 2.2.0 (2.2.7 $Date: 2012-11-17 01:55:16 $) INFO: [mplex] File /home/paz/dvd_20210812-221356/dvd.m2v looks like an MPEG Video stream. INFO: [mplex] File /home/paz/dvd_20210812-221356/dvd.ac3 looks like an AC3 Audio stream. INFO: [mplex] Video stream 0: profile 8 selected - ignoring non-standard options! INFO: [mplex] Found 1 audio streams, 1 video streams and 0 subtitle streams INFO: [mplex] Selecting dvdauthor DVD output profile INFO: [mplex] Multiplexing video program stream! INFO: [mplex] Scanning for header info: Video stream e0 (/home/paz/dvd_20210812-221356/dvd.m2v) INFO: [mplex] VIDEO STREAM: e0 INFO: [mplex] Frame width : 720 INFO: [mplex] Frame height : 576 INFO: [mplex] Aspect ratio : 16:9 display INFO: [mplex] Picture rate : 25.000 frames/sec INFO: [mplex] Bit rate : 9000000 bits/sec INFO: [mplex] Vbv buffer size : 229376 bytes INFO: [mplex] CSPF : 0 INFO: [mplex] Scanning for header info: AC3 Audio stream 00 (/home/paz/dvd_20210812-221356/dvd.ac3) INFO: [mplex] AC3 frame size = 896 INFO: [mplex] AC3 AUDIO STREAM: INFO: [mplex] Bit rate : 28672 bytes/sec (224 kbit/sec) INFO: [mplex] Frequency : 48000 Hz INFO: [mplex] SYSTEMS/PROGRAM stream: INFO: [mplex] rough-guess multiplexed stream data rate : 9419800 INFO: [mplex] target data-rate specified : 10080000 INFO: [mplex] Setting specified specified data rate: 10080000 INFO: [mplex] Run-in delay = 10800 Video delay = 10800 Audio delay = 14400 INFO: [mplex] New sequence commences... INFO: [mplex] Video e0: buf= 0 frame=000000 sector=00000000 INFO: [mplex] Audio bd: buf= 0 frame=000000 sector=00000000 ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=18139 required(DTS)=18000 ++ WARN: [mplex] Video e0: buf= 79161 frame=000002 sector=00000122 ++ WARN: [mplex] Audio bd: buf= 221 frame=000002 sector=00000001 INFO: [mplex] STREAM bd completed INFO: [mplex] STREAM e0 completed INFO: [mplex] Multiplex completion at SCR=2493147. INFO: [mplex] Video e0: completed INFO: [mplex] Audio bd: completed INFO: [mplex] VIDEO_STATISTICS: e0 INFO: [mplex] Video Stream length: 27816771 bytes INFO: [mplex] Sequence headers: 41 INFO: [mplex] Sequence ends : 0 INFO: [mplex] No. Pictures : 696 INFO: [mplex] No. Groups : 41 INFO: [mplex] No. I Frames : 41 avg. size 70744 bytes INFO: [mplex] No. P Frames : 655 avg. size 38040 bytes INFO: [mplex] No. B Frames : 0 avg. size 0 bytes INFO: [mplex] Average bit-rate : 7993200 bits/sec INFO: [mplex] Peak bit-rate : 9622800 bits/sec INFO: [mplex] BUFFERING min 15 Buf max 235543 INFO: [mplex] AUDIO_STATISTICS: bd INFO: [mplex] Audio stream length 778624 bytes. INFO: [mplex] Frames : 869 INFO: [mplex] BUFFERING min 35 Buf max 6979 **ERROR: [mplex] MUX STATUS: Frame data under-runs detected! DVDAuthor::dvdauthor, version 0.7.2. Build options: gnugetopt imagemagick iconv freetype fribidi fontconfig Send bug reports to <[email protected]> INFO: default video format is PAL INFO: dvdauthor creating VTS STAT: Picking VTS 01 STAT: Processing /home/paz/dvd_20210812-221356/dvd.mpg... STAT: VOBU 32 at 21MB, 1 PGCs INFO: Video pts = 0.160 .. 28.000 INFO: Audio[0] pts = 0.160 .. 27.968 STAT: VOBU 41 at 27MB, 1 PGCs CHAPTERS: VTS[1/1] 0.000 INFO: Generating VTS with the following video attributes: INFO: MPEG version: mpeg2 INFO: TV standard: pal INFO: Aspect ratio: 16:9 INFO: Resolution: 720x576 INFO: Audio ch 0 format: ac3/2ch, 48khz drc, 'en' STAT: fixed 41 VOBUs INFO: dvdauthor creating table of contents INFO: Scanning /home/paz/dvd_20210812-221356/iso/VIDEO_TS/VTS_01_0.IFO To burn dvd, load blank media and run: growisofs -dvd-compat -Z /dev/dvd -dvd-video /home/paz/dvd_20210812-221356/iso Terminato
On Thursday, August 12, 2021, Andrea paz <[email protected]> wrote:
I'll try 70 tomorrow....
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?)
I would leave these 3 patches alone: better to stay with the original behavior...
ok
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?
% CPU (top) about 23-30% in forward and 35-48% in reverse. 30-52% in fast forward and 60-120% in fast reverse.
with patch and without patch?
no, there is unchecked by default option about using ffmpeg. Because apparently I busted mpeg2 encoder - try to check this option? I had already activated "ffmpeg". I tried again as root (last time I wasn't) and I still have crashes.
I found this thread from 15 years ago: https://www.mail-archive.com/[email protected]/msg06644.html https://www.mail-archive.com/[email protected]/msg06625.html try lowering bitrate to 9000 kbits/s...
I have dvdauthor but I didn't put the external dvd player (I should get it back, who knows where it is!). See image. At the terminal I have these messages:
tc: 7.933333 filebase cpu 16 filebase cpu 16 filebase cpu 16 filebase cpu 16 filebase cpu 16 Render::render_single: Session finished. ** rendered 695 frames in 11.879 secs, 58.507 fps running /home/paz/dvd_20210812-221356/dvd.sh INFO: [mplex] mplex version 2.2.0 (2.2.7 $Date: 2012-11-17 01:55:16 $) INFO: [mplex] File /home/paz/dvd_20210812-221356/dvd.m2v looks like an MPEG Video stream. INFO: [mplex] File /home/paz/dvd_20210812-221356/dvd.ac3 looks like an AC3 Audio stream. INFO: [mplex] Video stream 0: profile 8 selected - ignoring non-standard options! INFO: [mplex] Found 1 audio streams, 1 video streams and 0 subtitle streams INFO: [mplex] Selecting dvdauthor DVD output profile INFO: [mplex] Multiplexing video program stream! INFO: [mplex] Scanning for header info: Video stream e0 (/home/paz/dvd_20210812-221356/dvd.m2v) INFO: [mplex] VIDEO STREAM: e0 INFO: [mplex] Frame width : 720 INFO: [mplex] Frame height : 576 INFO: [mplex] Aspect ratio : 16:9 display INFO: [mplex] Picture rate : 25.000 frames/sec INFO: [mplex] Bit rate : 9000000 bits/sec INFO: [mplex] Vbv buffer size : 229376 bytes INFO: [mplex] CSPF : 0 INFO: [mplex] Scanning for header info: AC3 Audio stream 00 (/home/paz/dvd_20210812-221356/dvd.ac3) INFO: [mplex] AC3 frame size = 896 INFO: [mplex] AC3 AUDIO STREAM: INFO: [mplex] Bit rate : 28672 bytes/sec (224 kbit/sec) INFO: [mplex] Frequency : 48000 Hz INFO: [mplex] SYSTEMS/PROGRAM stream: INFO: [mplex] rough-guess multiplexed stream data rate : 9419800 INFO: [mplex] target data-rate specified : 10080000 INFO: [mplex] Setting specified specified data rate: 10080000 INFO: [mplex] Run-in delay = 10800 Video delay = 10800 Audio delay = 14400 INFO: [mplex] New sequence commences... INFO: [mplex] Video e0: buf= 0 frame=000000 sector=00000000 INFO: [mplex] Audio bd: buf= 0 frame=000000 sector=00000000 ++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=18139 required(DTS)=18000 ++ WARN: [mplex] Video e0: buf= 79161 frame=000002 sector=00000122 ++ WARN: [mplex] Audio bd: buf= 221 frame=000002 sector=00000001 INFO: [mplex] STREAM bd completed INFO: [mplex] STREAM e0 completed INFO: [mplex] Multiplex completion at SCR=2493147. INFO: [mplex] Video e0: completed INFO: [mplex] Audio bd: completed INFO: [mplex] VIDEO_STATISTICS: e0 INFO: [mplex] Video Stream length: 27816771 bytes INFO: [mplex] Sequence headers: 41 INFO: [mplex] Sequence ends : 0 INFO: [mplex] No. Pictures : 696 INFO: [mplex] No. Groups : 41 INFO: [mplex] No. I Frames : 41 avg. size 70744 bytes INFO: [mplex] No. P Frames : 655 avg. size 38040 bytes INFO: [mplex] No. B Frames : 0 avg. size 0 bytes INFO: [mplex] Average bit-rate : 7993200 bits/sec INFO: [mplex] Peak bit-rate : 9622800 bits/sec INFO: [mplex] BUFFERING min 15 Buf max 235543 INFO: [mplex] AUDIO_STATISTICS: bd INFO: [mplex] Audio stream length 778624 bytes. INFO: [mplex] Frames : 869 INFO: [mplex] BUFFERING min 35 Buf max 6979 **ERROR: [mplex] MUX STATUS: Frame data under-runs detected! DVDAuthor::dvdauthor, version 0.7.2. Build options: gnugetopt imagemagick iconv freetype fribidi fontconfig Send bug reports to <[email protected]>
INFO: default video format is PAL INFO: dvdauthor creating VTS STAT: Picking VTS 01
STAT: Processing /home/paz/dvd_20210812-221356/dvd.mpg... STAT: VOBU 32 at 21MB, 1 PGCs INFO: Video pts = 0.160 .. 28.000 INFO: Audio[0] pts = 0.160 .. 27.968 STAT: VOBU 41 at 27MB, 1 PGCs CHAPTERS: VTS[1/1] 0.000 INFO: Generating VTS with the following video attributes: INFO: MPEG version: mpeg2 INFO: TV standard: pal INFO: Aspect ratio: 16:9 INFO: Resolution: 720x576 INFO: Audio ch 0 format: ac3/2ch, 48khz drc, 'en'
STAT: fixed 41 VOBUs INFO: dvdauthor creating table of contents INFO: Scanning /home/paz/dvd_20210812-221356/iso/VIDEO_TS/VTS_01_0.IFO To burn dvd, load blank media and run: growisofs -dvd-compat -Z /dev/dvd -dvd-video /home/paz/dvd_20210812-221356/ iso Terminato
with patch and without patch?
Only with patch. Normal and reverse and then Fast forward and fast reverse. I did a build with just patches 33-39-44-66-70. there is an error with patch 70. It seems to be looking for patch 0005. [paz@arch-paz cinelerra-5.1]$ git am /home/paz/Download/randrik15/*.patch Applicazione in corso: Add timecode to output mov/mxf Applicazione in corso: Hack: raise cpu cap from 8 to 16 (might have bad effect on non-ffmpeg encoders) Applicazione in corso: HACK: make avi demuxer in ffmpeg use cin-specific seek flag (worked on dv avi) Applicazione in corso: Hack : attempt to fix last flush in ffmpeg.c Applicazione in corso: Fix mpeg2enc build/install (was broken by termux series) .git/rebase-apply/patch:35: space before tab in indent. EncoderJob *job; .git/rebase-apply/patch:36: space before tab in indent. mjpeg_debug( "Worker thread started" ); .git/rebase-apply/patch:46: space before tab in indent. for(;;) .git/rebase-apply/patch:47: space before tab in indent. { error: patch non riuscita: cinelerra-5.1/thirdparty/Makefile:397 error: cinelerra-5.1/thirdparty/Makefile: la patch non si applica correttamente error: cinelerra-5.1/thirdparty/src/mjpegtools-2.1.0.patch5: non esiste nell'indice Patch non riuscita a 0005 Fix mpeg2enc build/install (was broken by termux series) suggerimento: Usa 'git am --show-current-patch=diff' per visualizzare la patch non riuscita Una volta risolto questo problema, esegui "git am --continue". Se preferisci saltare questa patch, esegui invece "git am --skip". Per ripristinare il branch originario e terminare il patching, esegui "git am --abort". [paz@arch-paz cinelerra-5.1]$ git am --abort
On Friday, August 13, 2021, Andrea paz <[email protected]> wrote:
with patch and without patch?
Only with patch. Normal and reverse and then Fast forward and fast reverse.
I did a build with just patches 33-39-44-66-70. there is an error with patch 70. It seems to be looking for patch 0005.
yeah, sorry. One day I may learn how to collapse few related patches into one.. try to put attched patch in thirdparty/src?
[paz@arch-paz cinelerra-5.1]$ git am /home/paz/Download/randrik15/*.patch Applicazione in corso: Add timecode to output mov/mxf Applicazione in corso: Hack: raise cpu cap from 8 to 16 (might have bad effect on non-ffmpeg encoders) Applicazione in corso: HACK: make avi demuxer in ffmpeg use cin-specific seek flag (worked on dv avi) Applicazione in corso: Hack : attempt to fix last flush in ffmpeg.c Applicazione in corso: Fix mpeg2enc build/install (was broken by termux series) .git/rebase-apply/patch:35: space before tab in indent. EncoderJob *job; .git/rebase-apply/patch:36: space before tab in indent. mjpeg_debug( "Worker thread started" ); .git/rebase-apply/patch:46: space before tab in indent. for(;;) .git/rebase-apply/patch:47: space before tab in indent. { error: patch non riuscita: cinelerra-5.1/thirdparty/Makefile:397 error: cinelerra-5.1/thirdparty/Makefile: la patch non si applica correttamente error: cinelerra-5.1/thirdparty/src/mjpegtools-2.1.0.patch5: non esiste nell'indice Patch non riuscita a 0005 Fix mpeg2enc build/install (was broken by termux series) suggerimento: Usa 'git am --show-current-patch=diff' per visualizzare la patch non riuscita Una volta risolto questo problema, esegui "git am --continue". Se preferisci saltare questa patch, esegui invece "git am --skip". Per ripristinare il branch originario e terminare il patching, esegui "git am --abort". [paz@arch-paz cinelerra-5.1]$ git am --abort
try to put attched patch in thirdparty/src?
It looks like the same error: [paz@arch-paz ~]$ git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cinelerra.git" cinelerra5 Clone in 'cinelerra5' in corso... remote: Enumerating objects: 11722, done. remote: Counting objects: 100% (11722/11722), done. remote: Compressing objects: 100% (8758/8758), done. remote: Total 11722 (delta 3335), reused 10524 (delta 2785), pack-reused 0 Ricezione degli oggetti: 100% (11722/11722), 145.30 MiB | 742.00 KiB/s, fatto. Risoluzione dei delta: 100% (3335/3335), fatto. [paz@arch-paz ~]$ cd /home/paz/cinelerra5/cinelerra-5.1 [paz@arch-paz cinelerra-5.1]$ git am /home/paz/Download/randrik15/*.patch Applicazione in corso: Add timecode to output mov/mxf Applicazione in corso: Hack: raise cpu cap from 8 to 16 (might have bad effect on non-ffmpeg encoders) Applicazione in corso: HACK: make avi demuxer in ffmpeg use cin-specific seek flag (worked on dv avi) Applicazione in corso: Hack : attempt to fix last flush in ffmpeg.c Applicazione in corso: Fix mpeg2enc build/install (was broken by termux series) .git/rebase-apply/patch:35: space before tab in indent. EncoderJob *job; .git/rebase-apply/patch:36: space before tab in indent. mjpeg_debug( "Worker thread started" ); .git/rebase-apply/patch:46: space before tab in indent. for(;;) .git/rebase-apply/patch:47: space before tab in indent. { error: patch non riuscita: cinelerra-5.1/thirdparty/Makefile:397 error: cinelerra-5.1/thirdparty/Makefile: la patch non si applica correttamente error: cinelerra-5.1/thirdparty/src/mjpegtools-2.1.0.patch5: non esiste nell'indice Patch non riuscita a 0005 Fix mpeg2enc build/install (was broken by termux series) suggerimento: Usa 'git am --show-current-patch=diff' per visualizzare la patch non riuscita Una volta risolto questo problema, esegui "git am --continue". Se preferisci saltare questa patch, esegui invece "git am --skip". Per ripristinare il branch originario e terminare il patching, esegui "git am --abort". [paz@arch-paz cinelerra-5.1]$ git am --abort I tried to apply the mjpegtool-2.1.0.patch5 patch in src, but I can't find the file to patch: [paz@arch-paz src]$ patch < mjpegtools-2.1.0.patch5 can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- ./mpeg2enc/seqencoder.cc.orig 2021-08-12 22:15:24.907277309 +0300 |+++ ./mpeg2enc/seqencoder.cc 2021-08-12 22:17:49.471277317 +0300 -------------------------- File to patch:
On Friday, August 13, 2021, Andrea paz <[email protected]> wrote:
try to put attched patch in thirdparty/src?
It looks like the same error:
[paz@arch-paz ~]$ git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cinelerra.git" cinelerra5 Clone in 'cinelerra5' in corso... remote: Enumerating objects: 11722, done. remote: Counting objects: 100% (11722/11722), done. remote: Compressing objects: 100% (8758/8758), done. remote: Total 11722 (delta 3335), reused 10524 (delta 2785), pack-reused 0 Ricezione degli oggetti: 100% (11722/11722), 145.30 MiB | 742.00 KiB/s, fatto. Risoluzione dei delta: 100% (3335/3335), fatto. [paz@arch-paz ~]$ cd /home/paz/cinelerra5/cinelerra-5.1 [paz@arch-paz cinelerra-5.1]$ git am /home/paz/Download/randrik15/*.patch Applicazione in corso: Add timecode to output mov/mxf Applicazione in corso: Hack: raise cpu cap from 8 to 16 (might have bad effect on non-ffmpeg encoders) Applicazione in corso: HACK: make avi demuxer in ffmpeg use cin-specific seek flag (worked on dv avi) Applicazione in corso: Hack : attempt to fix last flush in ffmpeg.c Applicazione in corso: Fix mpeg2enc build/install (was broken by termux series) .git/rebase-apply/patch:35: space before tab in indent. EncoderJob *job; .git/rebase-apply/patch:36: space before tab in indent. mjpeg_debug( "Worker thread started" ); .git/rebase-apply/patch:46: space before tab in indent. for(;;) .git/rebase-apply/patch:47: space before tab in indent. { error: patch non riuscita: cinelerra-5.1/thirdparty/Makefile:397 error: cinelerra-5.1/thirdparty/Makefile: la patch non si applica correttamente error: cinelerra-5.1/thirdparty/src/mjpegtools-2.1.0.patch5: non esiste nell'indice Patch non riuscita a 0005 Fix mpeg2enc build/install (was broken by termux series) suggerimento: Usa 'git am --show-current-patch=diff' per visualizzare la patch non riuscita Una volta risolto questo problema, esegui "git am --continue". Se preferisci saltare questa patch, esegui invece "git am --skip". Per ripristinare il branch originario e terminare il patching, esegui "git am --abort". [paz@arch-paz cinelerra-5.1]$ git am --abort
I tried to apply the mjpegtool-2.1.0.patch5 patch in src, but I can't find the file to patch:
[paz@arch-paz src]$ patch < mjpegtools-2.1.0.patch5 can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- ./mpeg2enc/seqencoder.cc.orig 2021-08-12 22:15:24.907277309 +0300 |+++ ./mpeg2enc/seqencoder.cc 2021-08-12 22:17:49.471277317 +0300 -------------------------- File to patch:
just cp (copy) it into this directory...
The first message is the one with the simple copy of the patch; but nothing has changed with respect to the previous error. So I try appling the patch, knowing it was wrong, but I didn't know what else to do.
Andrew, in randrik15, I think this patch is inconsistent. Could you recheck?
then 0042 - should be simple in that it adds exr sequence as format for background render
That is: 0042-Add-openEXR-format-for-background-render.patch @@ -92,7 +92,10 @@ void FormatPopup::create_objects() if(!use_brender) post_item(FILE_TIFF); post_item(FILE_TIFF_LIST); - +#ifdef HAVE_OPENEXR *+ if(use_brender) */ should this not be: if (!use_brender) like the ones above? */* + post_item(FILE_EXR_LIST); +#endif update(&format_items, 0, 0, 1); }
On Saturday, August 14, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, in randrik15, I think this patch is inconsistent. Could you recheck?
then 0042 - should be simple in that it adds exr sequence as format for background render
That is: 0042-Add-openEXR-format-for-background-render.patch @@ -92,7 +92,10 @@ void FormatPopup::create_objects() if(!use_brender) post_item(FILE_TIFF); post_item(FILE_TIFF_LIST); - +#ifdef HAVE_OPENEXR *+ if(use_brender) */ should this not be: if (!use_brender) like the ones above? */* + post_item(FILE_EXR_LIST); +#endif update(&format_items, 0, 0, 1); }
I think you can modify it like example above - just it worked for me in this form - but I have not tried to render individual (single) exrs
Checked into GIT 0042-Add-openEXR-format-for-background-render.patch from randrik15 (or 0044 from randrik14) -- this adds EXR Sequence as a choice in Settings->Preferences, Performance tab, for Background Rendering File Format Checked into GIT 0063-libvpx-disable-examples-and-unit-tests.patchfrom randrik15 (or 0065 from randrik14) -- this disables building unit-tests and examples in libvpx, thus saving quite a lot of disk space and some time -- this required a change to the "multibit" compile patch to apply that patch correctly to thirdparty/Makefile Maybe it would be better to introduce the Cinelerra-CV method, in which you
test single patch (or at least on a single feature), and then the result of the tests is discussed and possibly implemented. Only after that we move on to other patches.... What do you think?
It is hard to keep up with Andrew's changes, but glad to have them so CinGG improves and keeps up with the library releases. It would be easier to get one at a time though. For example as long as I was applying the 0063 patch, I had to check (1) 0032-Add-multilib-x265-slower-compilation-but-you-can-ren.patch (initial patch which was checked in as compile_multibit.patch to prevent confusion), (2) 0060-Add-x265-3.5-multilib-patch3-should-be-faster-at-com.patch (which seemed to remove "make"), (3) 0061-x265-patch3-was-malformed.patch (which only seemed to add "make -j 1" back for 32-bit) and (4) 0064-sigh-i-deleted-make-in-x265_3.5.patch3-restored.patch (which was such an interesting name !! and replaced "make -j 1 with "make"). Needless to say, I got a little lost. FFmpeg 4.4 update - the freelancer who "supposedly" had a fix for bluray patch2, got Covid and today said he was recuperating but still sent to fix. Another freelancer who "supposedly" knows ffmpeg, is looking at the problem but does not expect a quick fix. Bummer.
On Monday, August 16, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Checked into GIT 0042-Add-openEXR-format-for-background-render.patch from randrik15 (or 0044 from randrik14) -- this adds EXR Sequence as a choice in Settings->Preferences, Performance tab, for Background Rendering File Format Checked into GIT 0063-libvpx-disable-examples-and-unit-tests.patchfrom randrik15 (or 0065 from randrik14) -- this disables building unit-tests and examples in libvpx, thus saving quite a lot of disk space and some time -- this required a change to the "multibit" compile patch to apply that patch correctly to thirdparty/Makefile
Maybe it would be better to introduce the Cinelerra-CV method, in which
you test single patch (or at least on a single feature), and then the result of the tests is discussed and possibly implemented. Only after that we move on to other patches.... What do you think?
It is hard to keep up with Andrew's changes, but glad to have them so CinGG improves and keeps up with the library releases. It would be easier to get one at a time though.
For example as long as I was applying the 0063 patch, I had to check (1) 0032-Add-multilib-x265-slower-compilation-but-you-can-ren.patch (initial patch which was checked in as compile_multibit.patch to prevent confusion), (2) 0060-Add-x265-3.5-multilib-patch3-should-be-faster-at-com.patch (which seemed to remove "make"), (3) 0061-x265-patch3-was-malformed.patch (which only seemed to add "make -j 1" back for 32-bit) and (4) 0064-sigh-i-deleted-make-in-x265_3.5.patch3-restored.patch (which was such an interesting name !! and replaced "make -j 1 with "make"). Needless to say, I got a little lost.
yeah, sorry ( there is git method for uniting few patches, but I haven't tried it yet..
FFmpeg 4.4 update - the freelancer who "supposedly" had a fix for bluray patch2, got Covid and today said he was recuperating but still sent to fix. Another freelancer who "supposedly" knows ffmpeg, is looking at the problem but does not expect a quick fix. Bummer.
ow, covid sounds bad ( thankfully programming is one of those activities you can do from home, still... there ususally some need for food and household items.. so, stay safe!
Bummer outcome of ffmpg_flush_tmp.diff as stated below:
The difference between appimage and build is that the former uses
ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference between the 2 renders, see mediainfo test-1.txt (appimage) and test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The real video source has 7500 frame (5min 0sec at 25 fps)!
yeah, it seems last or 1 or 2 sec of stream is lost (
bad...
i'll look into ffmpeg's mail list and other projects to see if there anything easy enough to fix.
I tried to slightly alter condition in FFStream::encode_frame
now it does not display flush errors at the end of encoding... if encode was much faster than timeline fps (still with 4.4)
problem is, for me encoded avi/mov actually have correct number of frames, i checked with mediainfo and internal cingg info window.. but i am on 32-bit arm machine...
for now it seems upgrade to 4.4 still not good idea...
4.4 is dropping something on the end even with the ffmpeg_flush_tnp.diff patch installed. Unfortunately this patch had no effect in resolving issue so not putting it in. Need more eyes to look around the web to see if anyone else is reporting "it seems last or 1 or 2 sec of stream is lost" as Andrew quote stated.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith