Recherche avancée

Sur d’autres sites (2730)

• FFMPEG ldash 1 low latency option but dash.js not low latency and buggy with lag and start always at 0 cannot control

  7 avril 2021, par Jintor

  I can't figure out how to fix this. playing a supposed low latency mpeg-dash manifest but it's with lots of lag, and play-stop-wait-play-stop-wait....

  


  I have latest ubuntu with latest ffmpeg

  


  here the command

  


  ffmpeg -re -i file.webm -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -ac 2 -strict -2 -crf 18 -profile:v baseline -maxrate 1000k -pix_fmt yuv420p -bufsize 969k -ldash 1 -streaming 1 -use_template 0 -use_timeline 1 -seg_duration 1 -remove_at_exit 0 -f dash index.mpd


  


  and player side

  


  <code class="echappe-js">&lt;script src='http://stackoverflow.com/templates/account_js/dashjs/dash.3.1.0.min.js'&gt;&lt;/script&gt;&#xA;    
  &#xA;    &lt;script&gt;&amp;#xA;    (function(){&amp;#xA;        var url = &quot;index.mpd&quot;;&amp;#xA;        var player = dashjs.MediaPlayer().create();&amp;#xA;        player.initialize(document.querySelector(&quot;#videoPlayer&quot;), url, true);&amp;#xA;        player.updateSettings({&amp;#xA;            streaming: {&amp;#xA;                 lowLatencyEnabled: true, &amp;#xA;                 liveDelay: 3,&amp;#xA;                 liveCatchup: {&amp;#xA;                    enabled: true,&amp;#xA;                    minDrift: 0.05,&amp;#xA;                    maxDrift: 0,&amp;#xA;                    playbackRate: 0.5,&amp;#xA;                    latencyThreshold: 30    &amp;#xA;                  }&amp;#xA;            }&amp;#xA;        });&amp;#xA;    })();     &amp;#xA;    video = document.getElementById(&quot;videoPlayer&quot;);&amp;#xA;    video.addEventListener(&quot;loadedmetadata&quot;, function(){ video.muted = true; video.play(); }, false);&amp;#xA;    &lt;/script&gt;&#xA;
  

  


  but it's NOT low latency, It forces to start at 0 and cannot control the video

  


  is there a better config setup and what need to be fixed : ffmpeg options or dash.js config

  


• Origin Crusader Media

  14 février 2012, par Multimedia Mike — Game Hacking

  A gleaming copy of the old Origin game Crusader : No Remorse showed up today :

  
  
  

  Immediately, I delved in expecting to find Xan-encoded AVI files that would play perfectly using FFmpeg/Libav. Instead, I found a directory labeled flics/ that indeed has a lot of AVI files, but not in Xan. The programs attempt to interpret them as raw RGB. The strangest thing is the first frame often looks correct, if upside down :

  
  
  

  The first file I peered inside had the video FourCC ‘RRV1′. Searching for this led me to this discussion forum where people have already been hacking on this very format (Origin games invariably get a heap of lasting love). The forum participants have observed that 3 codecs are in play in this flics/ directory, including ‘RRV1′, ‘RRV2′, and ‘JYV1′, which apparently correspond to the initials of certain developers. The reason that the programs identify the files as raw RGB is because the FourCCs don’t appear everywhere that they’re supposed to. Additionally, there are several trailers for other Origin/EA games stored in Cinepak format elsewhere on the disc.

  It seems that I’m the person who added this title to the Xan wiki page, obviously with no first-hand evidence to back it up. Meanwhile, the forum participants speculate that the files are descended from the old Autodesk FLIC format (which would explain why they live in a directory called flics/). Corroborating strings extracted from the CRUSADER.EXE file include “FlicWait”, “FlicPlayer”, “Flic %s not found.”, “flicpath”, and “FLICPLAY.C”.

  The disc also features a sound/ directory which contains AMF files. Suxen Drol already documented these on the wiki as Asylum Media Format files. The disc contains an ASYLUM.DLL file as well as a utility called MOD2AMF.EXE. The latter works beautifully on a random MOD file I had laying around. The AMF file is a bit larger.

  Samples for all 3 FourCCs can be found here, while the AMF files and associated utilities are here.

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