Recherche avancée

Sur d’autres sites (8963)

• APPLY Strong to Buffer rule. Quit Switching Bit rates MPEG DASH

  14 juillet 2015, par Vinay

  I am using mpeg dash for adaptive bit rate streaming of video from my server.

  I have used ffmpeg and MP4Box to generate 4 different quality video files from my source .mp4

  The .mpd file generated has the below code

  <?xml version="1.0"?>
  
  
  
  <mpd xmlns="urn:mpeg:dash:schema:mpd:2011" minbuffertime="PT1.500000S" type="static" mediapresentationduration="PT0H3M1.42S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011">
  
   <programinformation moreinformationurl="http://gpac.sourceforge.net">
  
    
  
   </programinformation>
  
  
  
   <period duration="PT0H3M1.42S">
  
    <adaptationset segmentalignment="true" maxwidth="1920" maxheight="1080" maxframerate="24" par="16:9" lang="und" subsegmentstartswithsap="1">
  
     <representation mimetype="video/mp4" codecs="avc1.64000d" width="320" height="240" framerate="24" sar="1:1" startwithsap="1" bandwidth="375715">
  
      <baseurl>400_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="904-1403">
  
        <initialization range="0-903"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.640015" width="420" height="270" framerate="24" sar="1:1" startwithsap="1" bandwidth="644824">
  
      <baseurl>700_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.64001f" width="1024" height="576" framerate="24" sar="1:1" startwithsap="1" bandwidth="1349484">
  
      <baseurl>1500_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.64001f" width="1280" height="720" framerate="24" sar="1:1" startwithsap="1" bandwidth="2264379">
  
      <baseurl>2500_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="905-1404">
  
        <initialization range="0-904"></initialization>
  
      </segmentbase>
  
     </representation>
  
     <representation mimetype="video/mp4" codecs="avc1.640028" width="1920" height="1080" framerate="24" sar="1:1" startwithsap="1" bandwidth="3633049">
  
      <baseurl>4000_dashinit.mp4</baseurl>
  
      <segmentbase indexrangeexact="true" indexrange="906-1405">
  
        <initialization range="0-905"></initialization>
  
      </segmentbase>
  
     </representation>
  
    </adaptationset>
  
   </period>
  
  </mpd>

  I am using video.js along with dash.js to playback the mpeg dash content on client side. The issue is that the video doesn’t playback perfectly when i simulate network conditions from chrome dev tools.

  It works at times and it doesn’t at others. For ex the stream starts with bit rate of 400kbps and then detects enough bandwidth available so it switches to 2500kbps. Then when i bring down my bandwidth to 400kbps again then the video freezes at some point of time.

  At times the video freezes after few initial seconds of playback when it tries to switch the stream. I think there might be some command line parameter that i am missing while generating my video files via ffmpeg or generating .mpd file via MP4Box.

  below are the commands i use for ffmpeg and MP4Box

  ffmpeg -y -i inputfile -c:a libfdk_aac -ac 2 -ab 128k -c:v libx264 -r 24 – g 24 -b:v 1500k -maxrate 1500k -bufsize 1000k -vf "scale=-1:720" outputfile.mp4
  
  
  
  
  
  MP4Box -dash [DURATION] -rap -frag-rap -profile [PROFILE] -out [path/to/outpout.file] [path/to/input1.file] [path/to/input2.file] [path/to/input3.file]

  Also while i am generating .mpd files via MP4Box i am getting below warning in console

  [DASH]: Files have non-proportional track layouts (320x240 vs 420x270) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1024x576) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1280x720) but sample size and aspect ratio match, assuming precision issue
  
  [DASH]: Files have non-proportional track layouts (320x240 vs 1920x1080) but sample size and aspect ratio match, assuming precision issue

  Whenever the video stops playing the chrome console has these logs

  Number of times the buffer has run dry: 25
  
  Apply STRONG to buffer rule.
  
  Quit switching bit rates.

  I don’t have any clue as to why the buffers run dry and it stops switching the bit rates.

  Anything that is predominantly wrong in the process ?

• aacenc_tns : redo coefficient quantization and decision making

  12 septembre 2015, par Rostislav Pehlivanov

  aacenc_tns : redo coefficient quantization and decision making
  This finally (and again) gets rid of basically everything the
  
  specifications say about how TNS should be done. The main
  
  problem used to be that a single filter was used for all
  
  coefficients which despite being explicitly recommended by
  
  the specifications usually sounds wrong, therefore it’s
  
  a corner case in the current TNS implementation.
  This commit also changes the coefficient bit size, as apparently
  
  it’s better to use lower precision in case the windows are eight
  
  short. This is apparently what fdk_aac uses, looking at the bit
  
  stream and makes sense. Also the order when 8 SHORT windows happen
  
  is important as 7 was too much and according to PSNR was worse
  
  while 5 is just about correct.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/aacenc_tns.c
  • [DH] libavcodec/aacenc_tns.h

• lavu/libm : misc, minor changes

  25 décembre 2015, par Ganesh Ajjanagadde

  lavu/libm : misc, minor changes
  Addition of comments marking the end of ifdef blocks, correction of an
  
  incorrect (at double precision) M_LN2, removal of an unnecessary undef.
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/libm.h