Recherche avancée

Sur d’autres sites (7872)

• Does ffmpeg now natively support DTS-HD decoding ?

  20 octobre 2017, par Tom Arrow

  I know there used to be a —enable-libdcadec switch, but the newest builds available on ffmpeg.org don’t have it enabled.

  Also, DTS-HD is listed in the available decoders list.

  Also, I’ve seen some commit from not long ago that said "Remove libdcadec, we already have it merged internally"

  Also, I do get different results depending on whether I try to decode dtshd or dts files. (encoded directly to flac 5.1)

  So, any official statement on this ? Can I trust this ?

• rtmpproto : Avoid rare crashes in the fail : codepath in rtmp_open

  23 janvier, par Martin Storsjö

  rtmpproto : Avoid rare crashes in the fail : codepath in rtmp_open
  When running the cleanup in rtmp_close on failures in rtmp_open,
  
  we can in rare cases end up using rt->playpath, assuming that it
  
  is still set.
  The crash could happen if we hit the fail codepath in rtmp_open
  
  while publishing (rt->is_input == 0) with rt->state set to
  
  a value > STATE_FCPUBLISH.
  This would normally not happen while publishing ; either we have
  
  an error (and rt->state <= STATE_FCPUBLISH) or we reach
  
  rt->state = STATE_PUBLISHING, and then we also return successfully
  
  from rtmp_open.
  The unexpected combination of states could happen if the server
  
  responds with e.g. "NetStream.Play.Stop" while expecting
  
  "NetStream.Publish.Start" ; this sets rt->state to STATE_STOPPED,
  
  which also fulfills the condition "> STATE_FCPUBLISH".
  We don't need to free the rt->playpath/tcurl/flashver strings here ;
  
  they're handled via AVOption, and thus are freed automatically when
  
  the protocol instance is freed (that's why they aren't freed
  
  manually within the rtmp_close function either).
  We also don't need to free the AVDictionary with options ; it's
  
  owned by the caller.
  A smaller fix would be to just call rtmp_close before freeing
  
  the strings and dictionary, but as we don't need to free them
  
  at all, let's remove that redundant code.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/rtmpproto.c

• Audio/Video de-synchronisation when playing a video on Chrome

  30 novembre 2020, par Sonia Seddiki

  I've been recently working on a project where I try to play a "custom-made" video on an HTML5 player. By custom-made, I mean I concatenate a bunch of videos together using FFmpeg concat demuxer, each of them having the same properties (FPS, bitrate, resolution, timebase, etc).

  


  Now, I'm having a few issues regarding audio/video synchronisation, with a twist : it does not happen on every video player. The video is perfectly synchronised when read on Firefox, but not on Chrome. It is synchronised when read on a "local" video player like VLC.

  


  I assume it has to do with how the video data is presented to the player. I read a little about PTS, DTS, I-P-B frames and I guess the final output may be a little messed up ? But I don't really have a strong lead to follow here.

  


  I tried to find info on how the HTML5 player was implemented by both browsers, but couldn't find much (again, I'm probably not googling this right). Does anyone here know a bit more about the technical aspect of how a video is actually played in a browser ? Or any clue as to why this de-synchronisation doesn't happen on every platform ?

  


  Thank you so much for your help !