November 2019 - Cin - Cinelerra-GG Mailing Lists

Re: [Cin] cinelerra-gg on ppc64el
by Daniel Reurich 03 Apr '22

03 Apr '22

Hi I've made some significant progress in getting the build going - and will have some patches to drop that solve some issues for builds using system libs and non x86 based archs. The current issue I'm stumbling on is that configure doesn't detect the systems liba52 and a52dec/a52.h header files as installed. This results in a linking failure during the build of libzmpeg Any thoughts on how I might overcome that? Thanks, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722

3 5

Blu-ray encoding again
by Andrew Randrianasulu 16 Oct '20

16 Oct '20

Hi! With Marton's patches from git clone -b mpegts https://github.com/cus/ffmpeg/ and CinGG compiled with ffmpg.git I _nearly_ got some rendering. But option files still needed some modification For example I was running into x264 errors. cin Cinelerra Infinity - built: Nov 14 2019 14:17:05 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams (c) 2007-2019 cin5 derivative 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. Device type none is not supported. Available device types: vdpau cuda vaapi opencl Device type none is not supported. Available device types: vdpau cuda vaapi opencl Device type none is not supported. Available device types: vdpau cuda vaapi opencl Device type none is not supported. Available device types: vdpau cuda vaapi opencl [libx264 @ 0xe9a3c4c0] interlace + weightp is not implemented [libx264 @ 0xe9a3c4c0] using mv_range_thread = 88 [libx264 @ 0xe9a3c4c0] NAL HRD parameters require VBV parameters [libx264 @ 0xe9a3c4c0] using SAR=1/1 [libx264 @ 0xe9a3c4c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA3 BMI1 [libx264 @ 0xe9a3c4c0] profile High, level 4.1 Device type none is not supported. Available device types: vdpau cuda vaapi opencl FFMPEG::encode_activate: write header failed /dev/shm//bd_20191114-163217/bd.m2ts err: Недопустимый аргумент Render::render_single: Session finished. Device type none is not supported. Available device types: vdpau cuda vaapi opencl some of them were fixed by applying parameters from http://www.x264bluray.com/home/1080i-p [libx264 @ 0xe0609640] using mv_range_thread = 88 [libx264 @ 0xe0609640] using SAR=1/1 [libx264 @ 0xe0609640] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA3 BMI1 [libx264 @ 0xe0609640] HRD bitrate: 40000000 bits/sec [libx264 @ 0xe0609640] CPB size: 30000000 bits [libx264 @ 0xe0609640] profile High, level 4.1 [SWR @ 0xcfba81c0] Using fltp internally between filters Device type none is not supported. Available device types: vdpau cuda vaapi opencl Render::render_single: Session finished. but there still warning at ffmpeg site about deprecation of x264opts: https://trac.ffmpeg.org/wiki/Encode/H.264 Warning: Do not use the option x264opts, as it will eventually be removed. Use x264-params instead. --- /usr/share/cin/ffmpeg/video/bluray.m2ts 417/417 100% bluray libx264 bluray-compat=1 id=0x1011 level=41 bf=2 fake-interlaced=1 bitrate=40000 slices=4 sar=1:1 # vbv-maxrate=40000 # vbv-bufsize=30000 refs=3 cin_pix_fmt=yuv420p color_range=mpeg colorspace=bt709 color_trc=bt709 color_primaries=bt709 profile=high preset=medium flags=+cgop # must be last for bdcreate.C x264opts keyint=25:min-keyint=4:qpmin=3:qpmax=33:qp_step=4:merange=8:vbv-maxrate=40000:vbv-bufsize=30000 --- /usr/share/cin/ffmpeg/format/bluray 129/129 100% mpegts mpegts_m2ts_mode=1 mpegts_start_pid=1024 mpegts_pmt_start_pid=256 muxrate 1 #sdt_period=-1 packetsize 2048 preload 500000 But please note some x264 params actually should vary for interlaced or progressive, 25 vs 30 fps: 1080p Primary and Secondary Streams 1080p23.976 / 1080p24 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --open-gop --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file NB: the following two streams are encoded using fake-interlaced mode. This allows the stream to be encoded progressively yet flagged as interlaced. 1080p25 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file 1080p29.97 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --open-gop --slices 4 --fake-interlaced --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file 1080i Primary and Secondary Streams (assumes top field first) 1080i25 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --tff --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --tff --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file 1080i29.97 / 1080i30 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --open-gop --slices 4 --tff --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 30 --open-gop --slices 4 --tff --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 2 -o out.264 input.file so, keyint must be dynamically-selected, depending on profile you (user) choose, and fake_interlaced must be present for progressive encodings More on those constrains, refering same page: https://av.community/guides/encoding-video-for-blu-ray-using-h264-avc/ "8-bit (4:2:0) Colorspace is only allowed Main and High profiles are allowed Maximum 3 B-Frames is allowed NAL-HRD Type 2 capable encoder is needed" note, according to some comments around vbv-bufsize you can mux to DVD, so test this, too? "vbv-maxrate Maximum allowed bitrate. Depend of destination media, for normal BD Media, maximum settings is allowed (40000), while for DVD Media (eg BD-5 or BD-9) there is no maximum per Blu-Ray specification, but is strongly recommended that use less or equal to 15000, since DVD reading is slower."

3 3

Nested clip and proxy
by Igor BEGHETTO 26 Jan '20

26 Jan '20

I was reading the manual "CinelerraGG_manual.pdf" (created March 31 2019) and the manual "CinelerraGG_manual_WIP.pdf" (dated 20190826) by LaTex about Nested Clips. (really good job, guys. And I could print it on the paper in a A5 size) I noticed... - "CinelerraGG_manual.pdf", pg.116, Nested Clips - "CinelerraGG_manual_WIP.pdf", pg.122, Nested Clips The final sentence: "...compositions. They can not be proxied" By my tests/works, you CAN create proxies for Nested clips. Proxies are created in Cinelerra folder (where there is "cin" file) instead of the clip folder as usual (with Cin TAR version. With Package version I don't know). Before saving your project, pay attention to disable Proxy feature. You MUST SAVE your PROJECT with PROXY DISABLED otherwise you lose the link to the clips (more or less). Is it right that proxies are created in Cinelerra folder? Is there any reasons they are not created in the clip folder? Thanks. IgorBeg

3 19

Latex and Manual
by Andrea paz 13 Jan '20

13 Jan '20

@Olaf. Every month I write an email containing LaTeX and Manual in the title to continue the discussion and translation work with einhander. I installed the whole package, plus the Greek and Russian languages. Of course I also installed an editor, that is TexStudio. It would be nice if you could also contribute (in any way). "I also noticed that the lines in the TeX documents are all written without wrapping. When using Git and Diff, however, hard line breaks could be useful, short lines limited to less than 80 characters simplify the clarity." My knowledge of \LaTeX is very superficial and therefore I have not understood what you mean by wrapping the text. It would be nice if you could also contribute (in any way).

7 52

Cinelerra 7.2 (Cinelerra-HV)
by Sam 19 Dec '19

19 Dec '19

Hi guys, Adam Williams has released his annual update again, to the new Cinelerra version 7.2, I wrote a news article. Which can be found on our news website. https://www.cinelerra-gg.org/news-updates/cinelerra-7-2-release/ Sam --

4 5

New builds ready on the cinelerra-gg.org website
by Phyllis Smith 01 Dec '19

01 Dec '19

New builds are available. What is new is described in the release notes below. Sergio is this month's Hero having translated the website and updated the po files in Spanish. ------------------------------------------------------------------------------------------------------------------------------------------- Cinelerra-GG (Version Infinity) *Release Note*s for 11/01/2019-11/30/2019 for builds *Website*: Sergio has provided Spanish translations for the website. This is very much appreciated. 1. *Updated all Operating Systems on the local build machines* to be at the latest patch set. Debian 8 and Fedora 28 have been retired due to end of life and Fedora 31 has been added. In addition Centos 8 which was just released in October has a 1 time build available, but unless a Xen implementation becomes available, may not be regularly built. 2. *Reworked Audio* in the area of import samples, resampling, and playback speed sampling. This was a week’s worth of effort as many problems were found in the existing audio playback especially when playing backwards, when using the speed auto, and when large buffers were used. This rework fixed a lot of small problems and improved the program code for correct audio playing but does not affect the rendered output. Unless you use a magnifying glass and have exceptional hearing, it is doubtful you will notice the difference, but please report any problems. 3. Some of the original author’s *7.2 modifications *have been looked into to include the following: Added into Cinelerra-GG, the 3 new plugins – chorus, flanger, tremolo. Reviewed Pulse Audio and after merging it in, ended up backing it out because Alsa is much better and actually includes Pulse Audio with added improvements to compensate for any deficiencies. Better synchronization between audio and Playback was already achieved via #2 above of “reworked audio”. 4. *Usability Improvements:* *Spanish translation of the po files* was completed by Sergio with quite a large number of new translations added. This was a lot of work that is a benefit to many. The *prores opts files *have been updated and include a proxy version for ease of use (Olaf work). *Reworked the canvas zoom*. In the compositor, you can now use the middle wheel for zooming and moving the video with ease. Now scroll bars are available whenever image is off the screen. *Transcode 1:1* is now available in the Settings pulldown which provides a method to convert to a different format but most importantly gives the user the capability to be able to seek within media that does not have good indexing (see BT 337 for a few more details). Added potentiometer for the “beep on done” in the proxy and render menu so you can adjust the volume right from 0 for no beep to 100% for full beep. Bluray option file improvements and additions plus a bdcreate patch (Andrew work/discoveries). 4. *Bugs/Issues Fixed*: Fixed long-standing bug from original software where a specific setup caused a SEGV (reported and chased down by Andrew). For details, refer to Mantis Bug Tracker #335. Incorrect pix_fmt statements in ffmpeg opts files corrected to pixel_format (Andrew noted). Fixes to Compositor Background Color include: play with OpenGL driver retains color; flash when restart play in a couple of places is now gone for smoother viewing; the boundary marker is now outside the media and does not overlay any portion of the media. Small build changes to accommodate Fedora version 31. Duplicate close bug in vdevicex11 has been corrected. LV2 enhanced gui’s were not viewable in last month’s builds due to missing init but now fixed. Fixed hardware device type “none” causing problem as found by Andrew. Tweak to “remove assets” was done. Voluminous “buffer underflow” when using the default mpeg.mpeg proxy setting has been fixed via a patch to the ffmpeg code (Olaf reported). Updated about 13 other ffmpeg option files to switch from x264opts to x264-params to avoid potential future deletion of x264opts. Programmed some index rebuild fixes. Fixed audio big buffers bug for libzmpeg3.

1 0

I put up my hacked CinelerraGG slackbuild on github
by Andrew Randrianasulu 26 Nov '19

26 Nov '19

Hi all! While not really interesting in general, I think having whole thing outside my computer still better than not having! https://github.com/Randrianasulu/CinelerraGG-slackbuild Guess only thing worth re-investingating is DRI3 + OpenGL video output, for me it was not working, but then I rarely retry DRI3 due to some CPU consumption bug somewhere after prolonged uptime ....

1 0

Po files for spanish translation
by Sergio Daniel Gomez 21 Nov '19

21 Nov '19

The po file offered to translate in "translate the app" page, is same as in github? If not, please send me one, Thanks in advance Sergio

6 20

Re: [Cin] Blu-ray encoding again
by Andrew Randrianasulu 19 Nov '19

19 Nov '19

В сообщении от Friday 15 November 2019 01:01:29 Marton Balint написал(а): > > On Thu, 14 Nov 2019, Andrew Randrianasulu wrote: > > >> "Warning: Do not use the option x264opts, as it will eventually be removed. > >> Use x264-params instead." > >> *ok. we will change that.* > >> > >> f*or bluray_format, mpegts_m2ts_mode=1 *(changed to 2 by me) causes the > >> transport stream to set > >> the transport_priority flag if the packet is audio ac3, which is sort of a > >> kludge... but this is > >> necessary to get audio to reproduce on my home bluray player (samsung > >> ubd-k8500). This was > >> discovered by checking the diff between the ffmpeg output (which fails on > >> player) and the "sintel" > >> iso file from blender site (which works on player). The mode=2 triggers > >> mode=1 and add the > >> transport_priority flag for ac3 audio. It definitely helps here at home. > >> Similarly, *sdt_period=-1* > >> turns off the service descriptor table output, since this is not a > >> broadcast stream. I am not an > >> expert on mpegts and these changes work for me. If you have better > >> information, let me know. > > > > I'm not expert too, but may be Marton can explain to us > > if those changes acceptable in upstream, or they > > must be done as separate parameters .. > > I think we should just change behaviour unconditionally if m2ts mode is > used, unless there is a known downside of doing so. I will extend my > branch with a patch which makes the muxer not use SDT in m2ts mode, I was > not aware that it is not needed in BluRay. There is alternative ts muxer recently open-sourced, you can look into its code: https://github.com/justdan96/tsMuxer NOT guaranteed to be correct, but some code better than no code (buildable for me on 32-bit Slackware) File I used for test was named 1080p25.ts and I found it ... http://www.w6rz.net/1080p25.zip here I can try and locate some ps4 user, in theory this system should be able to play Blu-Rays: https://manuals.playstation.net/document/en/ps4/videos/videodisc.html > > Regards, > Marton >

2 4

Pulldown support in libx264?
by Andrew Randrianasulu 17 Nov '19

17 Nov '19

Hello, all! I was trying to see if x264's cli option "piulldown" can be ported to libx264/ffmpeg. Not as simple as copy/pasta, it seems :O in x264.c (from x264 source tree) I see this: /* set up pulldown */ if( opt->i_pulldown && !param->b_vfr_input ) { param->b_pulldown = 1; param->b_pic_struct = 1; pulldown = &pulldown_values[opt->i_pulldown]; param->i_timebase_num = param->i_fps_den; FAIL_IF_ERROR2( fmod( param->i_fps_num * pulldown->fps_factor, 1 ), "unsupported framerate for chosen pulldown\n" ); param->i_timebase_den = param->i_fps_num * pulldown->fps_factor; } and then: /* Encode frames */ for( ; !b_ctrl_c && (i_frame < param->i_frame_total || !param->i_frame_total); i_frame++ ) { if( filter.get_frame( opt->hin, &cli_pic, i_frame + opt->i_seek ) ) break; x264_picture_init( &pic ); convert_cli_to_lib_pic( &pic, &cli_pic ); if( !param->b_vfr_input ) pic.i_pts = i_frame; if( opt->i_pulldown && !param->b_vfr_input ) { pic.i_pic_struct = pulldown->pattern[ i_frame % pulldown->mod ]; pic.i_pts = (int64_t)( pulldown_pts + 0.5 ); pulldown_pts += pulldown_frame_duration[pic.i_pic_struct]; I tried to insert similar logic into libx264, but failed %) in x264.h i see typedef struct x264_picture_t { /* In: force picture type (if not auto) * If x264 encoding parameters are violated in the forcing of picture types, * x264 will correct the input picture type and log a warning. * Out: type of the picture encoded */ int i_type; /* In: force quantizer for != X264_QP_AUTO */ int i_qpplus1; /* In: pic_struct, for pulldown/doubling/etc...used only if b_pic_struct=1. * use pic_struct_e for pic_struct inputs * Out: pic_struct element associated with frame */ int i_pic_struct; and enum declared just above this as enum pic_struct_e { PIC_STRUCT_AUTO = 0, // automatically decide (default) PIC_STRUCT_PROGRESSIVE = 1, // progressive frame // "TOP" and "BOTTOM" are not supported in x264 (PAFF only) PIC_STRUCT_TOP_BOTTOM = 4, // top field followed by bottom PIC_STRUCT_BOTTOM_TOP = 5, // bottom field followed by top PIC_STRUCT_TOP_BOTTOM_TOP = 6, // top field, bottom field, top field repeated PIC_STRUCT_BOTTOM_TOP_BOTTOM = 7, // bottom field, top field, bottom field repeated PIC_STRUCT_DOUBLE = 8, // double frame PIC_STRUCT_TRIPLE = 9, // triple frame }; so, it basically number ? Just this number should be put in encoded frames, so they can be repeated at decoding according to pattern? Now, does libx264 allow such manipulation, I mean it eats frames, and feed them to x264 library fuctions, so just re-doing this dance with pts and timebase and pic_struct should be enough for making pulldown-converted video? It seems blu-ray at specific resolutions/framerates demand this type of encoding, see for example http://www.x264bluray.com/home/720p-encoding "NB: the next two streams use frame doubling to comply with the Blu-Ray specification: 720p25 x264 --bitrate XXXXX --preset veryslow --tune film --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --open-gop --slices 4 --pulldown double --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --pass 1 -o out.264 input.file" But because pulldown option only supported via x264 cli, it makes creating such streams harder, at least for CinelerraGG Also, what kind of program can check if this pulldown process actually was applied to encoded stream? medianfo? Copy/pasta 'patch' attached ... (it isn't working, not even compiling, just for showing areas I hack on.. I hope at least i bark at correct tree?)

1 0