Recherche avancée

Sur d’autres sites (3107)

• avcodec/tiff : Restrict tag order based on specification

  20 août 2020, par Michael Niedermayer

  avcodec/tiff : Restrict tag order based on specification
  "The entries in an IFD must be sorted in ascending order by Tag. Note that this is
  
   not the order in which the fields are described in this document."
  This way various dimensions, sample and bit sizes cannot be changed at
  
  arbitrary times which reduces the potential for bugs.
  
  The tag reading code also on various places assumes that numerically previous
  
  tags have already been parsed, so this needs to be enforced one way or another.
  If this commit causes problems with real world files which are not easy to fix
  
  then some other form of checks are needed to ensure the various dependencies
  
  in the tag reading are not violated.
  Fixes : out of array access
  
  Fixes : 24825/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6326925027704832
  Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/tiff.c

• movenc : Allow setting start_dts/start_cts before writing actual packets

  3 novembre 2015, par Martin Storsjö

  movenc : Allow setting start_dts/start_cts before writing actual packets
  By writing a zero-sized packet, the caller can communicate the
  
  start_dts/start_cts for the stream without actually writing
  
  the first packet.
  This allows doing random-access writing of fragments when the
  
  start dts of the stream isn’t zero, so that the edit list in the moov
  
  is written based on timestamps from the nominal start time signaled
  
  via the zero-sized packet, while the first proper packet written
  
  corresponds to a later fragment.
  To avoid potential unexpected behaviour, empty packets only set
  
  start_dts if the frag_discont flag is set.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/movenc.c

• Using ffplay with RTSP and source-specific multicast

  14 septembre 2022, par bigbrobrody

  We are trying to use ffplay to join a live video source in a network that uses IGMPv3 source-specific multicast.

  


  If we use an SDP file this works fine and wireshark shows that ffplay correctly sends a source-specific multicast membership report.

  


  However, when we try to join the same source using RTSP, ffplay seems to ignore the source-specific address contained in the SDP response to RTSP DESCRIBE and fails because it tries to join for any source. This is the command used :

  


  ffplay -loglevel debug -rtsp_transport udp_multicast -protocol_whitelist rtp,udp,tcp -i rtsp://[username:password]@[ip address]/stream0

  


  The SDP response as reported by ffplay includes :

  


  a=source-filter: incl IN IP4 * [ssm ip address]

  


  The only error reported by ffplay is :

  


  Failed to parse interval end specification ''

  


  Wireshark shows that ffplay is not performing an SSM join :

  


  Membership Report / Join group [group IP address] for any sources

  


  Further details in the screenshot below. Are we doing something wrong, is this a feature of ffplay or a potential bug ?

  


  I note that libavformat/rtsp.h contains the comment /** The following are used only in SDP, not RTSP */ against code for sdp port, source-specific multicast addresses, etc. I’m not sure if that hints at our issue being because of a feature in ffmpeg.

  


  ffplay using rtsp and ssm