Recherche avancée

Sur d’autres sites (10171)

• MediaController / VideoView can't play mp4 on certain phones

  29 août 2017, par Nicholas Muir

  From within my app I create a video from images that the user has taken using Ffmpeg. I the play this using MediaController and a VideoView. When I run the app using the Genymotion emulator for a Google Nexus 4 the video file plays without issue. When I use the Genymotion emulator for a Samsung Galaxy S4 I get an error from the VideoView on error listener say "Can’t play video".

  Thanks for your help.

• avcodec/flac_parser : Don't modify size of the input buffer

  6 octobre 2019, par Andreas Rheinhardt

  avcodec/flac_parser : Don't modify size of the input buffer
  When flushing, MAX_FRAME_HEADER_SIZE bytes (always zero) are supposed to
  
  be written to the fifo buffer in order to be able to check the rest of
  
  the buffer for frame headers. It was intended to write these by writing
  
  a small buffer of size MAX_FRAME_HEADER_SIZE to the buffer. But the way
  
  it was actually done ensured that this did not happen :
  First, it would be checked whether the size of the input buffer was zero,
  
  in which case it buf_size would be set to MAX_FRAME_HEADER_SIZE and
  
  read_end would be set to indicate that MAX_FRAME_HEADER_SIZE bytes need
  
  to be written. Then it would be made sure that there is enough space in
  
  the fifo for the data to be written. Afterwards the data is written. The
  
  check used here is for whether buf_size is zero or not. But if it was
  
  zero initially, it is MAX_FRAME_HEADER_SIZE now, so that not the
  
  designated buffer for writing MAX_FRAME_HEADER_SIZE is written ; instead
  
  the padded buffer (from the stack of av_parser_parse2()) is used. This
  
  works because AV_INPUT_BUFFER_PADDING_SIZE >= MAX_FRAME_HEADER_SIZE.
  
  Lateron, buf_size is set to zero again.
  Given that since 7edbd536, the actual amount of data read is no longer
  
  automatically equal to buf_size, it is completely unnecessary to modify
  
  buf_size at all. Moreover, modifying it is dangerous : Some allocations
  
  can fail and because buf_size is never reset to zero in this codepath,
  
  the parser might return a value > 0 on flushing.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/flac_parser.c

• 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