Recherche avancée

Sur d’autres sites (6056)

• ffmpeg video won't play in certain players

  25 janvier 2021, par Thomas Tiotto

  I'm generating a video in /folder/ from a stack of images in /folder/tmp/ using the following command :

  


   ffmpeg -pattern_type glob -i 'folder/tmp/*.png' -c:v libx264 -preset veryslow -crf 17 -tune stillimage -y -pix_fmt yuv420p folder/weight_evolution.mp4


  


  but my video won't play in, for example, QuickTime ("The file isn’t compatible with QuickTime Player.") and even sending it in Telegram gives really strange results. The video plays fine in IINA and VLC.

  


  As you can see, this is what is encoded by Telegram :

  


  

  


  and this is what the video should look like :

  


  

  


  The output of the command is :

  


  ffmpeg -pattern_type glob -i 'tmp/*.png' -c:v libx264 -preset veryslow -crf 17 -tune stillimage -y -pix_fmt yuv420p weight_evolution.mp4
    ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
      built with Apple clang version 12.0.0 (clang-1200.0.32.28)
      configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.1_7 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-videotoolbox --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack
      libavutil      56. 51.100 / 56. 51.100
      libavcodec     58. 91.100 / 58. 91.100
      libavformat    58. 45.100 / 58. 45.100
      libavdevice    58. 10.100 / 58. 10.100
      libavfilter     7. 85.100 /  7. 85.100
      libavresample   4.  0.  0 /  4.  0.  0
      libswscale      5.  7.100 /  5.  7.100
      libswresample   3.  7.100 /  3.  7.100
      libpostproc    55.  7.100 / 55.  7.100
    Input #0, image2, from 'tmp/*.png':
      Duration: 00:00:10.28, start: 0.000000, bitrate: N/A
        Stream #0:0: Video: png, rgba(pc), 1280x720 [SAR 3937:3937 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
    Stream mapping:
      Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
    Press [q] to stop, [?] for help
    [libx264 @ 0x7f804c009400] using SAR=1/1
    [libx264 @ 0x7f804c009400] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
    [libx264 @ 0x7f804c009400] profile High, level 5.0, 4:2:0, 8-bit
    [libx264 @ 0x7f804c009400] 264 - core 161 r3027 4121277 - H.264/MPEG-4 AVC codec - Copyleft 2003-2020 - http://www.videolan.org/x264.html - options: cabac=1 ref=16 deblock=1:-3:-3 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=2.00:0.70 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-4 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=8 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=60 rc=crf mbtree=1 crf=17.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.20
    Output #0, mp4, to 'weight_evolution.mp4':
      Metadata:
        encoder         : Lavf58.45.100
        Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 25 fps, 12800 tbn, 25 tbc
        Metadata:
          encoder         : Lavc58.91.100 libx264
        Side data:
          cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
    frame=   72 fps=0.0 q=0.0 size=       0kB time=00:00:00.00 bitrate=N/A speed=   frame=  126 fps=110 q=22.0 size=       0kB time=00:00:01.68 bitrate=   0.2kbits/frame=  185 fps=112 q=22.0 size=       0kB time=00:00:04.04 bitrate=   0.1kbits/frame=  245 fps=113 q=22.0 size=       0kB time=00:00:06.44 bitrate=   0.1kbits/frame=  257 fps= 97 q=-1.0 Lsize=     209kB time=00:00:10.16 bitrate= 168.7kbits/s speed=3.83x
    video:206kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.448294%
    [libx264 @ 0x7f804c009400] frame I:2     Avg QP: 4.16  size: 92234
    [libx264 @ 0x7f804c009400] frame P:36    Avg QP:24.07  size:   156
    [libx264 @ 0x7f804c009400] frame B:219   Avg QP:26.50  size:    93
    [libx264 @ 0x7f804c009400] consecutive B-frames:  0.8%  0.0%  0.0%  1.6%  9.7% 23.3% 10.9% 18.7% 35.0%
    [libx264 @ 0x7f804c009400] mb I  I16..4: 87.5%  4.4%  8.2%
    [libx264 @ 0x7f804c009400] mb P  I16..4:  0.0%  0.0%  0.0%  P16..4:  0.8%  0.0%  0.0%  0.0%  0.0%    skip:99.1%
    [libx264 @ 0x7f804c009400] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8:  0.3%  0.0%  0.0%  direct: 0.0%  skip:99.7%  L0:71.2% L1:28.4% BI: 0.4%
    [libx264 @ 0x7f804c009400] 8x8 transform intra:4.7% inter:22.5%
    [libx264 @ 0x7f804c009400] direct mvs  spatial:96.8% temporal:3.2%
    [libx264 @ 0x7f804c009400] coded y,uvDC,uvAC intra: 14.7% 14.6% 14.6% inter: 0.0% 0.0% 0.0%
    [libx264 @ 0x7f804c009400] i16 v,h,dc,p: 89%  2%  9%  0%
    [libx264 @ 0x7f804c009400] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 40% 31%  1%  1%  1%  1%  1%  2%
    [libx264 @ 0x7f804c009400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 41% 27% 22%  2%  2%  2%  1%  2%  2%
    [libx264 @ 0x7f804c009400] i8c dc,h,v,p: 91%  4%  3%  2%
    [libx264 @ 0x7f804c009400] Weighted P-Frames: Y:0.0% UV:0.0%
    [libx264 @ 0x7f804c009400] ref P L0: 89.1%  0.5%  4.8%  1.1%  1.5%  0.7%  0.2%  0.9%  0.2%  0.1%  0.1%  0.3%  0.1%  0.2%  0.1%  0.1%
    [libx264 @ 0x7f804c009400] ref B L0: 37.4% 17.9% 11.7%  7.0%  5.5%  5.5%  4.4%  2.0%  1.5%  1.6%  1.2%  1.9%  1.5%  0.7%  0.1%
    [libx264 @ 0x7f804c009400] ref B L1: 92.0%  8.0%
    [libx264 @ 0x7f804c009400] kb/s:163.83


  


• Optical Drive Value Proposition

  28 août 2010, par Multimedia Mike — General

  I have the absolute worst luck in the optical drive department. Ever since I started building my own computers in 1995 — close to the beginning of the CD-ROM epoch — I have burned through a staggering number of optical drives. Seriously, especially in the time period between about 1995-1998, I was going through a new drive every 4-6 months or so. This was also during that CD-ROM speed race where the the drive packages kept advertising loftier ‘X’ speed ratings. I didn’t play a lot of CD-ROM games during that timeframe, though I did listen to quite a few audio CDs through the computer.

  
  
  

  I use “optical drive” as a general term to describe CD-ROM drives, CD-R/RW drives, DVD-ROM drives, DVD-R/RW drives, and drives capable of doing any combination of reading and writing CDs and DVDs. In my observation, optical media seems to be falling out of favor somewhat, giving way to online digital distribution for things like games and software, as well as flash drives and external hard drives vs. recordable or rewritable media for backup and sneakernet duty. Somewhere along the line, I started to buy computers that didn’t even have optical drives. That’s why I have purchased at least 2 external USB drives (seen in the picture above). I don’t have much confidence that either works correctly. My main desktop until recently, a Mac Mini, has an internal optical drive that grew flaky and unreliable a few months after the unit was purchased.

  I just have really rotten luck with optical drives. The most reliable drive in my house is the one on the headless machine that, until recently, was the main workhorse on the FATE farm. The eject switch didn’t work correctly so I have to log in remotely, 'sudo eject', walk to the other room, pop in the disc, walk back to the other room, and work with the disc.

  Maybe optical media is on its way out, but I still have many hundreds of CD-ROMs. Perhaps I should move forward on this brainstorm to archive all of my optical discs on hard drives (and then think of some data mining experiments, just for the academic appeal), before it’s too late ; optical discs don’t last forever.

  So if I needed a good optical drive, what should I consider ? I’ve always been the type to go cheap, I admit. Many of my optical drives were on the lower end of the cost spectrum, which might have played some role in their rapid replacement. However, I’m not sold on the idea that I’m getting quality just because I’m paying a higher price. That LG unit at the top of the pile up there was relatively pricey and still didn’t fare well in the long (or even medium) term.

  Come to think of it, I used to have a ridiculous stockpile of castoff (but somehow still functional) optical drives. So many, in fact, that in 2004 I had a full size PC tower that I filled with 4 working drives, just because I could. Okay, I admit that there was a period where I had some reliable drives.

  That might be an idea, actually– throw together such a computer for heavy duty archival purposes. I visited Weird Stuff Warehouse today (needed some PC100 RAM for an old machine and they came through) and I think I could put together such a box rather cheaply.

  It’s a dirty job, but… well, you know the rest.

• How Much H.264 In Each Encoder ?

  8 septembre 2010, par Multimedia Mike — General

  Thanks to my recent experiments with code coverage tools, I have a powerful new — admittedly somewhat specious — method of comparing programs. For example, I am certain that I have read on more than one occasion that Apple’s H.264 encoder sucks compared to x264 due, at least in part, to the Apple encoder’s alleged inability to exercise all of H.264′s features. I wonder how to test that claim ?

  Experiment
  Use code coverage tools to determine which H.264 encoder uses the most features.

  Assumptions

  • Movie trailers hosted by Apple will all be encoded with the same settings using Apple’s encoder.
  • Similarly, Yahoo’s movie trailers will be encoded with consistent settings using an unknown encoder.
  • Encoding a video using FFmpeg’s libx264-slow setting will necessarily throw a bunch of H.264′s features into the mix (I really don’t think this assumption holds much water, but I also don’t know what “standard” x264 settings are).

  Methodology

  • Grab a random Apple-hosted 1080p movie trailer and random Yahoo-hosted 1080p movie trailer from Dave’s Trailer Page.
  • Use libx264/FFmpeg with the ‘slow’ preset to encode Big Buck Bunny 1080p from raw PNG files.
  • Build FFmpeg with code coverage enabled.
  • Decode each file to raw YUV, ignore audio decoding, generate code coverage statistics using gcovr, reset stats after each run by deleting *.gcda files.

  Results

  • x264 1080p video : 9968 / 134203 lines
  • Apple 1080p trailer : 9968 / 134203 lines
  • Yahoo 1080p trailer : 9914 / 134203 lines

  I also ran this old x264-encoded file (ImperishableNightStage6Low.mp4) through the same test. It demonstrated the most code coverage with 10671 / 134203 lines.

  Conclusions
  Conclusions ? Ha ! Go ahead and jump all over this test. I’m already fairly confident that it’s impossible (or maybe just very difficult) to build a single H.264-encoded video that exercises every feature that FFmpeg’s decoder supports. For example, is it possible for a file to use both CABAC and CAVLC entropy methods ? If it’s possible, does any current encoder do that ?