Recherche avancée

Sur d’autres sites (7973)

• Merge remote-tracking branch ’cus/stable’

  10 février 2015, par Michael Niedermayer

  Merge remote-tracking branch ’cus/stable’
  * cus/stable :
  
    ffplay : factorize thread starting and stopping code into decoder
  
    ffplay : make eof part of videostate and signal it when opening a stream
  
    ffplay : update frame timer based on last updated clock time when toggling pause
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] ffplay.c

• gstreamer h264 multicast missing SPS/PPS information

  6 mars 2015, par RBI

  I have two video streaming units capable of streaming live video inputs :

  • AXIS Q7424-R Video Encoder
  • EPIPHAN VGADVI Broadcaster 99460 -

  I am using gstreamer to view these streams on client terminals running linux. I am interested in the h264, rtp multicast streams (which both units support).

  I can stream the Epiphan video using the following gstreamer pipeline :

  gst-launch-0.10 udpsrc multicast-group=ADDRESS port=PORT caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! ffdec_h254 ! autovideosink

  However, this pipeline does not work for the Axis unit as I get the following error repeatedly :

  ffmpeg:0:: non-existing PPS referenced
  
  ffmpeg:0:: non-existing PPS 0 referenced
  
  ffmpeg:0:: decode_slice_header error
  
  ffmpeg:0:: no frame!
  
  ffdec_h264: decoding error (len:-1, have_data: 0)

  I have read that this error means that the ffmpeg decoder is missing the SPS/PPS information provided by a keyframe. The axis unit has a GOV parameter which is the interval at which i-frames are sent ; it is set to 32.

  Note that I can view both units’ rtp streams in unicast with the following :

  gst-launch-0.10 rtspsrc location=rtsp://ADDRESS:PORT/... latency=100 ! rtph264depay ! ffdec_h264 ! autovideosink

  Since unicast works and the unicast and multicast pipelines are the same (except for the source), my guess is either :

  • My udpsrc caps are simply incorrect for the axis stream (and I don’t really know where/how to verify it)

  • or, the axis multicast format/encoding is different and requires a modification to the pipeline (I find this unlikely since unicast is working and I don’t understand why the encoding would change between unicast/multicast).

  Any suggestions are appreciated as I am limited by my knowledge of gstreamer and media formats in terms of what to try next.

• lavu : Add av_gettime_relative

  22 octobre 2014, par Martin Storsjö

  lavu : Add av_gettime_relative
  Since av_gettime() is used in a number of places where actual
  
  real time clock is required, the monotonic clock introduced in
  
  ebef9f5a5 would have consequences that are hard to handle. Instead
  
  split it into a separate function that can be used in the cases
  
  where only relative time is desired.
  On platform where no monotonic clock is available, the difference
  
  between the two av_gettime functions is not clear, and one could
  
  mistakenly use the relative clock where an absolute one is
  
  required. Therefore add an offset, to make it evident that the
  
  time returned from av_gettime_relative never is actual current
  
  real time, even though it is based on av_gettime.
  Based on a patch by Olivier Langlois.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] doc/APIchanges
  • [DH] libavutil/time.c
  • [DH] libavutil/time.h
  • [DH] libavutil/version.h