Very slow opening of one specific mp4 file
Hello, all! My friend recorded video tutorial for me (in Win7), and I successfully watched it with mplayer. But attempt at editing this file with Cin-GG (from July 1 2019 + ffmpeg git) resulted in Cin process eating a lot of CPU and only showing and playing first minute or so. I wonder if this behavior artifact of my hacking, or 'normal' version of Cinelerra-GG also shows such behavior? File: https://yadi.sk/d/0OJUyJKWn2Bt3g (332447K - in other words more than 300Mb) sha256sum bandicam\ 2019-08-08\ 00-25-19-503.mp4 d898261e6db9764beadb43a4e4ba0edcc581b2c4598b46789e5597d8ece55312 bandicam 2019-08-08 00-25-19-503.mp4
I downloaded it, it is cute, but I think I see exactly what you see so I will have GoodGuy look at it this afternoon. On Thu, Aug 8, 2019 at 9:08 AM Andrew Randrianasulu <[email protected]> wrote:
Hello, all!
My friend recorded video tutorial for me (in Win7), and I successfully watched it with mplayer. But attempt at editing this file with Cin-GG (from July 1 2019 + ffmpeg git) resulted in Cin process eating a lot of CPU and only showing and playing first minute or so.
I wonder if this behavior artifact of my hacking, or 'normal' version of Cinelerra-GG also shows such behavior?
File: https://yadi.sk/d/0OJUyJKWn2Bt3g (332447K - in other words more than 300Mb)
sha256sum bandicam\ 2019-08-08\ 00-25-19-503.mp4 d898261e6db9764beadb43a4e4ba0edcc581b2c4598b46789e5597d8ece55312 bandicam 2019-08-08 00-25-19-503.mp4 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Thursday 08 August 2019 18:51:39 Phyllis Smith написал(а):
I downloaded it, it is cute, but I think I see exactly what you see so I will have GoodGuy look at it this afternoon.
Thanks! Just re-compiled Cin-GG latest, and apparently new filter from ffmpeg 4.2 (I compiled with ffmpeg.git again) was causing segfaults, so I commented it out in /usr/share/cin/ffmpeg/plugin.opts: #freezedetect Actually, I also commented out derain filter, because it need some other (neural net model?) file I don't have. ffmpeg 4.2 also was released: http://ffmpeg.org/ --------------copy----------- August 5th, 2019, FFmpeg 4.2 "Ada" FFmpeg 4.2 "Ada", a new major release, is now available! Some of the highlights: tpad filter AV1 decoding support through libdav1d dedot filter chromashift and rgbashift filters freezedetect filter truehd_core bitstream filter dhav demuxer PCM-DVD encoder GIF parser vividas demuxer hymt decoder anlmdn filter maskfun filter hcom demuxer and decoder ARBC decoder libaribb24 based ARIB STD-B24 caption support (profiles A and C) Support decoding of HEVC 4:4:4 content in nvdec and cuviddec removed libndi-newtek agm decoder KUX demuxer AV1 frame split bitstream filter lscr decoder lagfun filter asoftclip filter Support decoding of HEVC 4:4:4 content in vdpau colorhold filter xmedian filter asr filter showspatial multimedia filter VP4 video decoder IFV demuxer derain filter deesser filter mov muxer writes tracks with unspecified language instead of English by default added support for using clang to compile CUDA kernels We strongly recommend users, distributors, and system integrators to upgrade unless they use current git master. -----end copy---------
On Thu, Aug 8, 2019 at 9:08 AM Andrew Randrianasulu <[email protected]> wrote:
Hello, all!
My friend recorded video tutorial for me (in Win7), and I successfully watched it with mplayer. But attempt at editing this file with Cin-GG (from July 1 2019 + ffmpeg git) resulted in Cin process eating a lot of CPU and only showing and playing first minute or so.
I wonder if this behavior artifact of my hacking, or 'normal' version of Cinelerra-GG also shows such behavior?
File: https://yadi.sk/d/0OJUyJKWn2Bt3g (332447K - in other words more than 300Mb)
sha256sum bandicam\ 2019-08-08\ 00-25-19-503.mp4 d898261e6db9764beadb43a4e4ba0edcc581b2c4598b46789e5597d8ece55312 bandicam 2019-08-08 00-25-19-503.mp4 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, Just an update -- gg has been working on the bandicam...mp4 file problem but no solution yet. Maybe looks like a communication error with ffmpeg and cinelerra. I tested with older versions, the furthest back was April 12, 2017 to ensure it was not a new bug and it failed there also. It is a "seek" error and you can see that the ffmpeg "ffplay" program also hangs on this file when doing a seek -- just start ffplay, let it play a little, and then use the "right arrow" key to seek and it will hang. Just re-compiled Cin-GG latest, and apparently new filter from ffmpeg 4.2
(I compiled with ffmpeg.git again) was causing segfaults, so I commented it out in /usr/share/cin/ffmpeg/plugin.opts: #freezedetect
Actually, I also commented out derain filter, because it need some other (neural net model?) file I don't have.
ffmpeg 4.2 also was released: http://ffmpeg.org/
Thanks for the notify -- gg will update Cinelerra to start using 4.2 and update plugin.opts -- he did not think it would be available until November or he would not have bothered putting in 4.1.4 already. Yeah! -- "AV1 decoding support through libdav1d" -- he has been patiently waiting for this as the AOM version currently in as you let us know, is really bad. And one of the distros he does monthly builds on will not even build with it in.
В сообщении от Friday 09 August 2019 05:59:12 Phyllis Smith написал(а):
Andrew,
Just an update -- gg has been working on the bandicam...mp4 file problem but no solution yet. Maybe looks like a communication error with ffmpeg and cinelerra. I tested with older versions, the furthest back was April 12, 2017 to ensure it was not a new bug and it failed there also. It is a "seek" error and you can see that the ffmpeg "ffplay" program also hangs on this file when doing a seek -- just start ffplay, let it play a little, and then use the "right arrow" key to seek and it will hang.
As my friend told me - this video might be Variable Frame Rate - due to codec not keeping up with full 30 fps capture as various programs did their work. I re-encoded it with ffmpeg, and now it opens ok. ffmpeg -i bandicam\ 2019-08-08\ 00-25-19-503.mp4 -c:v libx264 -c:a copy T.mp4 ffmpeg version 2.8.15 Copyright (c) 2000-2018 the FFmpeg developers built with gcc 5.5.0 (GCC) configuration: --arch=i486 --target-os=linux --prefix=/usr --libdir=/usr/lib --mandir=/usr/man --docdir=/usr/doc/ffmpeg-2.8.15 --enable-gpl --enable-version3 --disable-static --enable-shared --enable-runtime-cpudetect --enable-ffmpeg --enable-ffplay --enable-ffprobe --enable-ffserver --enable-doc --enable-avdevice --enable-avcodec --enable-avformat --enable-avutil --enable-swresample --enable-swscale --enable-postproc --enable-avfilter --enable-avresample --enable-pthreads --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-ladspa --enable-libass --enable-libbluray --disable-libbs2b --disable-libcaca --disable-libcelt --enable-libcdio --disable-libdc1394 --disable-libflite --enable-libfreetype --enable-libfribidi --disable-libgme --enable-libgsm --enable-libiec61883 --disable-libilbc --disable-libkvazaar --disable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --disable-libpulse --disable-libquvi --enable-librtmp --enable-libschroedinger --enable-libsmbclient --enable-libsnappy --disable-libsoxr --enable-libspeex --disable-libssh --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-libzvbi --enable-lzma --enable-openal --enable-opengl --enable-sdl --enable-x11grab --enable-zlib --disable-debug libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bandicam 2019-08-08 00-25-19-503.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: mp41 creation_time : 2019-08-07 21:25:19 encoder : BandiMp4Muxer 1.0 encoder-eng : BandiMp4Muxer 1.0 Duration: 01:05:42.43, start: 0.000000, bitrate: 690 kb/s Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 1600x1200 [SAR 1:1 DAR 4:3], 682 kb/s, 23.74 fps, 30 tbr, 30k tbn, 60 tbc (default) Metadata: creation_time : 2019-08-07 21:25:19 handler_name : VideoHandler Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 2 kb/s (default) Metadata: creation_time : 2019-08-07 21:25:19 handler_name : SoundHandler File 'T.mp4' already exists. Overwrite ? [y/N] y [libx264 @ 0x86e5880] using SAR=1/1 [libx264 @ 0x86e5880] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1 [libx264 @ 0x86e5880] profile High, level 4.0 [libx264 @ 0x86e5880] 264 - core 148 - H.264/MPEG-4 AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 [mp4 @ 0x86e4ae0] Codec for stream 1 does not use global headers but container format requires global headers Output #0, mp4, to 'T.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: mp41 encoder : Lavf56.40.101 Stream #0:0(eng): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1600x1200 [SAR 1:1 DAR 4:3], q=-1--1, 30 fps, 15360 tbn, 30 tbc (default) Metadata: creation_time : 2019-08-07 21:25:19 handler_name : VideoHandler encoder : Lavc56.60.100 libx264 Stream #0:1(eng): Audio: aac ([64][0][0][0] / 0x0040), 44100 Hz, stereo, 2 kb/s (default) Metadata: creation_time : 2019-08-07 21:25:19 handler_name : SoundHandler Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:1 -> #0:1 (copy) Press [q] to stop, [?] for help frame=118273 fps= 62 q=-1.0 Lsize= 206097kB time=01:05:42.37 bitrate= 428.3kbits/s dup=24691 drop=0 video:200861kB audio:1060kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.068277% [libx264 @ 0x86e5880] frame I:487 Avg QP:16.47 size:148535 [libx264 @ 0x86e5880] frame P:30543 Avg QP:21.31 size: 3025 [libx264 @ 0x86e5880] frame B:87243 Avg QP:31.57 size: 470 [libx264 @ 0x86e5880] consecutive B-frames: 1.0% 1.3% 1.6% 96.0% [libx264 @ 0x86e5880] mb I I16..4: 36.4% 25.4% 38.2% [libx264 @ 0x86e5880] mb P I16..4: 0.6% 0.6% 0.5% P16..4: 1.2% 0.3% 0.2% 0.0% 0.0% skip:96.6% [libx264 @ 0x86e5880] mb B I16..4: 0.1% 0.1% 0.0% B16..8: 1.6% 0.1% 0.0% direct: 0.0% skip:97.9% L0:52.1% L1:46.6% BI: 1.3% [libx264 @ 0x86e5880] 8x8 transform intra:34.2% inter:32.9% [libx264 @ 0x86e5880] coded y,uvDC,uvAC intra: 24.0% 15.8% 10.9% inter: 0.2% 0.2% 0.1% [libx264 @ 0x86e5880] i16 v,h,dc,p: 40% 52% 4% 3% [libx264 @ 0x86e5880] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 38% 11% 49% 0% 0% 0% 0% 0% 0% [libx264 @ 0x86e5880] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 33% 17% 2% 3% 3% 3% 2% 3% [libx264 @ 0x86e5880] i8c dc,h,v,p: 74% 16% 9% 1% [libx264 @ 0x86e5880] Weighted P-Frames: Y:0.0% UV:0.0% [libx264 @ 0x86e5880] ref P L0: 72.7% 8.0% 12.6% 6.7% 0.0% [libx264 @ 0x86e5880] ref B L0: 71.9% 25.6% 2.5% [libx264 @ 0x86e5880] ref B L1: 94.2% 5.8% [libx264 @ 0x86e5880] kb/s:417.37 ------------------------ When I zoomed in timeline a lot (for more prescie cuts, while in fact I did none so far! Like, few seconds for full width of window) and tried to play file at 2x speed (fast forward) - timeline cursor was not always moving timeline as play progressed - but smaller timeline was moving along ok. Probably 'not enough CPU' problem .... Memory use was around 1.1-1.7Gb. I re-encoded file as 2x faster (1h5min -> 32 min), but then some parts of it started to fly past eyes a bit too fast, so I really need to think what parts need speed up.
Just re-compiled Cin-GG latest, and apparently new filter from ffmpeg 4.2
(I compiled with ffmpeg.git again) was causing segfaults, so I commented it out in /usr/share/cin/ffmpeg/plugin.opts: #freezedetect
Actually, I also commented out derain filter, because it need some other (neural net model?) file I don't have.
ffmpeg 4.2 also was released: http://ffmpeg.org/
Thanks for the notify -- gg will update Cinelerra to start using 4.2 and update plugin.opts -- he did not think it would be available until November or he would not have bothered putting in 4.1.4 already.
Yeah! -- "AV1 decoding support through libdav1d" -- he has been patiently waiting for this as the AOM version currently in as you let us know, is really bad. And one of the distros he does monthly builds on will not even build with it in.
Andrew, here is the result of analysis: But attempt at editing this file with Cin-GG (from July 1 2019 + ffmpeg
git) resulted in Cin process eating a lot of CPU and only showing and playing first minute or so.
Using the attached script, gg was able to verify that the bandicam...mp4 file has only a single keyframe and to quote from previous information -- "Generally it just does not have keyframes which are needed for seeking which is what is done when you move around the media and start playing in the middle". Except in this case it already hangs using 1 thread to build the index because of no keyframes.
Bottom line is that Cinelerra will never be able to handle this file. He is going to add a message to the code to at least notify the user so as to not hang leading to frustration.
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith