Raspberry Pi support #172
Comments
|
Relevant to this are also @ford-prefect 's changes to support compressed video |
|
Just dumping what I have so far for compressed support:
To actually make this work on the RPi, presumably we'd also need to swap out the use of v4l2src with the rpicamsrc. |
|
I have also a compressed media src (H264 and Opus) i will try your patches. @ford-prefect: just try but doesn't work i think owr_transport_agent.c or _owr_payload_create_encoder should also be patched. I mean if the source is already in the good format no need to create an encoder. (i didn't compile any video or audio encoder) |
|
I'm trying to do the same for Opus encoding the pipeline looks like successfully created but nothing works. Source Pipeline |
|
Yes, I've tested with Opus and Vorbis, and it did work (the gstinterapptest in the gst-plugin-bad/gst/inter repo tests audio). It looks like the buffers are going into interappsink but not coming out interappsrc. Could you run with GST_DEBUG=default:5 and see if there are messages from gstintersurface.c that suggest what's going on? One possibility is that the keyframe buffers are not marked appropriately. Putting an opusparse element after your interappsrc might help in that case. |
|
Same as h264parse i added an opusparse. @ford-prefect I have an error gstsegment invalid position
This the function called to push a buffer in my appsrc. static gboolean gst_appsrc_push_audio(unsigned char *inBuf, unsigned int size, void *user_data) {
GstFlowReturn ret;
OwrLocalMediaSourcePrivate *priv = OWR_LOCAL_MEDIA_SOURCE_GET_PRIVATE(user_data);
GstElement* appsrc = priv->source;
if(!appsrc){
return FALSE;
}
if(GST_STATE(appsrc) != GST_STATE_PLAYING){
g_print("Appsrc not playing ignore callback\n");
return FALSE;
}
GstBuffer *buffer = gst_buffer_new_allocate (NULL, size, NULL);
gst_buffer_fill (buffer, 0, inBuf, size);
ret = gst_app_src_push_buffer(GST_APP_SRC(appsrc), buffer);
if (ret != GST_FLOW_OK) {
g_error("PUSH AUDIO NOT OK\n");
return FALSE;
}
return TRUE;
} |
|
@ford-prefect Try also with h.264 but same issue, maybe it's comming from my appsrc module. Do you have an idea ?
|
|
Could you post the verbose logs for the h.264 case too? |
|
@ford-prefect Yes, i add some print inside OWR remove useless log |
|
The segment handling messages might be relevant, which is one of the big missing pieces in the interapp* elements. If you could put up a full GST_DEBUG=5 log somewhere (it will be quite large), I can try to confirm that. |
|
Print a full debug need a lot of cpu/time which is not possible because i have time constraint due to the callbacks of the audio/video encoder. Do you a more restricted GST_DEBUG output that could help ? PS: What's the point to use differents pipeline and inter-connect them instead of putting everything in the same pipeline (Sorry maybe the answer is obvious) ? That's the output : |
|
If you write it to a file instead of the terminal it should be better performance and have less impact. |
|
@superdump Thanks |
|
@ford-prefect Did you have time to check the log ? If you have a more verbose version of interapp i could give you the output log. Thanks for your help |
|
Sorry, I missed replying to this -- I don't see any output from the interapp code (specifically the GstDeferredClient code in gstintersurface.c) in either of those logs. Could you double-check that they are plugged in and buffers are reaching the interappsink? |
|
@ford-prefect : I did it again and add more print in the gstinstersurface. https://gist.githubusercontent.com/frozeus/b8197560e95188400638/raw/GST_DEBUG |
|
It's not absolutely clear to me what the problem is, but it could be related to the segment handling being incorrect: 0:01:15.968242791 447 0x7b7430 DEBUG default /home/clement/linux-wbp//system//gstreamer//./gst/gstsegment.c:483:gst_segment_to_running_time: invalid position (-1) If you're up to it, a backtrace of where that message is coming from can confirm this (and would probably happen on any machine, not just the Raspberry Pi). |
|
@ford-prefect Sorry if the answer is obvious but what is the point to use 2 different pipelines and connect them with an intersrc/sink ? (instead of all the element in the same pipeline) |
|
I think my appsrc is not working properly. I tried to connect it directly inside the transport pipeline without interapp* but still the same issue the buffer inside appsrc is increassing but never release the data. |
|
The long-term solution for the Raspberry Pi might be:
The Raspberry Pi is, as many know, a very capable platform when used optimally. Ideally we would want to obtain both a preview and compressed stream from the camera source to make optimal use of the tight connection between the camera module and the codecs. Unfortunately I don't think that is currently possible, or at least it wasn't last time I checked. The RPi can certainly handle 1080p30 in real-time with very low latency making it an excellent candidate for simpler low-latency use cases. The main problem is that the encryption runs in software on the CPU and the CPU is not so fast. Maybe with the RPi 2, that isn't a problem. Maybe there's a way to optimize the CPU usage for encryption/decryption. Suggestions welcome! 😄 |
|
See also #240 |
|
@ford-prefect sorry for the false bug report, i just found that my owr wasn't working due to an error from libnice : |
|
@Frozeus good to hear that! Is it working end-to-end now? On 19 March 2015 at 15:47, frozeus notifications@github.com wrote:
|
|
Could we start a bounty on this? Free pizza for the person who gets this working perhaps? If others are interested in helping the bounty, we could add it up. I'd be happy to chip in. |
|
😀 |
|
I will add a OpenWebRTC T-shirt and some Swedish chocolate to @lordmundi's bounty 😃 |
|
It looks like @philn is working on building OpenWebRTC on the RPi here: https://github.com/metrological/buildroot/tree/owr However, that is using a different build system and probably building a bunch of stuff that people may not want for developing simple OpenWebRTC applications. I don't know anything about that build system though. Ideally someone needs to create a cerbero configuration for the RPi, add a recipe for https://github.com/thaytan/gst-rpicamsrc and add the remaining appropriate modifications to https://github.com/ford-prefect/openwebrtc/commits/compressed to get everything working. |
|
It may be possible to build using cerbero natively on a Raspberry Pi (or in a cross-compilation environment) already. It would be awesome however if cerbero could set up a cross-compilation environment for the RPi itself with a config and bootstrapper... |
|
@ford-prefect : My devboard is very ressource limited i try but it's more a presentation slides than a fluent stream. I remove the interapp, hardcoded the caps and put the appsrc in the transport pipeline (I just need to receive the stream from my board) the stream is nice now but still have issue with sound :S. |
|
OWR can do sendonly/ recvonly. If not there's a bug to fix. |
|
I almost have binaries built for Raspbian for the RPi 2. I'll publish those, hopefully also with Python bindings for convenience, as part of the 0.4.0 release. I'll mark this issue as blocking the 0.4.0 milestone just for RPi 2 binaries. If I get that working, I can perhaps also sort out something for the RPi '1' but that's a bit further off. |
|
How can i use this :) is there any repository in github. thanks a lot. |
|
Not yet. It's coming soon when I have time to finish off the last bits and test it. |
|
Hi, I was wondering if there were any updates to RPi support? Looking to build a native WebRTC based application on an embedded device, and Raspberry Pi's price and hardware encoding makes it pretty much unbeatable :) OpenWebRTC seems like the perfect fit. |
|
I need to dig out what I had. A reliable cross-compilation environment would really help a lot! |
|
Hi, it seems that you were able to get this done, as you removed this from the 0.4.0 milestone. Is there any way that you could help me out with the RPi 2 binaries? or with information about which files do i have to modify? or if you were able to use the cerbero cross-compilation? im really interested in this, and would love to get my hands on these features before 0.4.0 comes out with many other stuff. Thanks so much in advance. |
|
@superdump any updates? |
|
It was removed from the 0.4.0 milestone because we decided it was not critical to have and getting an updated release out sooner is more important. If someone could provide a simple and reproducible way to set up a cross-compilation environment on Ubuntu 14.04 or by mounting the desired code directory into a docker container, that would drastically help. The problem is that iterating on fixing bugs takes a long time and progress is very slow because of how slow it is to build stuff. A generic cross-compilation environment for the RPi that I can set up with docker or an Ubuntu VM + script would be awesome. |
|
Not sure if this helps, but i'm trying to use this to cross-compile: http://raspberrypi.stackexchange.com/questions/29871/how-to-build-native-webrtc |
|
I'm new to this so please forgive me if I am not doing something correctly here. I am the owner of a small startup called RealBotics, Inc. (realbotics.com) and am very interested / need to have OpenWebRTC working on rPi2 and rPi3s. I was wondering if I were to post a $500 bounty on bountysource.com if that would be enough to stimulate the completion of this task by ~June 1, 2016. I also want to say thank you to everyone for all of the hard work thus far and in the future. |
|
I had managed to build everything on RPi2 using cerbero up to javascriptcoregtk at which point I ran out of memory. If you don't need the JavaScript API and will be implementing stuff against the C API then that should be sufficient. I had also made a recipe for building gst-rpicamsrc to use as the camera source to obtain H.264 directly from the source which is most efficient on the RPi. I will try to find these changes and publish them. After that, some work will be needed on OwrLocalMediaSource/OwrMediaSource and possibly OwrTransportAgent to support compressed sources though it should be much easier now than it was previously. The source will need to use rpicamsrc, request the appropriate compressed format from it and identify its output as compressed somehow. The transport agent code will then need to bypass any raw video processing elements and instead just pass the buffers through something like To support the SCReAM bitrate adaptation, a compressed source will need to expose a mechanism to set the target bitrate and wherever it is normally set on the encoder element in the transport agent it will need to instead set it on the source. I think when receiving FIR or PLI packets we will trigger requesting a new intra frame and that will flow back up to the source so shouldn't need any changes, hopefully. I can't think of anything else right now. Shout if anyone needs help. |
|
That will need rebasing but that allowed me to build everything but javascriptcoregtk on an RPi2. It's a bit ha josh and cross compiling is desirable to not hit the out of memory issues when building javascriptcoregtk and also because it should be faster. If someone can get cross compiling to work somehow (whether by setting up an environment to run cerbero in or hooking the toolchain into cerbero) please please let me know here! |
|
@RealBotics both @philn and @superdump has been looking into this from time to time. I leave it to them to report on the progress. |
|
Hi there, I was working some week ago on this, but had to switch task. I just pushed the branch to https://github.com/Metrological/openwebrtc/commits/calvaris/rpi-compressed . Take into account that all code there is experimental and non-definitive. I hope I can retake it at some point, but if anybody can use it, you are welcome. |
|
@stefanalund @philn @superdump and @calvaris Thank you all of the hard work and updates! I am still putting the word out trying to find an active developer to get it finished. If someone is interested let me know. Thanks again! |
|
@RealBotics, does your bounty require the patch to be accepted upstream by this project to count? |
|
@Oflameo, I hope that it is accepted upstream, but that is not required for the bounty. I just need access to the code and confirm that I can install and run it on a rPi 2 and 3. |
|
@calvaris - thanks! That should help a lot! :) |
|
Note that gst-rpicamsrc now has support for raw video. I haven't had time to check it yet though. |
|
Hi Guys, I am very interested by this project. I have successfully built openwebrtc on the Rpi3 but apparently this is still not supported very well (even the simple gst-io test is crashing with a lot of gstreamer errors). It turns out that there are several repositories and branches for this purpose. What is the most up to date one? As a workaround, I have implemented a small gateway to stream the rpi camera into a remote node, and this node is responsible of the openwebrtc server. Obviously, this is not a convenient solution though. Thanks for your help! `./test-gst-io (lt-test-gst-io:12272): GStreamer-CRITICAL **: gst_element_factory_make: assertion 'factoryname != NULL' failed ** (lt-test-gst-io:12272): CRITICAL **: _owr_create_decoder: assertion 'decoder' failed (lt-test-gst-io:12272): GStreamer-CRITICAL **: gst_bin_add: assertion 'GST_IS_ELEMENT (element)' failed ** (lt-test-gst-io:12272): WARNING **: cannot create convert or balance elements to disable rendering ** (lt-test-gst-io:12272): WARNING **: no suitable flipping element (lt-test-gst-io:12272): GLib-GObject-WARNING **: g_object_set_valist: object class 'GstBin' has no property named 'enable-last-sample' |
|
Trying to build openWebRTC on RaspberryPi but have this error: |
|
I have same error as stsdc ./cerbero-uninstalled -c config/linux.cbc fetch-package --full-reset --reset-rdeps openwebrtc I anybody can help to fix this or explain how to build ? |
Make OpenWebRTC run on Raspberry Pi. This is a placeholder for people interested (seems to be many :)). We have done some hacks but nothing that is yet ready to land as another supported platform.
The text was updated successfully, but these errors were encountered: