Recherche avancée

Sur d’autres sites (10592)

• fftools/ffmpeg_filter : Fix check for mjpeg encoder

  13 avril 2021, par Andreas Rheinhardt

  fftools/ffmpeg_filter : Fix check for mjpeg encoder
  The MJPEG encoder supports some pixel format/color range combinations
  
  only when strictness is set to unofficial or less. Before commit
  
  059fc2d9da5364627613fb3e6424079e14dbdfd3 said encoder's pix_fmts array
  
  only included the pixel formats supported with default strictness.
  
  When strictness was <= unofficial, fftools/ffmpeg_filter.c used
  
  an extended list of pixel formats instead of the encoder's including
  
  the pixel formats only supported when strictness <= unofficial.
  Said commit turned the logic around : The encoder's pix_fmts array now
  
  included all pixel formats and fftools/ffmpeg_filter.c instead used
  
  a small list of all pixel formats supported when strictness is >
  
  unofficial and the encoder's pixel formats instead. In particular,
  
  the codec's pix_fmt is not used when strictness is normal.
  This works for the mjpeg encoder ; yet it did not work for other
  
  (hardware-based) mjpeg encoders, because the check for whether one is
  
  using the MJPEG encoder is wrong : It just checks the codec id.
  
  So if one used strict unofficial with a hardware-accelerated MJPEG
  
  encoder before commit 059fc2d9da53, the unofficial (non-hardware)
  
  pixel formats of the MJPEG encoder would be used ; since said commit
  
  the codec's pixel formats are overridden at ordinary strictness
  
  by the ordinary MJPEG pixel formats. This leads to format conversion
  
  errors lateron which were reported in #9186.
  The solution to this is to check AVCodec.name instead of its id.
  Fixes ticket #9186.
  Tested-by : Eoff, Ullysses A <ullysses.a.eoff@intel.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] fftools/ffmpeg_filter.c

• Video encoder with low CPU usage on Atom 230

  8 février 2016, par Alexandr Zarubkin

  What are my options for screen capturing on Atom 230 CPU that will result in reasonably low CPU usage ?
  I’m using ffmpeg and would like to leave CPU power to other applications while recording a screencast without lags.
  Maybe there’s hardware support for certain codec ?

• Are there any technical reasons that MP4 is more popular than Webm ?

  1er juin 2019, par dprogramz

  Not looking for opinions. I’m searching for data.

  As it is now, I want to become a webM evangelist. However, I assume there are some actual technical reasons why mp4 is preferred over webm in the bigger picture. I want to know them so I can be accurate in my assessments.

  I’m working on developing a broadcast video messaging graphics engine (think chyron) and using the Chromium engine like OBS does for messaging. So far the results have been excellent.

  One of the best features I’ve found is using webm for video. I should note I am using small (640x480 max) videos as graphics that are on top off a larger full HD video.

  Not only does it seem to have a better compression:quality ratio than mp4 for my use case, the most important thing is that it has full alpha support, which allows for excellent layering of video objects on top of each other in the HTML DOM, in real time, with no noticable performance hits.

  Aside from it’s predecessor, FLV, I can’t think of another high quality, high compression codec that also supports alpha. I feel like you are stuck using pro-res 4444 or the ancient animation codec to reliable distribute video with an alpha.

  So, that said, are there technical reasons why webM isn’t more adopted than mp4 ?

  I already know the obvious, that there is dedicated hardware to decode mp4. But, is there any technicality that would prevent a hardware webM decoder ? I really want to understand more what the benefits of mp4 are over webM, which i assume is why it is more widely used than webM.

  Thanks !