November 2019 - Cin - Cinelerra-GG Mailing Lists

UPD: Is audio opts file for m2ts usable?
by Andrew Randrianasulu 08 Nov '19

08 Nov '19

ah, it was just due to missing patch (one failing to apply to ffmpeg.git) please discard this false alarm message. ---------- Пересланное сообщение ---------- Тема: Is audio opts file for m2ts usable? Дата: Пятница 08 ноября 2019 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org> I tried to render blu--ray profile (ffmpeg-m2ts type) and while video worked - audio was giving me troubles .. I changed bluray ac3 at very beginning of /usr/share/cin/ffmpeg/audio/bluray.m2ts to mpegts ac3 , now sounds apparently works (no render error, mplayer show audio stream with 192 Kbit/s bitrate) but is this right fix, or bluray keyword used internally for cin for Blu-Ray profiles? If this is right fix - there are some video opts files where format defined as "bluray libx264" at the top of the file: bluray.m2ts bluray_dv_ntsc.m2ts bluray_dv_pal.m2ts bluray_lo.m2ts visually_lossless.m2ts I think I made those files work as render choice, but BD creation not tested yet .... may be bluray.m2ts from audio folder should be renamed bluray_ac3.m2ts ? -------------------------------------------------------

2 1

mpegtsenc changes in latest ffmpeg (since 4.2)
by Andrew Randrianasulu 08 Nov '19

08 Nov '19

https://git.ffmpeg.org/gitweb/ffmpeg.git/history/HEAD:/libavformat/mpegtsen… avformat/mpegtsenc: fix incorrect PCR selection with multiple programs avformat/mpegtsenc: factorize setting up services avformat/mpegtsenc: remove section_write_packet forward declaration avformat/mpegtsenc: use increasing numbers in default service names avformat/mpegtsenc: fix PCR generation intervals avformat/mpegtsenc: remove deprecated resend_headers option avformat/mpegtsenc: rename pcr_period variable to pcr_period_ms avformat/mpegtsenc: add support for setting PCR interval for VBR streams avformat/mpegtsenc: move some code around and simplify a bit avformat/mpegtsenc: get rid of packet counting for sdt/pat/pmt avformat/mpegtsenc: fix flushing of audio packets lavf/mpegtsenc: fix logic check error so, as far as I understand this area ..this mean mpegtsenc patch in CinGG can be simplified now ... but sadly not by me, I still very much idiot when it comes to those complex areas

1 0

Is audio opts file for m2ts usable?
by Andrew Randrianasulu 08 Nov '19

08 Nov '19

I tried to render blu--ray profile (ffmpeg-m2ts type) and while video worked - audio was giving me troubles .. I changed bluray ac3 at very beginning of /usr/share/cin/ffmpeg/audio/bluray.m2ts to mpegts ac3 , now sounds apparently works (no render error, mplayer show audio stream with 192 Kbit/s bitrate) but is this right fix, or bluray keyword used internally for cin for Blu-Ray profiles? If this is right fix - there are some video opts files where format defined as "bluray libx264" at the top of the file: bluray.m2ts bluray_dv_ntsc.m2ts bluray_dv_pal.m2ts bluray_lo.m2ts visually_lossless.m2ts I think I made those files work as render choice, but BD creation not tested yet .... may be bluray.m2ts from audio folder should be renamed bluray_ac3.m2ts ?

1 0

Quicktime and beginning of digital video editing era [article from 2013]
by Andrew Randrianasulu 04 Nov '19

04 Nov '19

Because I keep forgotting where _exactly_ I saw this article ..... http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/201… scroll down to Quicktime Does it All (but you can read whole thing if you like) --------- Quicktime was basically a complete library for creating video editing programs. It included standard code for selecting a video digitizer, copying and pasting movies, even setting a selection in a movie (effectively setting in and out points for an edit), and cutting or copying only that selection. It included built-in support for superimposing styled text on movies, and even for scrolling text to make titles and credits. All that made it much bigger than other Apple APIs at the time. In fact it was not one API, but rather a collection of them. -------- So, basically it explains existence of controls you can see for example in ffmpeg-4.2/libavformat/mov.c : static const AVOption mov_options[] = { {"use_absolute_path", "allow using absolute path when opening alias, this is a possible security issue", OFFSET(use_absolute_path), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS}, {"seek_streams_individually", "Seek each stream individually to the to the closest point", OFFSET(seek_individually), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS}, {"ignore_editlist", "Ignore the edit list atom.", OFFSET(ignore_editlist), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS}, {"advanced_editlist", "Modify the AVIndex according to the editlists. Use this option to decode in the order specified by the edits.", OFFSET(advanced_editlist), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS}, {"ignore_chapters", "", OFFSET(ignore_chapters), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS}, {"use_mfra_for", "use mfra for fragment timestamps", OFFSET(use_mfra_for), AV_OPT_TYPE_INT, {.i64 = FF_MOV_FLAG_MFRA_AUTO}, -1, FF_MOV_FLAG_MFRA_PTS, FLAGS, "use_mfra_for"}, {"auto", "auto", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_MFRA_AUTO}, 0, 0, FLAGS, "use_mfra_for" }, {"dts", "dts", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_MFRA_DTS}, 0, 0, FLAGS, "use_mfra_for" }, {"pts", "pts", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_MFRA_PTS}, 0, 0, FLAGS, "use_mfra_for" }, { "export_all", "Export unrecognized metadata entries", OFFSET(export_all), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS }, { "export_xmp", "Export full XMP metadata", OFFSET(export_xmp), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS }, { "activation_bytes", "Secret bytes for Audible AAX files", OFFSET(activation_bytes), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM }, { "audible_fixed_key", // extracted from libAAX_SDK.so and AAXSDKWin.dll files! "Fixed key used for handling Audible AAX files", OFFSET(audible_fixed_key), AV_OPT_TYPE_BINARY, {.str="77214d4b196a87cd520045fd20a51d67"}, .flags = AV_OPT_FLAG_DECODING_PARAM }, { "decryption_key", "The media decryption key (hex)", OFFSET(decryption_key), AV_OPT_TYPE_BINARY, .flags = AV_OPT_FLAG_DECODING_PARAM }, { "enable_drefs", "Enable external track support.", OFFSET(enable_drefs), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS }, { NULL }, }; Not sure if any of those more advanced options actually used now by CinGG, but they are there :} Another thing i found, about DV (a bit old, like from 2006 at best, still historical perspective I like to read (more than code!): https://www.adamwilt.com/DV-FAQ-tech.html by Adam J. Wilt. (analog TV was strange and complicated thing ...) Random site with historical video editing machines (incl. CMX): http://www.vtoldboys.com/editingmuseum/index.htm

2 1

Re: [Cin] [Libav-user] libavcodec usage inside Cinelerra-GG [LONG]
by Andrew Randrianasulu 04 Nov '19

04 Nov '19

В сообщении от Sunday 03 November 2019 13:56:09 Carl Eugen Hoyos написал(а): > Am So., 3. Nov. 2019 um 11:53 Uhr schrieb Andrew Randrianasulu > <randrianasulu(a)gmail.com>: > > > For what exactly I should look? > > You claim that AVStream->time_base is changing (which sounds strange to me > but who know) on seeking, you could look (with printf's) how ffmpeg.c > deals with this. > I cannot know... Update, just compiled CinelerraGG with ffmpeg.git LANG=ru_RU.utf8 /dev/shm/tmp/cinelerra-goodguy-20191104/cinelerra-5.1/bin/cin Cinelerra Infinity - built: Nov 4 2019 16:35:57 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. FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi Device type none is not supported. Available device types: vdpau cuda vaapi opencl FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi Device type none is not supported. Available device types: vdpau cuda vaapi opencl Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi Device type none is not supported. Available device types: vdpau cuda vaapi opencl Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,25 FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi FFMPEG::open_decoder: some stream times estimated: /home/guest/botva/Downloads/from_Vladimir/Leningrad dolphinarium 16 09 2009/LD_160909_2.avi Timebase from stream: 1,25 Timebase from stream: 1,25 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Timebase from stream: 1,30000 Session time: 0:00:19 Cpu time: user: 0:00:04.433 sys: 0:00:01.064 1,25 print was before I tried to seek in stream, but it jumped to 1,30000 after I tried to set playback cursor to some 3 min into video. Cinelerra git: commit 83cdf330ba14342487a08d72e25ef29736d41100 (grafted, HEAD -> master, origin/master, origin/HEAD) Author: Good Guy <good1.2guy(a)gmail.com> Date: Sat Nov 2 19:32:42 2019 -0600 correct last chkin dvd opts files ffmpeg.git: commit ec3d3fc65d06a9f7bc4d32b12b14a7c75e00484d (HEAD -> master, origin/master, origin/HEAD) Author: Jun Zhao <barryjzhao(a)tencent.com> Date: Sat Jun 15 16:21:56 2019 +0800 lavf/asfdec: Simplify the check conditions Simplify the check conditions Signed-off-by: Jun Zhao <barryjzhao(a)tencent.com> my diff for ffmpeg.c: diff --git a/cinelerra-5.1/cinelerra/ffmpeg.C b/cinelerra-5.1/cinelerra/ffmpeg.C index 70098ca..3cf85a9 100644 --- a/cinelerra-5.1/cinelerra/ffmpeg.C +++ b/cinelerra-5.1/cinelerra/ffmpeg.C @@ -681,7 +681,11 @@ int FFStream::seek(int64_t no, double rate) } if( pos == curr_pos ) return 0; double secs = pos < 0 ? 0. : pos / rate; - AVRational time_base = st->time_base; +// if user forced timebase to a specified stream + AVRational time_base = ffmpeg->force_timebase >= 0 ? + ffmpeg->fmt_ctx->streams[ffmpeg->force_timebase]->time_base : + st->time_base; + fprintf(stderr, "Timebase from stream: %i,%i \n", time_base.num, time_base.den); int64_t tstmp = time_base.num > 0 ? secs * time_base.den/time_base.num : 0; if( !tstmp ) { if( st->nb_index_entries > 0 ) tstmp = st->index_entries[0].timestamp; @@ -1192,10 +1196,19 @@ int FFVideoStream::video_seek(int64_t pos) if( pos == curr_pos-1 && !seeked ) return 0; // if close enough, just read up to current int gop = avctx->gop_size; - if( gop < 4 ) gop = 4; + if( gop < 4 && gop != 0) gop = 4; if( gop > 64 ) gop = 64; + if( gop == 0 ) gop = 1; + //fprintf(stderr, "GOP: %i \n", gop); int read_limit = curr_pos + 3*gop; if( pos >= curr_pos && pos <= read_limit ) return 0; + // fixup for I-only codecs, not sure why it needed with ffmpeg 4.2 + if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO || st->codecpar->codec_id == AV_CODEC_ID_MJPEG || + st->codecpar->codec_id == AV_CODEC_ID_FFVHUFF || st->codecpar->codec_id == AV_CODEC_ID_DNXHD || + st->codecpar->codec_id ==AV_CODEC_ID_HUFFYUV ) { + gop = 1; + if( seek(pos - 2*gop, frame_rate) < 0 ) return -1; + } // guarentee preload more than 2*gop frames if( seek(pos - 3*gop, frame_rate) < 0 ) return -1; return 1; @@ -1576,6 +1589,7 @@ FFMPEG::FFMPEG(FileBase *file_base) flow = 1; decoding = encoding = 0; has_audio = has_video = 0; + force_timebase = -1; opts = 0; opt_duration = -1; opt_video_filter = 0; @@ -2271,6 +2285,8 @@ int FFMPEG::init_decoder(const char *filename) if( (tag=av_dict_get(opts, "format", NULL, 0)) != 0 ) { ifmt = av_find_input_format(tag->value); } + if( (tag=av_dict_get(opts, "force_timebase", NULL, 0)) != 0 ) + force_timebase = atoi(tag->value); } else load_options("decode.opts", opts); actually patch was mostly developed by CinelerraGG developer, I only added fprintf(stderr, "Timebase from stream: %i,%i \n", time_base.num, time_base.den); (for testing I moved opts file I used to fix this stream away: mv /home/guest/botva/Downloads/from_Vladimir/Leningrad\ dolphinarium\ 16\ 09\ 2009/LD_160909_2.opts \ /home/guest/botva/Downloads/from_Vladimir/Leningrad\ dolphinarium\ 16\ 09\ 2009/LD_160909_2___.opts ) Is this enough for demonstrating problem ? > > Carl Eugen > _______________________________________________ > Libav-user mailing list > Libav-user(a)ffmpeg.org > https://ffmpeg.org/mailman/listinfo/libav-user > > To unsubscribe, visit link above, or email > libav-user-request(a)ffmpeg.org with subject "unsubscribe".

1 0

UPD: Current CinGG git fails to build with current ffmpeg.git, but may be this is not a problem yet
by Andrew Randrianasulu 04 Nov '19

04 Nov '19

moving patch to NO_patch with mv right before configure stage solved patching problem, so build continues .. # temporariry remove ffmpeg.git patch #2 mv thirdparty/src/ffmpeg.git.patch2 thirdparty/src/NO_patch from slackbuild I modified I wonder what exactly this patch was trying to workaround, some long-duration dvb->blu-ray transcoding? As far as I understand usual practice when upstreaming (or asking for comments on) patches is to make one thing per patch, even if it will made their number grow. I'm not a programmer, so I am puzzled even by beginning of patch: https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… - int pcr_pid; - int pcr_packet_count; - int pcr_packet_period; + int64_t pcr, pcr_packet_timer, pcr_packet_period; + int pcr_sid, pcr_pid; does this mean int was not big enough? and end a bit puzzling for me too, i see new options added but I can't reformulate why they were needed..? + { "mpegts_pcr_start_pid", "Set the first pid of the PCR.", and more + { "mpegts_pcr_offset", "clock offset.", real developers probably will understand what those must do, but I usually try to understand something so I can make some slightly more intelligent noise about it .... ---------- Пересланное сообщение ---------- Тема: Current CinGG git fails to build with current ffmpeg.git, but may be this is not a problem yet Дата: Понедельник 04 ноября 2019 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: cin(a)lists.cinelerra-gg.org I remember those git patches updated mostly ar ~rc/branching (for ffmpeg) time, I just tried my luck one more time and yeah ... nope: patch -d ffmpeg* -p1 < src/ffmpeg.git.patch1 patching file libavformat/bluray.c patch -d ffmpeg* -p1 < src/ffmpeg.git.patch2 patching file libavformat/mpegtsenc.c Hunk #1 FAILED at 56. Hunk #2 FAILED at 78. Hunk #3 FAILED at 95. Hunk #4 FAILED at 111. Hunk #5 succeeded at 217 with fuzz 2 (offset -5 lines). Hunk #6 succeeded at 763 with fuzz 2 (offset 33 lines). Hunk #7 FAILED at 745. Hunk #8 FAILED at 777. Hunk #9 succeeded at 853 (offset 68 lines). Hunk #10 succeeded at 879 with fuzz 1 (offset 39 lines). Hunk #11 FAILED at 927. Hunk #12 FAILED at 966. Hunk #13 FAILED at 1052. Hunk #14 succeeded at 1082 (offset -27 lines). Hunk #15 succeeded at 1100 (offset -27 lines). Hunk #16 FAILED at 1196. Hunk #17 FAILED at 1207. Hunk #18 succeeded at 1245 (offset 7 lines). Hunk #19 FAILED at 1253. Hunk #20 FAILED at 1261. Hunk #21 succeeded at 1372 (offset 3 lines). Hunk #22 FAILED at 1546. Hunk #23 FAILED at 1567. Hunk #24 FAILED at 1764. Hunk #25 succeeded at 1908 (offset -25 lines). Hunk #26 FAILED at 1982. 17 out of 26 hunks FAILED -- saving rejects to file libavformat/mpegtsenc.c.rej make[2]: *** [/dev/shm/tmp/cinelerra-goodguy-20191104/cinelerra-5.1/thirdparty/../thirdparty/build/ffmpeg.source] Ошибка 1 This is related to reporting possible incosistences in libavcodec/libavformat - because obviously libav devs prefer to look at current git ... Probably I should revisit this at ffmpeg 4.3's rc time. Just for your information. -------------------------------------------------------

1 0

Current CinGG git fails to build with current ffmpeg.git, but may be this is not a problem yet
by Andrew Randrianasulu 04 Nov '19

04 Nov '19

I remember those git patches updated mostly ar ~rc/branching (for ffmpeg) time, I just tried my luck one more time and yeah ... nope: patch -d ffmpeg* -p1 < src/ffmpeg.git.patch1 patching file libavformat/bluray.c patch -d ffmpeg* -p1 < src/ffmpeg.git.patch2 patching file libavformat/mpegtsenc.c Hunk #1 FAILED at 56. Hunk #2 FAILED at 78. Hunk #3 FAILED at 95. Hunk #4 FAILED at 111. Hunk #5 succeeded at 217 with fuzz 2 (offset -5 lines). Hunk #6 succeeded at 763 with fuzz 2 (offset 33 lines). Hunk #7 FAILED at 745. Hunk #8 FAILED at 777. Hunk #9 succeeded at 853 (offset 68 lines). Hunk #10 succeeded at 879 with fuzz 1 (offset 39 lines). Hunk #11 FAILED at 927. Hunk #12 FAILED at 966. Hunk #13 FAILED at 1052. Hunk #14 succeeded at 1082 (offset -27 lines). Hunk #15 succeeded at 1100 (offset -27 lines). Hunk #16 FAILED at 1196. Hunk #17 FAILED at 1207. Hunk #18 succeeded at 1245 (offset 7 lines). Hunk #19 FAILED at 1253. Hunk #20 FAILED at 1261. Hunk #21 succeeded at 1372 (offset 3 lines). Hunk #22 FAILED at 1546. Hunk #23 FAILED at 1567. Hunk #24 FAILED at 1764. Hunk #25 succeeded at 1908 (offset -25 lines). Hunk #26 FAILED at 1982. 17 out of 26 hunks FAILED -- saving rejects to file libavformat/mpegtsenc.c.rej make[2]: *** [/dev/shm/tmp/cinelerra-goodguy-20191104/cinelerra-5.1/thirdparty/../thirdparty/build/ffmpeg.source] Ошибка 1 This is related to reporting possible incosistences in libavcodec/libavformat - because obviously libav devs prefer to look at current git ... Probably I should revisit this at ffmpeg 4.3's rc time. Just for your information.

1 0

Spend whole day writing single-line Makefile
by Andrew Randrianasulu 03 Nov '19

03 Nov '19

... because I forgot about 'you must use tabs in makefiles' It still errors out, but at least build goes past ffmpeg's configure.. I'm trying to hack-in my latest discovery about multidepth x265. So, it really hack - thirdparty/Makefile patched for not creating configure in x265 dir, then Makefile, pseudo 'configure' with just one /bin/true line and multilib.sh script copied into just created folder, and after this CinGG's build system handles the rest ...hopefully (build not yet finished)

1 0

UPD: Re: Video background on CinGG website eats CPU ...
by Andrew Randrianasulu 03 Nov '19

03 Nov '19

Well, I hope Sam will find this info useful (myself is not a dev for adding this to webpage/locally): https://gist.github.com/cferdinandi/9044694 "simple method to stop YouTube, Vimeo, and HTML5 videos from playing." https://gomakethings.com/stopping-youtube-vimeo-and-html5-videos-with-javas… basically the same but without comments. sometimes comments useful ..... /** * Stop an iframe or HTML5 <video> from playing * @param {Element} element The element that contains the video */ var stopVideo = function ( element ) { var iframe = element.querySelector( 'iframe'); var video = element.querySelector( 'video' ); if ( iframe ) { var iframeSrc = iframe.src; iframe.src = iframeSrc; } if ( video ) { video.pause(); } }; -------------- and further in comments =========== Copy link Luminicus commented Sep 23, 2019 Good idea, but how can I call the function on click to pause all iframe > videos on the page (without ID of every iframe) ? @cferdinandi Copy link Owner Author cferdinandi commented Sep 24, 2019 @Luminicus This outta do it. /** * Stop all iframes or HTML5 <video>'s from playing */ var stopVideos = function () { var videos = document.querySelectorAll('iframe, video'); Array.prototype.forEach.call(videos, function (video) { if (video.tagName.toLowerCase() === 'video') { video.pause(); } else { var src = video.src; video.src = src; } }); }; ============ but may be you already figured this out. I usually check git, not website itself :} ---------- Пересланное сообщение ---------- Тема: Re: [Cin] Video background on CinGG website eats CPU ... Дата: Пятница 01 ноября 2019 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org> В сообщении от Friday 01 November 2019 13:29:04 Andrea paz написал(а): > Your information and tests are always interesting, thanks also for the > link. I also noticed a great CPU usage watching the video of the site. > In total, with "top", we are around 90%, of which 30-40% of GPUs that > do not know what it means (I have enabled hardware acceleration in > Firefox). yes, I also have layers.acceleration.force-enabled enabled in Seamonkey, but this only accelerates in-browser compositing, IIRC > But I have the same results watching the same video on Youtube: > https://www.youtube.com/watch?v=SzP2o2OJ90g > And the same results from watching any video on Youtube. > Does it turn out to you too? Yeah, 200%+ of CPU according to top :} Video in avc1 (h264), so may be Chrome (and/or Firefox on windows?) actually use hw acceleration for *decoding* it, so effect not very notieceable .... https://bugzilla.mozilla.org/show_bug.cgi?id=1210727 -------------------------------------------------------

2 2

Correction (for libavcodec usage inside Cinelerra-GG [LONG])
by Andrew Randrianasulu 03 Nov '19

03 Nov '19

I included link to our bugtracker issue #330, but it was not meant to say FFmpeg should be absolutely blamed on this - just that my primitive fprintf debugging showed something like jumping around at seek timestamps (due to cinelerra-GG using different seek method, relative to ffplay/mplayer) I just hope I not ruined our communication.

2 1