Recherche avancée

Sur d’autres sites (12327)

• Read H264 streaming from Elp H264 with OpenCV + Pyhton

  15 janvier 2017, par Francesco Paissan

  I’m trying to read an udp streaming of a H264 encoded image. The software structure is like follows :

  On a BeagleBoneBlack (Ubuntu 16.04) I’ve an Elp H264 cam (see here : https://www.amazon.com/ELP-Support-Android-Windows-Surveillance/dp/B00VDSBH9G ). I stream frames with ffmpeg on a Unicast UDP Stream.

  I want to read this images from python and opencv to be able to process them.

  I tried with this simple code to see if the cap is opened or not :

  import cv2

  try:
  
       cap = cv2.VideoCapture("udp://localhost:1234/")
  
      cap.set(CV_CAP_PROP_FOURCC, CV_FOURCC('H', '2', '6', '4'));
  
  except Exception, e:
  
      print str(e)

  But when I run this script python says :

  DtsGetHWFeatures : Create File Failed DtsGetHWFeatures : Create File
  Failed Running DIL (3.22.0) Version DtsDeviceOpen : Opening HW in mode
  0 DtsDeviceOpen : Create File Failed libva info : VA-API version 0.38.1
  libva info : va_getDriverName() returns -1 libva error :
  va_getDriverName() failed with unknown libva error,driver_name=(null)
  libva info : VA-API version 0.38.1 libva info : va_getDriverName()
  returns -1 libva error : va_getDriverName() failed with unknown libva
  error,driver_name=(null) libva info : VA-API version 0.38.1 libva info :
  va_getDriverName() returns -1 libva error : va_getDriverName() failed
  with unknown libva error,driver_name=(null) libva info : VA-API version
  0.38.1 libva info : va_getDriverName() returns -1 libva error : va_getDriverName() failed with unknown libva error,driver_name=(null)
  GStreamer Plugin : Embedded video playback halted ; module vaapidecode
  reported : Could not initialize supporting library. OpenCV
  Error : Unspecified error (GStreamer : unable to start pipeline ) in
  cvCaptureFromCAM_GStreamer, file /builddir/build/BUILD/opencv-
  2.4.12.3/modules/highgui/src/cap_gstreamer.cpp, line 816 /builddir/build/BUILD/opencv-2.4.12.3/modules/highgui/src/cap_gstreamer.cpp:816 :
  error : (-2) GStreamer : unable to start pipeline in function
  cvCaptureFromCAM_GStreamer

  Can anybody help me ?

  Thanks,

  Francesco.

• lavf : deprecate av_stream_get_end_pts()

  17 août 2022, par Anton Khirnov

  lavf : deprecate av_stream_get_end_pts()
  According to its documentation it returns "pts of the last muxed packet
  
  + its duration", but the value it actually returns right now is
  
  (possibly guessed) dts after muxer-internal bitstream filtering (if
  
  any).
  This function was added for ffmpeg.c, but it is not used there anymore.
  
  Since the value it returns is ill-defined and so inappropriate for any
  
  serious use, deprecate it.
  

  • [DH] doc/APIchanges
  • [DH] libavformat/avformat.h
  • [DH] libavformat/mux_utils.c
  • [DH] libavformat/version_major.h

• avformat/hls : Check local file extensions

  3 juin 2017, par Sysiphus

  avformat/hls : Check local file extensions
  This reduces the attack surface of local file-system
  
  information leaking.
  It prevents the existing exploit leading to an information leak. As
  
  well as similar hypothetical attacks.
  Leaks of information from files and symlinks ending in common multimedia extensions
  
  are still possible. But files with sensitive information like private keys and passwords
  
  generally do not use common multimedia filename extensions.
  
  It does not stop leaks via remote addresses in the LAN.
  The existing exploit depends on a specific decoder as well.
  
  It does appear though that the exploit should be possible with any decoder.
  
  The problem is that as long as sensitive information gets into the decoder,
  
  the output of the decoder becomes sensitive as well.
  
  The only obvious solution is to prevent access to sensitive information. Or to
  
  disable hls or possibly some of its feature. More complex solutions like
  
  checking the path to limit access to only subdirectories of the hls path may
  
  work as an alternative. But such solutions are fragile and tricky to implement
  
  portably and would not stop every possible attack nor would they work with all
  
  valid hls files.
  Developers have expressed their dislike / objected to disabling hls by default as well
  
  as disabling hls with local files. There also where objections against restricting
  
  remote url file extensions. This here is a less robust but also lower
  
  inconvenience solution.
  
  It can be applied stand alone or together with other solutions.
  
  limiting the check to local files was suggested by nevcairiel
  Found-by : Emil Lerner and Pavel Cheremushkin
  
  Reported-by : Thierry Foucu <tfoucu@google.com>
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/hls.c