Recherche avancée

Sur d’autres sites (5082)

• Error while saving RTSP to .mp4 from a Hikvision using cvlc, openRTSP or ffmpeg

  4 octobre 2020, par Rui Martins

  I'm trying to save an RTSP streaming from a hikvion camera to a .mp4 file in a USB pen drive in a raspberry pi 3.

  


  I'm using raspbian, I read a lot from the internet, and I'm using different programs to try to save the video.

  


  I used cvlc, openRTSP and ffmpeg, and all of them have errors...

  


  Some commands that I used :

  


  openRTSP -D 1 -c -B 10000000 -b 10000000 -4 -Q -F video_openRTSP_ -P 1200 -w 1920 -h 1080 -f 25 -t -u admin xxxxx rtsp://admin:xxxxx@192.168.1.64:554/h264/ch1/main/av_stream


  


  ffmpeg -i rtsp://admin:xxxxx@192.168.1.64:554/h264/ch1/main/av_stream -acodec copy -vcodec copy ffmpeg.mp4


  


  cvlc --rtsp-tcp rtsp://admin:xxxxx@192.168.1.64:554/h264/ch1/main/av_stream --sout=file/mp4:cvlc.mp4 --stop-time=900 vlc://quit


  


  I tried a lot of different parameters for each one of these 3 programs... The final result never was good. I guess the Hikvision firmware is not implementing well the RTSP protocol...

  


  Exists some alternative firmware for Hikvision cameras ? As we have openWRT and ddWRT for routers ?

  


  Someone had the same problem as me ?

  


  (I want to store at least 15 minutes, even when the .mp4 file is saved, sometimes only save few seconds of videos, and sometimes I can't reproduce the video)

  


  Pictures of the errors :

  


  openRTSP :

  


  

  


  

  


  ffmpeg :

  


  

  


  

  


• Decoding RIMM streaming file format

  1er août 2019, par ThomasRS

  I want to decode the video (visual) frames within a Blackberry RIMM file. So far I have a parser, and some corresponding container documentation from RIM. 

  The video codec is H264 and is explicitly set on the device using one of the video.encodings properties. However, FFMPEG is not able to decode the frames and this is driving me nuts.

  Edit 1 : The issues seems to be lack of SPS and PPS in the frames, and artificially inserting them have proven unsuccessful so far (all grey image). Blackberry 9700 sends

  0x00 0x00 0x ?? 0x ?? 0xType

  where Type is according to table 7-1 in the H264 spec (I and P frames). We believe the 0x ?? 0x ?? represent the size of the frame, however the size does not always correspond to the size found by the parser (the parser seems to be working correctly).

  I have a windows decoder codec from blackberry, called mc_demux_mp2_ds.ax, and can play some MPEG-4 files captured the same way, but it is a binary for windows. And the H264 files will not play either way. I am aware of previous attempts. The capture url for javax.microedition.media.Manager is

  encoding=video-3gpp_width=176_height=144_video_codec=H264_audio_codec=AAC

  and I am writing to an output stream. Some example files here.

  Edit 2 :Turns out that about 3-4 of the 12-15 available video capture modes are flat out failing and refusing to output data, even in the simplest of test applications. So any working solution should implement MPEG-4, H264 and H263 in both AMR and AAC, in so getting fallback alternatives when one sound codec and/or resolution fails. Reboots, hangs and what not litters the Blackberry video implementation and vary from firmware to firmware ; total suckage.

• Revision 2cfddec332 : Refactor column integral projection computation Move the scaling factor outside

  16 mars 2015, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_mcomp.c

  
   Modify /vp9/encoder/x86/vp9_avg_intrin_sse2.c

  
  
  Refactor column integral projection computation

  Move the scaling factor outside column projection. This avoids
  repeated calculation of the same scaling factor. Profiling shows
  that the percentage of vp9_int_pro_col_sse2 of overall cycles
  goes from 2.29% down to 1.88%.

  Change-Id : I5ac4e324ab2d7f33ba2de66dd2a12e04e04dfd66