by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Scott Rubin
    @Apreche
    it seems like the case where the vidgear application connects as a client and ingests video is already covered.
    Abhishek Thakur
    @abhiTronix

    @Apreche

    vidgear application acts as a client and connets to an RTMP server like youtube/twitch/nginx

    YouTube is currently supported, I'll add support for other streams too in near future.

    the other is where the vidgear application acts as a server with an open port and RTMP clients can connect and send/receive video.
    it seems like the case where the vidgear application connects as a client and ingests video is already covered.

    I think this behavior is similar to Vidgear's high-performance NetGear API, Kindly go through it, and also see its wiki. This API is exclusively designed to transfer video frames synchronously and asynchronously between interconnecting systems over the network in real-time.

    Scott Rubin
    @Apreche
    I might be misunderstanding your documentation, but the existing youtube support you have seems to be for taking video FROM Youtube.
    I'm talking about streaming video TO YouTube so that people can watch it on YouTube.
    As for NetGear, it seems to be exactly the thing I'm talking about. However, other applications don't support the NetGear API. To achieve interoperability with other applications like VLC or OBS, another protocol like RTMP or HLS is required. RTMP isn't the best, but it's somehow become the standard, and it works.
    Abhishek Thakur
    @abhiTronix

    @Apreche

    I'm talking about streaming video TO YouTube so that people can watch it on YouTube.

    oh, ok, we can work on that.

    To achieve interoperability with other applications like VLC or OBS, another protocol like RTMP or HLS is required.

    Yes, That's a disadvantage of using NetGear API.

    RTMP isn't the best, but it's somehow become the standard, and it works.

    I may work on Streaming Feature in couple of days, depending on my schedule. But, I may have to choose the best between HLS, HSS, DASH and now RTMP for vidgear based on real-time performance and supported features.

    Scott Rubin
    @Apreche
    yeah, sadly RTMP is what is most supported, even though it is far from the best.
    Samuel Navas
    @snavas
    Hi! I'm trying to run one of the NetGear_Async examples, particularly the one with custom Server Source (using OpenCV). However, following the Server side code example I get the following error TypeError: my_frame_generator() missing 1 required positional argument: 'self'. Does someone knows why could this be due to? Ty!
    Abhishek Thakur
    @abhiTronix
    @snavas Yes, It was a typo in example-code. I've corrected it, You can now try this example again.
    Samuel Navas
    @snavas
    great, thanks, it works now!
    Samuel Navas
    @snavas
    The reason why I was looking into it is because I want to build a bi-directional videostream app, like a video chat, between two machines. I was thinking on trying to use Async Netgear to create a server loop and a client loop in one machine, and the same in the other. Do you think that's a good idea or even possible? I have been trying to merge the client code and the server code into the same python file but I dont manage to get it work (example here). Should I maybe use instead the regular NetGear with the bidirectional mode?
    Abhishek Thakur
    @abhiTronix

    @snavas >

    Should I maybe use instead the regular NetGear with the bidirectional mode?

    Yes, No doubt NetGear_Async is performance-wise superior but it provide NO support for any NetGear Exclusive modes (including bi-directional mode) yet as mentioned in its wiki. But performance difference is not that huge and also, I'm bringing performance updates for NetGear API too in upcoming PR too, so stay tuned.

    Abhishek Thakur
    @abhiTronix

    I have been trying to merge the client code and the server code into the same python file but I dont manage to get it work (example here).

    That's not the right way to do it. You should take ideas from its test file for correctly merging both server and client into one.

    Samuel Navas
    @snavas
    Thank you @abhiTronix I will check that out!
    Samuel Navas
    @snavas
    btw, small question regarding the bi-directional NetGear parameters message and return_data. According to the documentation they enable to send data (of any datatype). However, while trying to send the frames back and forth (as numpy array) I keep getting TypeError as object of type ndarray is not JSON serializable. Am I missing something? I'm trying to work around that and somehow encode and decode the numpy arrays into other datatype.
    Abhishek Thakur
    @abhiTronix
    @snavas You can't simply send Ndarray like that, since NDarray's cannot be transmitted over the network serially, and has nothing to do with supported datatype. You have two options to tackle this issue:
    Also, I probably may add internal support for NDarray datatype for bi-directional mode in NetGear API, in upcoming PR but you've to wait for it.
    Abhishek Thakur
    @abhiTronix
    @snavas I've just added inbuilt support for bidirectional frames(numpy NDarray) tranfer in development branch, Kindly see its WIKI example. Goodluck!
    Samuel Navas
    @snavas
    Thank you @abhiTronix! Actually, I managed to make it work just Jsonifying the frame. However, the performance wasn't very good, but it might be due to my own network. I was planning to test it in a better network, probably tomorrow. However, I will kindly test the bidirectional frame transfer and let you know If I find any bug or anomalous behaviour :)
    Abhishek Thakur
    @abhiTronix
    @snavas Jsonifying Numpy array is too slow, that's why I decided for adding this update to vidgear. Hope this will be helpful for you.
    Abhishek Thakur
    @abhiTronix
    @snavas This feature doesn't use jsonifying approach but rather implements a separate channel for sending frames faster over the socket. I've tested this example on my end and its working as usual, kindly give it a try, any helpful feedback is much appreciated.
    Samuel Navas
    @snavas
    I imagined something like that when I saw it needed asyncio :) Thanks a lot for your effort, I trully appreciate. I will deffinitely test it out and let you know about it!
    Samuel Navas
    @snavas
    @abhiTronix I just tested it, it works perfectly when I run two python processes in the same machine. But, I still got very bad performance when I communicate between two PCs in my home network over WLAN (using tpc and pattern=1). As I mentioned before, it might be a problem of my network and I will try using my work network probably tomorrow and let you know
    Abhishek Thakur
    @abhiTronix
    @snavas You can boost further performance with Frame Encoding/Decoding Compression in NetGear API. Give it a try too, maybe it can help.
    Also, are you sending 1080p/720p video frames bi-directionally? or less?
    Samuel Navas
    @snavas
    @abhiTronix 720p indeed
    Abhishek Thakur
    @abhiTronix
    @snavas than it maybe more than your network bandwidth. I may shortly introduce reducer() function in next commit for NetGear API to reduce overall size of frames to be sent. Stay tuned.
    Samuel Navas
    @snavas
    Looking forward to that! :)
    Abhishek Thakur
    @abhiTronix
    @snavas I've added the reducer support and also updated the example code. Kindly re-clone and reinstall vidgear's developement as previous and then try the updated example code. I'm waiting for your feedback. Goodluck!
    Samuel Navas
    @snavas
    @abhiTronix Indeed the more I reduce the frame the better the performance is. However, its far from being ideal. In the following days, I'll probably try to implement the asynchronous data transfer runing in both machines a server and a client. Regarding the frame compressiong you mentioned before, the way it is implemented in the NetGear API it would only work for the server frames in the case of the bi-directonal frame transmission, right? Otherwise, I could try combining compression and reducing the frame. Actually, I could also look into some opencv functions for reducing frame size as well.
    Abhishek Thakur
    @abhiTronix

    However, its far from being ideal.

    @snavas can you elaborate?

    In the following days, I'll probably try to implement the asynchronous data transfer runing in both machines a server and a client.

    Yes, it is possible to implement by oneself but if you want this feature in vidgear, then you have to wait for long. As my other pending project(s) is right now my priority, and thereby I can only work on this project in my free time. But if you need this feature in time, then consider support this project through helpful donation.

    Regarding the frame compression you mentioned before, the way it is implemented in the NetGear API it would only work for the server frames in the case of the bi-directional frame transmission, right?

    Yup, it's true.

    Otherwise, I could try combining compression and reducing the frame

    Reducer can work bi-directionally but compression works one way only for now. You can implement similar behavior for client's end too in your script, it's easy. Adding this feature internally might make things complicated.

    Actually, I could also look into some opencv functions for reducing frame size as well.

    Nope, it's the best way and only ideal way to reduce size, and I've been working with OpenCV for now 4 years almost.

    Samuel Navas
    @snavas

    Thank you @abhiTronix for clarifying!

    However, its far from being ideal.

    @snavas can you elaborate?

    I meant, I need to reduce the frame size a lot in order to get decent framerate in both ends.

    However, this afternoon I've done further testing. I have been setting up a NetGear_Async client and server pair per each PC. Together with frame size reduction and the NetGear Frame Encoding/Decoding Compression I have been managing quite acceptable results!

    You can implement similar behavior for client's end too in your script, it's easy.

    I might give a chance to this and try to implement it tomorrow though!

    lucaslugao
    @lucaslugao
    Hello everyone, is there anyway to get the associated timestamp when capturing a frame with the CamGear? I'm currently using cv2 VideoCapture.get(cv2.CAP_PROP_POS_MSEC) and I would like to switch the VidGear library
    Abhishek Thakur
    @abhiTronix
    @lucaslugao I've already answered this question: https://github.com/abhiTronix/vidgear/issues/53#issuecomment-529282409
    Abhishek Thakur
    @abhiTronix
    @mateothegreat I've responded to your mail.
    Abhishek Thakur
    @abhiTronix

    New VidGear v0.1.8 Released 🥳

     

    Multiple Clients support in NetGear API:

    • Implemented support for handling any number of Clients simultaneously with a single Server in this mode.
    • Added new multiclient_mode attribute for enabling this mode easily.
    • Built support for zmq.REQ/zmq.REP and zmq.PUB/zmq.SUB patterns in this mode.
    • Implemented ability to receive data from all Client(s) along with frames with zmq.REQ/zmq.REP pattern only.
    • Updated related CI tests

    Support for robust Lazy Pirate pattern(auto-reconnection) in NetGear API for both server and client ends:

    • Implemented a algorithm where NetGear rather than doing a blocking receive, will now:
      • Poll the socket and receive from it only when it's sure a reply has arrived.
      • Attempt to reconnect, if no reply has arrived within a timeout period.
      • Abandon the connection if there is still no reply after several requests.
    • Implemented its default support for REQ/REP and PAIR messaging patterns internally.
    • Added new max_retries and request_timeout(in seconds) for handling polling.
    • Added DONTWAIT flag for interruption-free data receiving.
    • Both Server and Client can now reconnect even after a premature termination.

    Performance Updates for NetGear API:

    • Added default Frame Compression support for Bidirectional frame transmission in Bidirectional mode.
    • Added support for Reducer() function in Helper.py to aid reducing frame-size on-the-go for more performance.
    • Added small delay in recv() function at client's end to reduce system load.
    • Reworked and Optimized NetGear termination, and also removed/changed redundant definitions and flags.

    Docs Migration to Mkdocs:

    • Implemented a beautiful, static documentation site based on MkDocs which will then be hosted on GitHub Pages.
    • Crafted base mkdocs with third-party elegant & simplistic mkdocs-material theme.
    • Implemented new mkdocs.yml for Mkdocs with relevant data.
    • Added new docs folder to handle markdown pages and its assets.
    • Added new Markdown pages(.md) to docs folder, which are carefully crafted documents based on previous Wiki's docs, and some completely new additions.
    • Added navigation under tabs for easily accessing each document.

    and many more...

    Abhishek Thakur
    @abhiTronix
    Also, VidGear Docs now Available at https://abhitronix.github.io/vidgear
    josefhernandez
    @josefhernandez
    I'm trying to stream the ouput of a opencv+tensorflow app to a webbrowser, How can I pass these frame to webgear?
    aubulas
    @aubulas
    Hello, I am using vidgear to grab images from a youtube livesteam for machine learning... I want to grab an image every 10 or so seconds (the interval doesn't need to be precise). Is there a way to leave a stream object open for several hours and to grab the most recent frame when I ask it to using CamGear? It currently grabs the frames in order meaning one frame is 1/60th of a second. At first I was initializing a new stream for each image... but this caused YouTube to block me after about 48 hours of running hah.
    Abhishek Thakur
    @abhiTronix
    @aubulas VidGear does videocapturing with multi-threading in unrestricted manner, and thereby you cannot block the background process in any means possible, so you propably have to develop api for yourself. You can however disable this multi-threading but you then have deal with problems like frame-skipping, deadlocks, and race conditions, etc. For more information see: Threaded Queue Mode
    Devon Bray
    @esologic

    Hi Abhishek! Your library is absolutely amazing, however, there is a feature that I think would be easy for you to implement that could make it even more powerful. This came up on stackoverflow a few days ago here. This person is pointing out that when one is trying to stream to an RTMP server using ffmpeg, the location of the server is put in the command where the name of the output file normally goes. Example:

    ffmpeg -re -i file.flv -c copy -f flv rtmp://live.twitch.tv/app/<stream key>

    I got this example from here.

    It would be amazing if we could provide rtmp addresses instead of output file paths with WriteGear.

    Thanks! - Devon

    Abhishek Thakur
    @abhiTronix
    @esologic Thanks for suggesting this feature. I think it will be easier to implement and will be a good addition. Can you raise this idea as a issue in our GitHub Repo., so we can start working on this.
    Devon Bray
    @esologic
    Created the issue! abhiTronix/vidgear#144
    gtandalus
    @gtandalus
    >Hi.
    Using your example code for CamGear to access youtube videos.
    stream = CamGear(source=<URL>, y_tube =True).start()
    Some <URL> values work OK, e.g.
    https://www.youtube.com/watch?v=4Z8ZFOkCD7k
    https://www.youtube.com/watch?v=bBrUrgNf5y8
    Others generate error, e.g.
    "https://www.youtube.com/watch?v=vDrVS0_DnRM"
    as below:
    [ERROR:0] global C:\projects\opencv-python\opencv\modules\videoio\src\cap.cpp (142) cv::VideoCapture::open VIDEOIO(CV_IMAGES): raised OpenCV exception:

    OpenCV(4.3.0) C:\projects\opencv-python\opencv\modules\videoio\src\cap_images.cpp:235: error: (-5:Bad argument) CAP_IMAGES: error, expected '0?[1-9][du]' pattern, got: https://manifest.googlevideo.com/api/manifest/dash/expire/1594307477/ei/Nd8GX7-zIqSOxgLQ-7zIAg/ip/84.78.245.177/id/bc3ad54b4fc39d13/source/youtube/requiressl/yes/playback_host/r2---sn-vg5obxn25po-n89z.googlevideo.com/mh/Yb/mm/31%2C29/mn/sn-vg5obxn25po-n89z%2Csn-h5q7kned/ms/au%2Crdu/mv/m/mvi/2/pl/25/hfr/all/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/initcwndbps/1060000/vprv/1/mt/1594285781/fvip/2/keepalive/yes/itag/0/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Chfr%2Cas%2Cvprv%2Citag/sig/AOq0QJ8wRgIhANSUtVN3u9g5eFbXkiUw3j_s0xyPFr0n-7upda-Koi5JAiEAit0ttN2N-T2cCEMhnkfUwN3-txP0ZyKJk-5lR2YmsbU%3D/lsparams/playback_host%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps/lsig/AG3C_xAwRAIgPUXNaWXdf2kk30uL-ww74rZ4wpP1H2FI1nRX-L7yArgCIHy_qeyz1VRQ-Po3E5ffAn4HjhKxgcqCrKGgu-DzAI2Z in function 'cv::icvExtractPattern'


    Traceback (most recent call last):
    File "D:\Users\gtand\PycharmProjects\motion_detector.py\testcamgear.py", line 11, in <module>
    stream = CamGear(source=mys2, y_tube =True).start() # YouTube Video URL as input
    File "C:\Users\gtand\AppData\Roaming\Python\Python38\site-packages\vidgear\gears\camgear.py", line 213, in __init__
    raise RuntimeError(
    RuntimeError: [CamGear:ERROR] :: Source is invalid, CamGear failed to intitialize stream on this source!

    Am using Python 3.8
    vidgear package version 0.1.8
    opencv-python version 4.3.0.36
    opencv-contrib-python 4.3.0.36
    Abhishek Thakur
    @abhiTronix
    @gtandalus This a bug with FFmpeg supplied with OpenCV and has nothing to do with vidgear. Kindly try this workaround suggested here to solve this issue.
    @esologic Kindly try PR abhiTronix/vidgear#145 related to your issue.
    Thomasedv
    @Thomasedv

    Hi, i got a bit of a question/issue, i was trying to encode a ~70 frames video with a low resolution, but kept on getting empty output files. I had a strong suspicion that ffmpeg was terminated early, due to in some other cases I ended up with no chapters in a video that previously had that, a typical issue from ffmpeg getting closed early, at least per google. As such, i had a look at the source and i saw the following in the close() method of writegear.py:

    if self.__output_parameters and "-i" in self.__output_parameters:
        self.__process.terminate()

    While i may wildly guess it's to prevent from wrongfully encoding more than the duration of frames supplied by the user, in this case that seems to lead to the last buffer of frames getting dropped and ffmpeg exiting before it's supposed to, and there won't be any output since all the frames were in that buffer. Commenting out those lines fixed my issue. I'll happily pop over to github and make an issue, but i thought i'd ask here if i should consider it a bug first, or there is some specific reason why it's done this way. Either way, it might be smart to let users prevent killing the process when the -i flag is supplied without editing the source code for vidgear.

    Abhishek Thakur
    @abhiTronix
    @Thomasedv Nope, your FFmpeg settings are wrong. Kindly raise the issue with complete terminal log(enable logging=True) on GitHub. Also, provide the source code in which you used WriteGear API.
    Thomasedv
    @Thomasedv
    Issue submitted, but i do not believe this is a problem on my end. The logging doesn't even print the conversion that ffmpeg usually does after calling .close, but it dose when i remove the lines i believe to be the cause.