
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (73)
-
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir -
Soumettre améliorations et plugins supplémentaires
10 avril 2011Si vous avez développé une nouvelle extension permettant d’ajouter une ou plusieurs fonctionnalités utiles à MediaSPIP, faites le nous savoir et son intégration dans la distribution officielle sera envisagée.
Vous pouvez utiliser la liste de discussion de développement afin de le faire savoir ou demander de l’aide quant à la réalisation de ce plugin. MediaSPIP étant basé sur SPIP, il est également possible d’utiliser le liste de discussion SPIP-zone de SPIP pour (...)
Sur d’autres sites (8237)
-
ffmpeg's "clev" and "slev" switches
7 juin 2017, par Wally WaltersDo the "-clev" and "-slev" switches have any effect on non-surround audio (e.g., mono and stereo) or are they safely ignored in the absence of the center and surround channels ?
-
FFMPEG Mpeg-DASH what attributes options and flags do we need to make H264 playable .mpd universally playable
22 mars 2021, par JintorI want to encode from any source to a universally playable .mpd with h264 codec.


Here my command


/usr/bin/ffmpeg -re -i 1.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 -flags -global_header -streaming 1 
-use_template 1 -use_timeline 0 -seg_duration 2 -remove_at_exit 1 
-f dash index.mpd



but with dash.js the log says


dash.js videoCodec (video/mp4;codecs="avc1") is not supported.



**EXTRA NOTE : When using -c:v libx264 and output in HLS .m3u8 —> it's working in all browsers


HTML with dash.js


<code class="echappe-js"><script src="http://cdn.dashjs.org/latest/dash.all.min.js"></script>



<script>&#xA; (function(){&#xA; var url = "https://www.---domain--path-to.mpd";&#xA; var player = dashjs.MediaPlayer().create();&#xA; player.initialize(document.querySelector("#videoPlayer"), url, true);&#xA;player.updateSettings({&#xA; streaming: {&#xA; lowLatencyEnabled: true, &#xA; liveDelay: 4,&#xA; liveCatchup: {&#xA; minDrift: 0.02,&#xA; maxDrift: 0,&#xA; playbackRate: 0.5,&#xA; latencyThreshold: 60 &#xA; }&#xA; }&#xA; });&#xA; })(); &#xA; video = document.getElementById("videoPlayer");&#xA; video.addEventListener("loadedmetadata", function(){ video.muted = true; video.play(); }, false);&#xA; </script>



I do have "-c:v libx264" but why dash.js sees avc1... I know that h264 have avc1, but how to fix this. Is it fixing the ffmpeg command or changing the
player.initialize
in the javascript

-
Solving The XVD Puzzle
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.