Recherche avancée

Sur d’autres sites (10505)

• Solving The XVD Puzzle

  15 avril 2012, par Multimedia Mike — General, multimedi archaeology, silicon valley, vg2, xvd, zygo

  I downloaded a multimedia file a long time ago (at least, I strongly suspected it was a multimedia file which is why I downloaded it). It went by the name of ‘lamborghini_850kbps.vg2′. I have had it in my collection for at least 7 years. I couldn’t remember where I found it. I downloaded it before it occurred to me to take notes about this sort of stuff.

  I found myself staring at the file again today and Googled the filename. This led me to a few Japanese sites which also contained working URLs for a few more .vg2 samples. Some other clues led me to a Russian language forum where someone had linked to a site that had Win32 codec modules that could process the files. The site was defunct but the Internet Archive Wayback Machine kept a copy for me, as well as copies of several more .vg2 samples from a defunct Japanese site previously involved with this codec.

  Sometimes this internet technology works really well. But I digress.

  Anyway, through all this, I finally found a clue : XVD. and wouldn’t you know, there is already a basic page on the MultimediaWiki describing the technology. In fact, while VG2 is a custom container, the MultimediaWiki states that the video component has a FourCC of VGMV, and there is already a file named VGMV.avi in the root V-codecs/ samples directory, something I vow to correct (that’s a big pet peeve of mine– putting samples in the root V-codecs/ or A-codecs/ directories).

  XVD… XVD… XVD… why does that sound so familiar ? Oh, of course ; there is a company named XVD and they have an office in the Bay Area which I have passed on numerous occasions, like this morning :

  
  <

  Someone originally connected with the multimedia technology in question operates a website which contains an unofficial history of the XVD tech. At first, I was wondering if the technology was completely defunct (and should therefore be open sourced). But if XVD’s solutions page (dated 2010) is to be believed, the technology is still in service, and purported to be better than H.264 and VC-1 : “The current generation of XVD video compression technology provides better video quality at any given data rate than standards-based codecs (H.264 or VC-1) with four times lower encoding complexity (when compared with H.264 Main Profile).”

  If they say so. For my part, I’m just happy that I have finally figured out what this lamborghini_850kbps.vg2 is so that I can properly catalog it on the samples site, which I have now done, along with other samples and various codecs modules.

  This episode reminds me that there’s a branch office of Zygo Corporation close to my home (though the headquarters are far, far away). The companies you see in Silicon Valley. Anyway, long-time open source multimedia hackers will no doubt recognize Zygo from the ZyGo FourCC & video codec transported in QuickTime files that was almost decode-able using an H.263 decoder.

  
  
  

  I may never learn what Zygo’s core competency actually is, but I will always remember their multimedia tech every time I run past their office.

• i want to control on bitrate for 720p

  10 décembre 2020, par shadymelad

  i want to control on bitrate for my files&#xA;i use this code

  &#xA;

  for %i in (Fargo.*.mkv) do echo %~ni.mkv && ffmpeg -i %~ni.mkv -i shady.png -filter_complex "[0:v][1:v]overlay=main_w-overlay_w-10:10,subtitles=%~ni.srt" -codec:a copy -s hd720 -b:v 800k -maxrate 800k -bufsize 800k -preset medium %~ni.new.mp4


  &#xA;

  by this code always the bitrate come to high like average 2000-2500 the finiel files come to high for watching online for ex 1 EP for series come like 1 Giga&#xA;i want to control it to get out average 1000-1200 to make the size come not to high for watching online

  &#xA;

  anyone can help me ?

  &#xA;

• 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