It seems to work, at least I observed up to 300+% cpu load on encoding I made simple openjpeg.mov to put in /usr/share/cin/ffmpeg/video I can encode into rgba64 lossless, but it takes like 5 minutes for 47 seconds long 700x400 file (but with background render set to EXR/DWAA, and project set to RGBA-float, and vf_pseudocolor and some fader ...) playing this file with mplayer in realtime apparently impossible on my machine :} mplayer -vo x11 /dev/shm/OPENJPEG.mov MPlayer SVN-r38247-10.0.1 (C) 2000-2021 MPlayer Team parse error at line 423 do_connect: could not connect to socket connect: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /dev/shm/OPENJPEG.mov. libavformat version 58.65.101 (internal) libavformat file format detected. [mov,mp4,m4a,3gp,3g2,mj2 @ 0x574c054c]Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol [lavf] stream 0: video (jpeg2000), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang rus VIDEO: [mjp2] 704x400 24bpp 25.000 fps 143587.3 kbps (17527.7 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 58.119.100 (internal) [libopenjpeg @ 0x57601cf4]Requested frame threading with a custom get_buffer2() implementation which is not marked as thread safe. This is not supported anymore, make your callback thread-safe. Selected video codec: [fflibopenjpeg] vfm: ffmpeg (OpenJPEG MJPEG2000) ========================================================================== Clip info: major_brand: qt minor_version: 512 compatible_brands: qt encoder: Lavf58.65.101 Load subtitles in /dev/shm/ ========================================================================== Forced audio codec: mad Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders [aac @ 0x57601cf4]Multiple frames in a packet. AUDIO: 48000 Hz, 2 ch, floatle, 118.0 kbit/3.84% (ratio: 14754->384000) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) ========================================================================== AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... [aac @ 0x57601cf4]channel element 0.0 is not allocated Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] Movie-Aspect is 1.76:1 - prescaling to correct movie aspect. [swscaler @ 0x5773aa54]bicubic scaler, from rgba64le to bgra using MMXEXT VO: [x11] 704x400 => 704x400 BGRA [VD_FFMPEG] DRI failure. Movie-Aspect is 1.76:1 - prescaling to correct movie aspect. VO: [x11] 704x400 => 704x400 BGRA A: 0.0 V: 0.0 A-V: 0.000 ct: 0.000 0/ 0 ??% ??% ??,?% 0 0 [VD_FFMPEG] DRI failure. A: 8.7 V: 6.6 A-V: 2.013 ct: -0.019 0/ 0 46% 38% 4.9% 50 0 ************************************************ **** Your system is too SLOW to play this! **** ************************************************ Possible reasons, problems, workarounds: - Most common: broken/buggy _audio_ driver - Try -ao sdl or use the OSS emulation of ALSA. - Experiment with different values for -autosync, 30 is a good start. - Slow video output - Try a different -vo driver (-vo help for a list) or try -framedrop! - Slow CPU - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts, e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all. - Broken file - Try various combinations of -nobps -ni -forceidx -mc 0. - Slow media (NFS/SMB mounts, DVD, VCD etc) - Try -cache 8192. - Are you using -cache to play a non-interleaved AVI file? - Try -nocache. Read DOCS/HTML/en/video.html for tuning/speedup tips. If none of this helps you, read DOCS/HTML/en/bugreports.html. A: 9.1 V: 6.8 A-V: 2.269 ct: -0.019 0/ 0 51% 38% 5.1% 55 0 file is like 810 mb big :} Additional patches attached .... I can't say OpenEXR-2.5-opt.diff help much (this was optimization they talked about in OpenEXR 2.5.x) but apparently it still applicaple to 2.4.1, just rename it and put in thirdparty/src if you want to test FORMAT_brender_exr_added.diff is basically not very useful (apart from testing?) addition of OpenEXR as background render choice openjpeg-24.patch Basically you should put Openjpeg-2.4.0 tarball into thirdparty/src instead of 2.3.1 and apply this patch for testing ... internal ffmpeg should be build with this version of openjpeg
Andrew, I checked into GIT, your new openjpeg.qt just now and am looking at the updated jpeg library as you provided next. Thank you!
В сообщении от Thursday 04 February 2021 01:05:18 Phyllis Smith via Cin написал(а):
Andrew, I checked into GIT, your new openjpeg.qt just now and am looking at the updated jpeg library as you provided next. Thank you!
Well, this was simple .... But concern about new library suddently breaking on old-ish distros still stand .... :( So, if you have old-ish distro unpacked somewhere - try to test it there too? Or I can try to build it in VM
Andrew, Yes, I will test on an older distro too (if I can figure out how to boot into that!). So far I can not get it to build and get the following error BUT I have to figure it out myself so I learn how.
g++: error: /mnt0/build5/cinelerra-5.1/mplexlo/../thirdparty/openjpeg-2.4.0/bin/libopenjp2.a: No such file or directory
On Wed, Feb 3, 2021 at 4:11 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
В сообщении от Thursday 04 February 2021 01:05:18 Phyllis Smith via Cin написал(а):
Andrew, I checked into GIT, your new openjpeg.qt just now and am looking at the updated jpeg library as you provided next. Thank you!
Well, this was simple .... But concern about new library suddently breaking on old-ish distros still stand .... :(
So, if you have old-ish distro unpacked somewhere - try to test it there too?
Or I can try to build it in VM -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Thursday 04 February 2021 02:25:17 Phyllis Smith via Cin написал(а):
Andrew, Yes, I will test on an older distro too (if I can figure out how to boot into that!). So far I can not get it to build and get the following error BUT I have to figure it out myself so I learn how.
g++: error: /mnt0/build5/cinelerra-5.1/mplexlo/../thirdparty/openjpeg-2.4.0/bin/libopenjp2.a: No such file or directory
Do not forgot to re-run autgen.sh after patching? (while I think in this case it stopped at ffmpeg build for me, when I forgot this step) Also, apparently even libdav1d 0.5.1 unbuildable on Ubuntu 16.04.7 ? So far I added --disable-dav1d for my configure .... I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
On Wed, Feb 3, 2021 at 4:11 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
В сообщении от Thursday 04 February 2021 01:05:18 Phyllis Smith via Cin написал(а):
Andrew, I checked into GIT, your new openjpeg.qt just now and am looking at the updated jpeg library as you provided next. Thank you!
Well, this was simple .... But concern about new library suddently breaking on old-ish distros still stand .... :(
So, if you have old-ish distro unpacked somewhere - try to test it there too?
Or I can try to build it in VM -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, Do not forgot to re-run autgen.sh after patching? (while I think in this
case it stopped at ffmpeg build for me, when I forgot this step)
I did get openjpeg-2.4.0 built and the results look good, but I still want to test on an older distro yet tomorrow. Thanks for the hints.
Also, apparently even libdav1d 0.5.1 unbuildable on Ubuntu 16.04.7 ? So far I added --disable-dav1d for my configure ....
That is probably true because the NASM requirement is higher than what is on even currently still supportable distros. For example, 0.6 dav1d requires NASM 2.14 which is above that of older distros. This is best left for users to compile on their own if they really, really need to have it.
I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
I will test this after I have finished openjpeg and checked that in.
Checked in Andrew's patch and updated openjpeg-2.4.0 after testing on Ubuntu 16 -- just little tests but it does seem a little faster to render Jpeg Sequence (4.027 versus 4.169 on a small 1'30' video). Andrea/Walter -- if you have time could you GIT pull and rebuild and make a small test too? I did get openjpeg-2.4.0 built and the results look good, but I still want
to test on an older distro yet tomorrow. Thanks for the hints.
I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
Still time for me to test this toda!
В сообщении от Saturday 06 February 2021 00:05:20 Phyllis Smith via Cin написал(а):
Checked in Andrew's patch and updated openjpeg-2.4.0 after testing on Ubuntu 16 -- just little tests but it does seem a little faster to render Jpeg Sequence (4.027 versus 4.169 on a small 1'30' video).
It must be noted OpenJpeg is about jpeg2000 (j2k), not ususal jpeg... And even j2k sequence apparently handled by default by ffmpeg's internal encoder? so, why I did openjpeg.qt :}
Andrea/Walter -- if you have time could you GIT pull and rebuild and make a small test too?
I did get openjpeg-2.4.0 built and the results look good, but I still want
to test on an older distro yet tomorrow. Thanks for the hints.
I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
Still time for me to test this toda!
Andrew, Ooops, I better test again since I did the wrong test. Thanks. On Fri, Feb 5, 2021 at 3:59 PM Andrew Randrianasulu via Cin < [email protected]> wrote:
В сообщении от Saturday 06 February 2021 00:05:20 Phyllis Smith via Cin написал(а):
Checked in Andrew's patch and updated openjpeg-2.4.0 after testing on Ubuntu 16 -- just little tests but it does seem a little faster to render Jpeg Sequence (4.027 versus 4.169 on a small 1'30' video).
It must be noted OpenJpeg is about jpeg2000 (j2k), not ususal jpeg... And even j2k sequence apparently handled by default by ffmpeg's internal encoder?
so, why I did openjpeg.qt :}
Andrea/Walter -- if you have time could you GIT pull and rebuild and
make a
small test too?
I did get openjpeg-2.4.0 built and the results look good, but I still want
to test on an older distro yet tomorrow. Thanks for the hints.
I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
Still time for me to test this toda!
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
El viernes, 5 de febrero de 2021 18:05:20 -03 Phyllis Smith via Cin escribió:
Checked in Andrew's patch and updated openjpeg-2.4.0 after testing on Ubuntu 16 -- just little tests but it does seem a little faster to render Jpeg Sequence (4.027 versus 4.169 on a small 1'30' video).
Andrea/Walter -- if you have time could you GIT pull and rebuild and make a small test too?
I did get openjpeg-2.4.0 built and the results look good, but I still want
to test on an older distro yet tomorrow. Thanks for the hints.
I think I had patch for building new nasm as thirdparty (attached) do not forgot to add nasm's tar.gz into thirdparty/src if you want to test this too ....
Still time for me to test this toda!
In the very basic tests I did, some videos, audio and a couple of * .jp2 images, the project built fine. !! cinelerra commit d3595620 -- - | Walter Casanova | - - | Gnu / Linux - SysAdmin | -
All OK, for me. I just get this warning: FFMPEG::open_decoder: some stream have bad times: /home/paz/Download/relax.jp2 But it's the same with png and tiff ( as always) and everything works fine.
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith -
Walter Casanova