Recherche avancée

Sur d’autres sites (15757)

• avformat/matroskaenc : Write SeekHead when livestreaming

  26 avril 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Write SeekHead when livestreaming
  Commit 6fd300ac6c2c3871736ce0e6df95603255004dc6 added support for WebM
  
  Chunk livestreaming ; in this case, both the header as well as each
  
  Cluster is written to a file of its own, so that even if the AVIOContext
  
  seems seekable, the muxer has to behave as if it were not. Yet one of
  
  the added checks makes no sense : It ensures that no SeekHead is written
  
  preliminarily (and hence no SeekHead is written at all) if the option
  
  for livestreaming is set, although one should write the SeekHead in this
  
  case when writing the Header. E.g. the WebM-DASH specification [1]
  
  never forbids writing a SeekHead and in some instances (that don't apply
  
  here) even requires it (if Cues are written after the Clusters).
  [1] : https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/webm-dash-specification
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c

• MP4Box Resolution unmatched between representation

  30 janvier 2018, par Massimo Vantaggio

  for one of the last stability tests i try with two representation instead the only one of before to get the adaptive bitrate streaming .
  Below my encoding command :

  ffmpeg -y -i $name -i logo.png -c:a aac -b:a 256k -ar 48000 -ac 2 -async 1 -c:v libx264 -x264opts keyint=$GOP:min-keyint=$GOP:no-scenecut -bf 0 -r $FPSC -b:v 1060k -maxrate 1060k -bufsize 530k -profile:v main -t $FDUR -filter_complex "[0:v][1:v]overlay=main_w-overlay_w-10:10,scale=-1:478" format480.mp4
  
  
  
  ffmpeg -y -i $name -i logo.png -c:a aac -b:a 384k -ar 48000 -ac 2 -async 1 -c:v libx264 -x264opts keyint=$GOP:min-keyint=$GOP:no-scenecut -bf 0 -r $FPSC -b:v 2400k -maxrate 2400k -bufsize 1200k -profile:v main -t $FDUR -filter_complex "[0:v][1:v]overlay=main_w-overlay_w-10:10,scale=-1:1080" format1080.mp4

  If for the first rapresentation i use 480p ffmpeg give me this error :

  width not divisible by 2 (853x480)
  Error initializing output stream

  If i use for first representation 478p ffmpeg run correctly all two encoding but after when i try to load these two files on MP4Box to dash them live with the following command :

  MP4Box -dash-live 8000 -subdur 8000 -profile dashavc264:live -mpd-refresh 240.0 -time-shift 24 -min-buffer 4000 -insert-utc -no-cache -out manifest.mpd format1080.mp4#video format480.mp4#video format1080.mp4#audio format480.mp4#audio

  the error come back into mp4box :
  "files have not-proportional layout 1920 x 1080 vs 849 x 478 but sample size and aspect ratio match, assuming precision issue"

  I would like to understand what i don’t know about, which are the resolutions that match, i understand that some movies have atypical resolution for example 1040 or 432 but the input video for this test is correct 1920 X 1080 and i wish to compress/encode it for dash and to create another representation with 480p, could i ask where I’m wrong ?
  Thanks !
  Massimo

• mov : Support default-base-is-moof.

  1er juillet 2014, par Yusuke Nakamura

  mov : Support default-base-is-moof.
  default-base-is-moof shall be set to track fragments compatible with DASH
  
  Media Segments. So, this is a fundamental support for ISOBMFF ver. DASH.
  
  This is meaningful only when base-data-offset-present is absent and two or
  
  more track fragments are present in a movie fragment.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/isom.h
  • [DH] libavformat/mov.c