Recherche avancée
Médias (1)
-
La conservation du net art au musée. Les stratégies à l’œuvre
26 mai 2011
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (47)
-
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 -
Déploiements possibles
31 janvier 2010, parDeux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
Version mono serveur
La version mono serveur consiste à n’utiliser qu’une (...)
Sur d’autres sites (8226)
-
ffmpeg, dash manifest cannot be created due to unspecified pixel format
24 septembre 2015, par artworkad シI am using ffmpeg 2.8 on OSX.
I try to convert a short mp4 video to webm for adaptive streaming like suggested here http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-adaptive-webm-using-dash like this :
VP9_DASH_PARAMS="-tile-columns 6 -frame-parallel 1"
ffmpeg -i t2.mp4 -c:v libvpx-vp9 -s 160x90 -b:v 250k -keyint_min 150 -g 150 ${VP9_DASH_PARAMS} -an -f webm -dash 1 video_160x90_250k.webm
ffmpeg -i t2.mp4 -c:a libvorbis -b:a 128k -vn -f webm -dash 1 audio_128k.webm
ffmpeg \
-f webm_dash_manifest -i video_160x90_250k.webm \
-f webm_dash_manifest -i audio_128k.webm \
-c copy -map 0 -map 1 \
-f webm_dash_manifest \
-adaptation_sets "id=0,streams=0 id=1,streams=1" \
manifest.mpdHowever this gives me a warning unspecified pixel format :
[webm_dash_manifest @ 0x7f9414812800] Could not find codec parameters for stream 0 (Video: vp9, none, 160x90): unspecified pixel format
Consider increasing the value for the 'analyzeduration' and 'probesize' options
video_160x90_250k.webm: could not find codec parameters
Input #0, webm_dash_manifest, from 'video_160x90_250k.webm':
Metadata:
encoder : Lavf56.36.100
Duration: 00:00:09.97, bitrate: 111 kb/s
Stream #0:0: Video: vp9, none, 160x90, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
Metadata:
webm_dash_manifest_duration: 9969
webm_dash_manifest_initialization_range: 437
webm_dash_manifest_file_name: video_160x90_250k.webm
webm_dash_manifest_track_number: 1
webm_dash_manifest_cues_start: 139297
webm_dash_manifest_cues_end: 139399
webm_dash_manifest_bandwidth: 99164
webm_dash_manifest_cluster_keyframe: 1
webm_dash_manifest_cue_timestamps: 0,2085,4171,6256,8342
Input #1, webm_dash_manifest, from 'audio_128k.webm':
Metadata:
encoder : Lavf56.36.100
Duration: 00:00:10.01, bitrate: 120 kb/s
Stream #1:0: Audio: vorbis, 48000 Hz, stereo, fltp (default)
Metadata:
webm_dash_manifest_duration: 10009
webm_dash_manifest_initialization_range: 4697
webm_dash_manifest_file_name: audio_128k.webm
webm_dash_manifest_track_number: 1
webm_dash_manifest_cues_start: 151174
webm_dash_manifest_cues_end: 151240
webm_dash_manifest_bandwidth: 105517
webm_dash_manifest_cluster_keyframe: 1
webm_dash_manifest_cue_timestamps: 0,4999,9998
Output #0, webm_dash_manifest, to 'manifest.mpd':
Metadata:
encoder : Lavf56.36.100
Stream #0:0: Video: vp9, none, 160x90 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 23.98 tbr, 1k tbn, 1k tbc (default)
Metadata:
webm_dash_manifest_duration: 9969
webm_dash_manifest_initialization_range: 437
webm_dash_manifest_file_name: video_160x90_250k.webm
webm_dash_manifest_track_number: 1
webm_dash_manifest_cues_start: 139297
webm_dash_manifest_cues_end: 139399
webm_dash_manifest_bandwidth: 99164
webm_dash_manifest_cluster_keyframe: 1
webm_dash_manifest_cue_timestamps: 0,2085,4171,6256,8342
Stream #0:1: Video: vorbis, none, q=2-31, 1k tbn, 1k tbc (default)
Metadata:
webm_dash_manifest_duration: 10009
webm_dash_manifest_initialization_range: 4697
webm_dash_manifest_file_name: audio_128k.webm
webm_dash_manifest_track_number: 1
webm_dash_manifest_cues_start: 151174
webm_dash_manifest_cues_end: 151240
webm_dash_manifest_bandwidth: 105517
webm_dash_manifest_cluster_keyframe: 1
webm_dash_manifest_cue_timestamps: 0,4999,9998
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 0 fps=0.0 q=-1.0 Lsize= 1kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)Nevertheless the manifest file is created. I tried to specify the pixel format :
-pix_fmt yuv420pHowever this did not change anything. The warning remains the same.
Any ideas why the warning appears and how to fix this ?
-
Live streaming : node-media-server + Dash.js configured for real-time low latency
7 juillet 2021, par MaorationWe're working on an app that enables live monitoring of your back yard.
Each client has a camera connected to the internet, streaming to our public node.js server.



I'm trying to use node-media-server to publish an MPEG-DASH (or HLS) stream to be available for our app clients, on different networks, bandwidths and resolutions around the world.



Our goal is to get as close as possible to live "real-time" so you can monitor what happens in your backyard instantly.



The technical flow already accomplished is :



- 

-
ffmpeg process on our server processes the incoming camera stream (separate child process for each camera) and publishes the stream via RTSP on the local machine for node-media-server to use as an 'input' (we are also saving segmented files, generating thumbnails, etc.). the ffmpeg command responsible for that is :



-c:v libx264 -preset ultrafast -tune zerolatency -b:v 900k -f flv rtmp://127.0.0.1:1935/live/office -
node-media-server is running with what I found as the default configuration for 'live-streaming'



private NMS_CONFIG = {
server: {
 secret: 'thisisnotmyrealsecret',
},
rtmp_server: {
 rtmp: {
 port: 1935,
 chunk_size: 60000,
 gop_cache: false,
 ping: 60,
 ping_timeout: 30,
 },
 http: {
 port: 8888,
 mediaroot: './server/media',
 allow_origin: '*',
 },
 trans: {
 ffmpeg: '/usr/bin/ffmpeg',
 tasks: [
 {
 app: 'live',
 hls: true,
 hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]',
 dash: true,
 dashFlags: '[f=dash:window_size=3:extra_window_size=5]',
 },
 ],
 },
},



} ;
-
As I understand it, out of the box NMS (node-media-server) publishes the input stream it gets in multiple output formats : flv, mpeg-dash, hls.
with all sorts of online players for these formats I'm able to access and the stream using the url on localhost. with mpeg-dash and hls I'm getting anything between 10-15 seconds of delay, and more.











My goal now is to implement a local client-side mpeg-dash player, using dash.js and configure it to be as close as possible to live.



my code for that is :







 
 
 
 
 
 <div>
 <video autoplay="" controls=""></video>
 </div>
 <code class="echappe-js"><script src="https://cdnjs.cloudflare.com/ajax/libs/dashjs/3.0.2/dash.all.min.js"></script>

<script>&#xD;&#xA; (function(){&#xD;&#xA; // var url = "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd";&#xD;&#xA; var url = "http://localhost:8888/live/office/index.mpd";&#xD;&#xA; var player = dashjs.MediaPlayer().create();&#xD;&#xA; &#xD;&#xA; &#xD;&#xA;&#xD;&#xA; // config&#xD;&#xA; targetLatency = 2.0; // Lowering this value will lower latency but may decrease the player&#x27;s ability to build a stable buffer.&#xD;&#xA; minDrift = 0.05; // Minimum latency deviation allowed before activating catch-up mechanism.&#xD;&#xA; catchupPlaybackRate = 0.5; // Maximum catch-up rate, as a percentage, for low latency live streams.&#xD;&#xA; stableBuffer = 2; // The time that the internal buffer target will be set to post startup/seeks (NOT top quality).&#xD;&#xA; bufferAtTopQuality = 2; // The time that the internal buffer target will be set to once playing the top quality.&#xD;&#xA;&#xD;&#xA;&#xD;&#xA; player.updateSettings({&#xD;&#xA; &#x27;streaming&#x27;: {&#xD;&#xA; &#x27;liveDelay&#x27;: 2,&#xD;&#xA; &#x27;liveCatchUpMinDrift&#x27;: 0.05,&#xD;&#xA; &#x27;liveCatchUpPlaybackRate&#x27;: 0.5,&#xD;&#xA; &#x27;stableBufferTime&#x27;: 2,&#xD;&#xA; &#x27;bufferTimeAtTopQuality&#x27;: 2,&#xD;&#xA; &#x27;bufferTimeAtTopQualityLongForm&#x27;: 2,&#xD;&#xA; &#x27;bufferToKeep&#x27;: 2,&#xD;&#xA; &#x27;bufferAheadToKeep&#x27;: 2,&#xD;&#xA; &#x27;lowLatencyEnabled&#x27;: true,&#xD;&#xA; &#x27;fastSwitchEnabled&#x27;: true,&#xD;&#xA; &#x27;abr&#x27;: {&#xD;&#xA; &#x27;limitBitrateByPortal&#x27;: true&#xD;&#xA; },&#xD;&#xA; }&#xD;&#xA; });&#xD;&#xA;&#xD;&#xA; console.log(player.getSettings());&#xD;&#xA;&#xD;&#xA; setInterval(() => {&#xD;&#xA; console.log(&#x27;Live latency= &#x27;, player.getCurrentLiveLatency());&#xD;&#xA; console.log(&#x27;Buffer length= &#x27;, player.getBufferLength(&#x27;video&#x27;));&#xD;&#xA; }, 3000);&#xD;&#xA;&#xD;&#xA; player.initialize(document.querySelector("#videoPlayer"), url, true);&#xD;&#xA;&#xD;&#xA; })();&#xD;&#xA;&#xD;&#xA; </script>
 








with the online test video (https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd) I see that the live latency value is close to 2 secs (but I have no way to actually confirm it. it's a video file streamed. in my office I have a camera so I can actually compare latency between real-life and the stream I get).
however when working locally with my NMS, it seems this value does not want to go below 20-25 seconds.



Am I doing something wrong ? any configuration on the player (client-side html) I'm forgetting ?
or is there a missing configuration I should add on the server side (NMS) ?


-
-
mpeg dash on wowza server not working, status error 404 Not Found
10 septembre 2015, par jobinadaptives links for mpeg dash on wowza server not working with me, the following are the steps that I used to publish video on wowza :
- I install and configure Wowza server, and I tested it and it is working fine.
-
Transcode this video using ffmepg (I bring these command from wowza documentation)
-
I test the files and all of them workig fine then I moved these files to wowza content folder and create the smil file as following :
<?xml version="1.0" encoding="UTF-8"?>
<smil title="sintel">
<switch>
<video width="320" height="180" src="sintel_320p.mp4" systemlanguage="eng">
</video>
<video width="640" height="360" src="sintel_640p.mp4" systemlanguage="eng">
</video>
<video width="320" height="180" src="sintel_400p.mp4" systemlanguage="eng">
</video>
<video width="420" height="270" src="sintel_700p.mp4" systemlanguage="eng">
</video>
<video width="720" height="406" src="sintel_1100p.mp4" systemlanguage="eng">
</video>
<video width="1024" height="576" src="sintel_1300p.mp4" systemlanguage="eng">
</video>
<video width="1080" height="608" src="sintel_1500p.mp4" systemlanguage="eng">
</video>
</switch>
</smil>- I use the mpd file (http://191.237.26.137:1935/vod/smil:sintel.smil/manifest.mpd) with http://www.jwplayer.com/innovation/roadmap/mpeg-dash/
Result : the video work for first few seconds the stop
Syndiquer tout le site
