Possible to 'prime' pipeline with frame size/etc?

[Michael Tyson]

Thanks for that Chuck.

Hmm, my apologies – that’s not quite what I’m after: Video transmission is working just fine, once connection is established. I'm just using the plugins that’re already bundled with GStreamer (rtph264pay, udpsink; udpsrc, rtph264depay), and they set up the formats quite adequately, and transfer video with acceptable latency of about 180 milliseconds, which is also important.

The scenario I’m trying to cater for is this:

Receiver station is fixed, powered by batteries.
Sender station is mobile, powered by batteries.
Both stations start powered down.

1. Attach receiver station to battery. Wait for boot, observe screen

This is where I’d like the receiver station to show a blank screen, ideally with the message “Waiting for video” or similar. At this point, the sender station is powered off - there’s no connectivity whatsoever. Note that without being able to prime the pipeline first, using eglglessink one is going to see the boot console until the first video frames arrive. I don’t really want that.

2. Attach sender station to battery. Boot, then sender automatically begins sending video to a multicast address.
3. Receiver gets video packets, starts displaying video.

Looking through the API docs, I’m not seeing anything that stands out, but I would imagine that there might be a way to send a signal to one of the parser/decoder/sink units to kick off the sink and get it to start displaying video frames. Failing that, there might be a way to initialise the pipeline with an intermediate video source that just displays a blank screen - appsrc, perhaps - and then detect the initialisation of the h264 decoder and swap sources to that once it’s ready.

Does that sound reasonable plausible with the API as it stands?

Thanks again,
Michael


On 12 Mar 2014, at 4:03 am, Chuck Crisler <ccrisler at mutualink.net> wrote:

> The easiest and quickest way in GStreamer is to setup an RTSP server. It can use any video stream, but only one way. It can easily support multiple clients receiving the same (or different) video streams from the server. If you want something more, you *COULD* have both systems running as an RTSP server and both running as a client. However, the best way would be to use some other outside signaling protocol such as SIP. SIP does not require a server or a registrar and you can make pt-pt calls with SIP. You exchange SDPs in the invite/response, which can contain the sprops-parameters that contain the info you want. But SIP is entirely outside of GStreamer. There are several open source SIP implementations. If you do this without a SIP server that everyone registers with, you will have to provide some way for endpoints to know the destination (IP address) of the target. There are other out of band protocols also, such as H323. This will require a moderate amount of work.
> 
> 
> On Mon, Mar 10, 2014 at 6:35 PM, Michael Tyson <michael at tyson.id.au> wrote:
> That’s great news! Thanks, Chuck.
> 
> It’s pretty much one-sender-one-receiver, although I’d like to keep the option of one-sender-multiple-receivers open. It’s entirely local-network, with prearranged multicast address, port and protocol. 
> 
> I’d imagine at launch priming the rx pipeline with the frame size/rate it expects to receive from the other end, which will hopefully facilitate showing some kind of display until the actual video arrives. Just to consider a simple case, where these are hard-coded, are you able to point me at the appropriate API bits to accomplish that?
> 
> Cheers!
> 
> On 11 Mar 2014, at 12:48 am, Chuck Crisler <ccrisler at mutualink.net> wrote:
> 
>> Sure. You use out of band signaling, something like SIP or RTSP. It really depends on your application - what you are trying to do, single system to many? One to one? Endpoints registered to a server? How do you know the addresses and ports and protocols? The sender could include the sprop_parameters in that communication.
>> 
>> 
>> On Mon, Mar 10, 2014 at 5:49 AM, Michael Tyson <michael at tyson.id.au> wrote:
>> Hello!
>> 
>> I’m putting together a realtime video monitoring application with a cairo overlay, in C.
>> 
>> Until the first RTP video packets arrive, there’s no visual - the pipeline’s got no video format information, so it’s waiting to receive the first frames.
>> 
>> I’d ideally like to display a blank screen, but primed with the expected screen resolution, ideally with something like a “waiting for video” caption. Is something like this at all possible with GStreamer?
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> 
>> 
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140312/4bca6743/attachment.html>