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

[Chuck Crisler]

You are a bit beyond my direct experience. However, it sounds like you
completely control the entire system, including the video source. That
means that you always know the capture parameters, including width and
height. So you could simply hard-code that or 'remember' the last value
before power-down. On the receiver you could create your own display window
of the appropriate size and (I think) pass the handle to a display
function. Either that or terminate the receiver pipeline with appsink (?)
and then handle the image display yourself in your window. Then, when
packets started coming in the display would use your window under your
control. Since you own/control the window, you could display any message
that you wanted to (language independent) and, with some work, suppress the
boot messages. Though suppressing the boot info won't be trivial.


On Tue, Mar 11, 2014 at 6:54 PM, Michael Tyson <michael at atastypixel.com>wrote:

> 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
>
>
>
> _______________________________________________
> 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/267b1725/attachment.html>