Andrew, yes it works with new ffmpeg-4.4.patchB. The Freelancer provided changes to libavcodec/encode.c to get it working. If you look at encode.c for 4.3 versus 4.4 it has been wildly changed and that caused a problem for CinGG. Andrew tested his big file that was getting the tail (the word tail is an interesting description!) too. And thank goodness for bluray or we might not have discovered this until the users did. I did remove the debug and print statements from the Freelancer provided fixes but not from the attached here. On Fri, Aug 27, 2021 at 3:18 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
does it work finally without eating video's tail? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, also a single code line change (NOT debug/fprintf stuff) was needed in cinelerra's ffmpeg.C file -- line 606 "if ( ret == AVERROR(EAGAIN) && !frame ) continue; ". The Freelancer had worked with ffmpeg before and that is what it took to get this mod -- ffmpeg is just such a big complicated program. On Fri, Aug 27, 2021 at 6:53 AM Phyllis Smith <[email protected]> wrote:
Andrew, yes it works with new ffmpeg-4.4.patchB. The Freelancer provided changes to libavcodec/encode.c to get it working. If you look at encode.c for 4.3 versus 4.4 it has been wildly changed and that caused a problem for CinGG. Andrew tested his big file that was getting the tail (the word tail is an interesting description!) too. And thank goodness for bluray or we might not have discovered this until the users did.
I did remove the debug and print statements from the Freelancer provided fixes but not from the attached here.
On Fri, Aug 27, 2021 at 3:18 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
does it work finally without eating video's tail? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Compiled by git also applying the multibit patch. All OK. Playback and various rendering formats: all OK; except cinepak.qt which leads to a freeze. I remember it happened also with ffmpeg-4.3. The "shape wipe" transition doesn't work, I'm not sure but I think it didn't work before either. The other transitions work fine. I added the new plugins in expanders.txt; However, I think I broke the formatting of the file and it gives me a dump at startup. Going back to the previous expanders.txt gives no problems. I attach expanders-dump.txt and the dump. PS: in plugin.opts i've corrected "dresser" in "deesser". I also attach this file even though it's just a typo in one word. For Andrew, who did not see my previous email, I attach the terminal messages when I tried rendering with ffmpeg-4.4 (test.txt).
On Friday, August 27, 2021, Andrea paz via Cin <[email protected]> wrote:
Compiled by git also applying the multibit patch. All OK. Playback and various rendering formats: all OK; except cinepak.qt which leads to a freeze. I remember it happened also with ffmpeg-4.3.
may be it just encodes _very_ slowly? like 20 min for ~1 min video with 320x200 sized frame... single-threaded...
The "shape wipe" transition doesn't work, I'm not sure but I think it didn't work before either. The other transitions work fine.
hm, strange.. can you try to debug this a bit (for example was it working in previous appimages/tagged releases?)
I added the new plugins in expanders.txt; However, I think I broke the formatting of the file and it gives me a dump at startup. Going back to the previous expanders.txt gives no problems. I attach expanders-dump.txt and the dump.
ow, dumps-on-startup are bad ( (esp. if you can so easily create them, by editing text file). I hope this was something simple, like too small static allocation.... will look into code.
PS: in plugin.opts i've corrected "dresser" in "deesser". I also attach this file even though it's just a typo in one word.
For Andrew, who did not see my previous email, I attach the terminal messages when I tried rendering with ffmpeg-4.4 (test.txt).
thanks
On Friday, August 27, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Friday, August 27, 2021, Andrea paz via Cin <[email protected]> wrote:
Compiled by git also applying the multibit patch. All OK. Playback and various rendering formats: all OK; except cinepak.qt which leads to a freeze. I remember it happened also with ffmpeg-4.3.
may be it just encodes _very_ slowly? like 20 min for ~1 min video with 320x200 sized frame... single-threaded...
The "shape wipe" transition doesn't work, I'm not sure but I think it didn't work before either. The other transitions work fine.
hm, strange.. can you try to debug this a bit (for example was it working in previous appimages/tagged releases?)
I added the new plugins in expanders.txt; However, I think I broke the formatting of the file and it gives me a dump at startup. Going back to the previous expanders.txt gives no problems. I attach expanders-dump.txt and the dump.
ow, dumps-on-startup are bad ( (esp. if you can so easily create them, by editing text file). I hope this was something simple, like too small static allocation.... will look into code.
PS: in plugin.opts i've corrected "dresser" in "deesser". I also attach this file even though it's just a typo in one word.
For Andrew, who did not see my previous email, I attach the terminal messages when I tried rendering with ffmpeg-4.4 (test.txt).
thanks
well, in x265-10 bit encode we still see message about encoding 7499 (not 7500) frames (from x265 library itself) . I hope this is bug in reporting, but can you add some specific image/effect at this very end frame and try to play resulted encode with, say, ffplay? (i think it will freeze last frame on display)
may be it just encodes _very_ slowly? like 20 min for ~1 min video with 320x200 sized frame... single-threaded...
True: 7:43 min for 9 seconds of video; single thread; freeze (temporarily) to 10% and then to 95%.
hm, strange.. can you try to debug this a bit (for example was it working in previous appimages/tagged releases?)
The video transitions that don't work are: BandWipe; Wipe; Dissolve; Shape Wipe and IrisSquare. They don't work in git, in the latest appimage or even in appimage 20201030. No error on the terminal.
well, in x265-10 bit encode we still see message about encoding 7499 (not 7500) frames (from x265 library itself) . I hope this is bug in reporting, but can you add some specific image/effect at this very end frame and try to play resulted encode with, say, ffplay? (i think it will freeze last frame on display)
Yes; trying a render with x265-10-bit and playing back the file obtained with ffply I get a freeze in the last frame with the last line of the terminal (indicating the momentary value: 19.46 A-V ...) that keeps increasing the number to infinity and I have to stop with ctrl+c. The same thing happens with DNxHR and x264. See image.
On Friday, August 27, 2021, Andrea paz <[email protected]> wrote:
may be it just encodes _very_ slowly? like 20 min for ~1 min video with 320x200 sized frame... single-threaded...
True: 7:43 min for 9 seconds of video; single thread; freeze (temporarily) to 10% and then to 95%.
hm, strange.. can you try to debug this a bit (for example was it working in previous appimages/tagged releases?)
The video transitions that don't work are: BandWipe; Wipe; Dissolve; Shape Wipe and IrisSquare. They don't work in git, in the latest appimage or even in appimage 20201030. No error on the terminal.
well, if i add silence to video track, and then add iris square transition to very end of first fragment (so bar indicating its legth will cover some empty space on track) - it seems to work... but i get crash when I initially tried to blade-cut video, add transition, played with settings like 'video output driver' abd 'cache transition' and then tried to insert silence at very same frame boundary where I had transition start: ------- Log file is /data/data/com.termux/files/home/.vnc/localhost:1.log Cinelerra Infinity - built: Aug 1 2021 13:38:03 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. (xfwm4:23212): xfwm4-WARNING **: 19:53:13.259: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined BC_WindowBase::init_im: Could not open input method. BC_Theme::get_image: image "mode_reflect" not found. BC_Theme::get_image: image "mode_average" not found. BC_Theme::get_image: image "mode_normals" not found. RenderFarmClient::main_loop: client started FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 1 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 1 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 AudioPulse::open_output 110: failed server=(null) Connection refused AudioPulse::open_output 110: failed server=(null) Connection refused AudioPulse::open_output 110: failed server=(null) Connection refused FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 AudioPulse::open_output 110: failed server=(null) Connection refused AudioPulse::open_output 110: failed server=(null) Connection refused FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 FFMPEG::open_decoder: some stream times estimated: /data/data/com.termux/files/home/av1-cpu5-crf10.mkv filebase cpu 8 signal_entry: got SIGFPE my pid=23213 execution table size=0: signal_entry: lock table size=38 0xf1168f00 CWindowTool::input_lock, CWindowTool::run 0xf0404230 0xf5793d68 BC_DialogThread::active_lock, BC_DialogThread::run 0xf0202230 * 0xf1591200 RecordSetChannel::change_channel, (null) 0xef272230 0xf1d7f680 ChannelInfo::scan_lock, (null) 0xef171230 0xf1d7f6a0 SWindow::swin_lock, (null) 0xef070230 0xf6523370 MWindow::run_lock, MWindow::run 0xf7f5bfc0 * 0xf6bfe9a0 BC_Synchronous::next_command, BC_Synchronous::run 0xee666230 0xf009e980 PlaybackEngine::output_lock, PlaybackEngine::run 0xefc7c230 0xf1d7fa40 MainIndexes::input_lock, MainIndexes::run 1 0xeed6d230 0xf6533180 BC_Repeater::pause_lock, BC_Repeater::run 0xed6fc230 0xf7f5bfc0 0xf5a322a0 VIconThread::draw_lock, VIconThread::run 0 0xf0606230 0xf1e5e720 BRenderThread::input_lock, BRenderThread::run 0xeea6a230 0xf1d7f700 BC_Repeater::pause_lock, BC_Repeater::run 0xeef6f230 0xf7f5bfc0 0xf111e2c0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xf5efc230 0xf1d7f780 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xee868230 0xf1d7faa0 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xee767230 0xf5a32b80 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xee969230 0xf009e000 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xf0202230 0xf152cd80 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xef575230 0xf152cd40 ResourceThreadBase::draw_lock, ResourceThreadBase::run 0xef878230 0xf1283080 BC_WindowBase::event_condition, BC_WindowBase::get_event 0xf7f5bfc0 0xf009adb0 FFStream::frm_lock, FFStream::decode 0xef777230 * 0xf1283020 PlaybackEngine::output_lock, PlaybackEngine::run 0xf0303230 lock_items: 23 lock_frees: 15 BC_Trace::delete_temps: deleting 1 temp files /data/data/com.termux/files/home/tmp/cinelerra.49e9e11c-d2cf-4eb6-b2f1-477ebaed03ac SigHandler::signal_handler total files=0 ./cin.sh: line 14: 23213 Aborted LD_PRELOAD=$PREFIX/lib/libandroid-shmem.so bin/cin ----- not yet tried to reproduce it...
well, in x265-10 bit encode we still see message about encoding 7499 (not 7500) frames (from x265 library itself) . I hope this is bug in reporting, but can you add some specific image/effect at this very end frame and try to play resulted encode with, say, ffplay? (i think it will freeze last frame on display)
Yes; trying a render with x265-10-bit and playing back the file obtained with ffply I get a freeze in the last frame with the last line of the terminal (indicating the momentary value: 19.46 A-V ...) that keeps increasing the number to infinity and I have to stop with ctrl+c. The same thing happens with DNxHR and x264. See image.
well, this is that I remembered. Thing is - you hopefully can use this behavior if you replace last frame with strongly different from normal end of piece/track image, like red square taking all screen space. Idea is to be sure we encode all video frames as presented on timeline... sorry for additional load, just need to recompile latest git (but I hope to backup some local patches here first)
Andrea, ffplay always works this way for me and always has. So I just use ctrl+c.
Yes; trying a render with x265-10-bit and playing back the file obtained with ffply I get a freeze in the last frame with the last line of the terminal (indicating the momentary value: 19.46 A-V ...) that keeps increasing the number to infinity and I have to stop with ctrl+c. The same thing happens with DNxHR and x264. See image.
Video Transition: Forgive me, I'm so stupid I hadn't thought of the obvious. Thank you Andrew for your patience. All video transitions work fine, I was only not seeing their effect because I was cutting (X) one same edit and thus its continuity did not show the effect of the transition. Excuse me! Expanders.txt: I remember that even the first time expanders.txt was introduced I had broken the formatting with some changes. I use Kwrite for plain text; apparently it has different support for text encodings than what is used in expanders.txt Cinepak: Cinepak works and gets to the end of the rendering. Only on my system it is so slow that it seems to freeze and not work. It took me 8 min to render a 9 second video! With the other codecs it takes me about 4-9 seconds.... (Note: ffmpeg-4.4 adds encoding to new formats: cineform HD; SpeedHQ and PFM. I'll try to make some presets later). Last frame rendering: The video (290 frames) with the last red frame, was rendered in CinGG. Then it was re-imported in CinGG and the last red frame is visible; the frame count is right: always 290 frames. Even with external playes the last red frame is visible. I would say it's a counting problem, but the result is right. So for me it is OK. [There's too much confusion in my head lately; I better take a break....]
On Saturday, August 28, 2021, Andrea paz via Cin <[email protected]> wrote:
Video Transition: Forgive me, I'm so stupid I hadn't thought of the obvious. Thank you Andrew for your patience. All video transitions work fine, I was only not seeing their effect because I was cutting (X) one same edit and thus its continuity did not show the effect of the transition. Excuse me!
Expanders.txt: I remember that even the first time expanders.txt was introduced I had broken the formatting with some changes. I use Kwrite for plain text; apparently it has different support for text encodings than what is used in expanders.txt
Cinepak: Cinepak works and gets to the end of the rendering. Only on my system it is so slow that it seems to freeze and not work. It took me 8 min to render a 9 second video! With the other codecs it takes me about 4-9 seconds.... (Note: ffmpeg-4.4 adds encoding to new formats: cineform HD; SpeedHQ and PFM. I'll try to make some presets later).
Last frame rendering: The video (290 frames) with the last red frame, was rendered in CinGG. Then it was re-imported in CinGG and the last red frame is visible; the frame count is right: always 290 frames. Even with external playes the last red frame is visible. I would say it's a counting problem, but the result is right. So for me it is OK.
[There's too much confusion in my head lately; I better take a break....]
sorry for such high load... On the last item - can you re-test 'last frame rendering' with longer (7500 frames) timeline? not urgent, when you will have time....
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
can you re-test 'last frame rendering' with longer (7500 frames) timeline? not urgent, when you will have time....
Always the same result, as in test.txt made 2 days ago: encoded 7499 frames in 270.06s (27.77 fps), 1165.19 kb/s, Avg QP:32.60 Render::render_single: Session finished. ** rendered 7500 frames in 272.158 secs, 27.558 fps Could it be that cnt1 starts from the first frame calling it 0 and cnt starts from the same first frame calling it 1? (I actually don't even understand why there are two counts! Maybe we can ask the freelancer, since he solved the: 7470 --> 7499).
On Saturday, August 28, 2021, Andrea paz <[email protected]> wrote:
can you re-test 'last frame rendering' with longer (7500 frames) timeline? not urgent, when you will have time....
Always the same result, as in test.txt made 2 days ago:
encoded 7499 frames in 270.06s (27.77 fps), 1165.19 kb/s, Avg QP:32.60 Render::render_single: Session finished. ** rendered 7500 frames in 272.158 secs, 27.558 fps
Could it be that cnt1 starts from the first frame calling it 0 and cnt starts from the same first frame calling it 1? (I actually don't even understand why there are two counts! Maybe we can ask the freelancer, since he solved the: 7470 --> 7499).
well, I mean test with last flashy/bright frame... as long as all frames get rendered into file - this is just cosmetical bug.... but if they still not... ( ( ( also, does cin crash for you uf you try to blade cut/insert transition/set in piint in one place, then set out point somewere else and then edit >badd silence (so it will act on transition too)? if yes - does my patch from 'iris square' transition crash (termux/arm)' fix this crash?
Andrea,
I added the new plugins in expanders.txt; However, I think I broke the formatting of the file and it gives me a dump at startup. Going back to the previous expanders.txt gives no problems. I attach expanders-dump.txt and the dump.
The expanders.txt file relies on tabs in exact position. I fixed it and will check in probably later today. "Artistic" just needed a correctly sized tab space in front of it to be exactly lined up like "test" etc. Thanks for your contribution and I will look at plugin.opts now.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith