Recherche avancée

Sur d’autres sites (7783)

• 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 !

• Revision 1434f7695b : Skip ref frame mode search conditioned on predicted mv residuals This commit ma

  3 novembre 2014, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_pickmode.c

  
  
  Skip ref frame mode search conditioned on predicted mv residuals

  This commit makes the RTC coding mode to conditionally skip the
  reference frame mode search, when the predicted motion vector of
  the current reference frame gives more than two times sum of
  absolute difference compared to that of other reference frames.

  It reduces the runtim by 1% - 4% for speed -5 and -6. The average
  compression performance is improved by about 0.1% in both settings.

  It is of particular benefit to light change scenarios. The
  compression performance of test clip mmmovingvga.y4m is improved by
  6.39% and 15.69% at high bit rates for speed -5 and -6, respectively.

  Speed -5
  vidyo1 16555 b/f, 40.818 dB, 12422 ms ->
  16552 b/f, 40.804 dB, 12100 ms

  nik 33211 b/f, 39.138 dB, 11341 ms ->
  33228 b/f, 39.139 dB, 11023 ms

  mmmoving 33263 b/f, 40.935 dB, 13508 ms ->
  33256 b/f, 41.068 dB, 12861 ms

  Speed -6
  vidyo1 16541 b/f, 40.227 dB, 8437 ms ->
  16540 b/f, 40.220 dB, 8216 ms

  nik 33272 b/f, 38.399 dB, 7610 ms ->
  33267 b/f, 38.414 dB, 7490 ms

  mmmoving 33255 b/f, 40.555 dB, 7523 ms ->
  33257 b/f, 40.975 dB, 7493 ms

  Change-Id : Id2aef76ef74a3cba5e9a82a83b792144948c6a91

• Revision a4ce53f14d : Adaptive motion control on ref and search range This commit takes a preliminary

  21 décembre 2013, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Adaptive motion control on ref and search range

  This commit takes a preliminary attempt to refine the motion search
  control. It detects the SAD associated with mv predictor per reference
  frame, and based on which to determine whether the encoder wants to
  reduce the motion search range (if the predicted mv provides fairly
  small SAD), or to skip the current reference frame (if there exists
  another ref frame that gives much smaller SAD cost).

  This feature is turned on in the settings of speed 1 and above.

  In speed 1, compression performance changed
  derf -0.018%
  yt -0.043%
  hd -0.045%
  stdhd -0.281%

  speed-up
  pedestrian_area_1080p at 4000 kbps 100 frames
  199651ms -> 188846ms (5.5% speed-up)
  blue_sky_1080p at 6000 kbps
  443531ms -> 415239ms (6.3% speed-up)

  In speed 2, compression performance changed
  derf -0.026%
  yt -0.090%
  hd -0.055%
  stdhd -0.210%

  speed-up
  pedstrian 113949ms -> 108855ms (4.5% speed-up)
  blue_sky 271057ms -> 257322ms (5% speed-up)

  Change-Id : I1b74ea28278c94fea329d971d706d573983d810d