Recherche avancée

Sur d’autres sites (8159)

• doc/muxers/dash : review documentation

  18 janvier 2024, par Stefano Sabatini

  doc/muxers/dash : review documentation
  Sort options by name, review formatting, apply consistency fixes and
  
  fill the gaps (e.g. missing value for constants or flags), and review
  
  and extend content.
  

  • [DH] doc/muxers.texi

• Add aac single audio to MPEG DASH mpd files

  26 avril 2017, par Adminy

  I am trying to add manually to the .mpd file the following code.

      <adaptationset contenttype="audio" segmentalignment="true" bitstreamswitching="true" lang="English">
  
          <representation mimetype="audio/mp4" codecs="mp4a.40.2" audiosamplingrate="44100">
  
              <audiochannelconfiguration schemeiduri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"></audiochannelconfiguration>
  
              <segmenttemplate timescale="44100" media="http://localhost/audio.aac" startnumber="1">
  
              </segmenttemplate>
  
          </representation>
  
      </adaptationset>

  But its not working, Does everything have to be segmented in .mpd files ? or can I have a single .acc file ?

• Why is one ffmpeg webm dash stream much larger than the others ?

  5 janvier 2017, par ranvel

  Over the summer, I worked on putting together a script which took a x264 video/mp3 stream and broke it up into the different streams so that it would work via MSE-DASH. (Based heavily on the instructions on the webmproject.org website) Those same scripts have ceased to work, turning a 6GB video into several 25 Gb videos. I kept up with updates of ffmpeg and so I don’t know when it stopped working, but I am guessing it was due to the way that their DASH Webm implementation was updated.

  I found new method which works better, but still has a major problem with one stream. I was hoping someone could explain how this encoding works so that I could understand the underlying cause.

  #!/bin/bash
  
  COMMON_OPTS="-map 0:0 -an -threads 11 -cpu-used 4 -cmp chroma"
  
  WEBM_OPTS="-f webm -c:v vp9 -keyint_min 50 -g 50 -dash 1"
  
  
  
  ffmpeg -i $1 -vn -acodec libvorbis -ab 128k audio.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 500k -vf scale=1280:720 -y vid-500k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 700k -vf scale=1280:720 -y vid-700k.webm & 
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1000k -vf scale=1280:720 -y vid-1000k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1500k -vf scale=1280:720 -y vid-1500k.webm  

  The transcode is not yet complete, but you can see where this is headed :

  -rw-r--r--  1 user  staff    87M Jan  4 23:27 audio.webm
  
  -rw-r--r--  1 user  staff    27M Jan  4 23:42 vid-1000k.webm
  
  -rw-r--r--  1 user  staff   285M Jan  4 23:42 vid-1500k.webm
  
  -rw-r--r--  1 user  staff    15M Jan  4 23:42 vid-500k.webm
  
  -rw-r--r--  1 user  staff    20M Jan  4 23:42 vid-700k.webm

  The 1500k variant is disproportionately larger than the other streams.

  The other problem is that when I use a shorter video, lets say eight or nine minutes, the above configuration runs as expected and everything is perfect. I don’t know where the limit for this is since each test costs a lot of processing power and time, but if it’s less than ten minutes, it works and if its longer than an hour, it produces massive files.