Recherche avancée

Sur d’autres sites (11744)

• GStreamer pipeline should automatically switch back to the live stream

  16 janvier, par AD Thumar

  I am using below list of version.

  


  


  Gstreamer-1.24.10, windows 10.

  


  


  I’m working on a GStreamer pipeline to handle RTSP camera streams. When the RTSP camera goes offline, I want to display a image or black screen instead of stopping the pipeline. Once the RTSP stream is back online, the pipeline should automatically switch back to the live stream.

  


  Below pipeline work but rtsp server not response that time 3 camera stop (After 19 seconds...) but 1 camera not ping that's not fulfill my requirements(My requirement is not stoping live view)

  


  I have already tried pipeline belowed :

  


  gst-launch-1.0 compositor name=comp sink_0::xpos=0 sink_0::ypos=0 sink_1::xpos=240 sink_1::ypos=0 sink_2::xpos=480 sink_2::ypos=0 ! videoconvert ! autovideosink sync=false rtspsrc location=rtspt://USERNAME:PASSWORD@IP:PORT/Streaming/Channels/101 ! rtph265depay ! avdec_h265 ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! comp. rtspsrc location=rtspt://USERNAME:PASSWORD@IP:PORT/Streaming/Channels/101 ! rtph265depay ! avdec_h265 ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! comp. rtspsrc location=rtspt://USERNAME:PASSWORD@IP:PORT/Streaming/Channels/101 ! rtph265depay ! avdec_h265 ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! comp.

  


  Can you please let me know.How to deal with this issue ??

  


• fftools/cmdutils : put stream specifier handling back into cmdutils

  14 décembre 2023, par Anton Khirnov

  fftools/cmdutils : put stream specifier handling back into cmdutils
  Stream specifiers were originally designed exclusively for CLI use and
  
  were not intended to be public API. Handling them in avformat places
  
  major restrictions on how they are used. E.g. if ffmpeg CLI wishes to
  
  override some stream parameters, it has to change the demuxer fields
  
  (since avformat_match_stream_specifier() does not have access to
  
  anything else). However, such fields are supposed to be read-only for
  
  the caller.
  Furthermore having this code in avformat restricts extending the
  
  specifier syntax. An example of such an extension will be added in
  
  following commits.
  

  • [DH] fftools/cmdutils.c

• Back porting ffmpeg.dll from electron for windows xp by disassembling

  28 juillet 2024, par Oosuke Ren

  I've recently gotten into a really interesting project of having a fully functional (and as futuristic as possible) physical retro gaming machine with windows xp. I had found One Core Api that successfully works to allow for some programs to work that otherwise wouldn't have. One of them is electron (5.0.13). Thanks to a vast testing between a VM with the kernel extender and a vanilla XP, I found out that the only thing stopping me from succeeding is because it's dependent on an EXTREMELY specific version/fork of ffmpeg (Chromium fork of ffmpeg 4.1) . Due to that being a relatively old fork/version, the build tools/links for some of the stuff are nonexistent right now, so even if I do have the fork locally with all the instructions, I can't build it. (and if I do I have to patch Win Vista+ Api functions, with one custom stub dll I have)

  


  AcquireSRWLockExclusive InitializeConditionVariable SleepConditionVariableSRW InitOnceBeginInitialize InitOnceComplete InitializeSRWLock ReleaseSRWLockExclusive WakeAllConditionVariable WakeConditionVariable

  


  Since I can't custom build ffmpeg I have to patch it's calls by redirecting them to my custom dll that includes these back ported functions and more.

  


  I tried many different ways => IDA Pro, Ghidra, objconv, currently am the closest with "DLL to C"

  


  Ida Pro and Ghidra seem to not be creating assembly code that I'd be able to assemble back after patching.

  


  objconv produces a really accurate disassembly, but the issue is it doesn't have an assembler. And the produced .asm won't assemble with Fasm, masm or nasm

  


  As for DLL to C-> successfully created a quite presentable VS project, the project successfully compiles with only one warning, the byte sizes is quite similar, the problem is => the functions are getting wrongly directed (towards wrong functions in my dll- and thus the ones needed are undefined) And this is too deep to be able to tell if it's a VS version issue, wrong code implementation or if just DLL to C has wrongly disassembled the logic.

  


  Question is, is my last option remaining to manually edit the HEXES of the Import Address Table and Import Names so they get redirected ? (the problem is my knowledge in Assembly isn't too good, so I'm not sure if that's all I'd have to do, and even if so, I have a feeling I'd mess up the Virtual Addresses or something.