Caps Negotiation Confusion.

Stirling Westrup swestrup at gmail.com
Mon Jan 28 13:20:39 PST 2013


Okay, here's some more info. I'm working on a project to display video
content on a video wall made up of a rectangular array of monitors.
Right now it works fine if I just play video files, but my boss would
like me to be able to show live content as well, such as a video
camera feed, or a capture from an X session. This latter is what I
chose to implement first, and its what I'm now trying to debug. To
simplify the tests, this example just reads from a single source and
outputs it to a single monitor, but the program is intended to be able
to handle multiple video and audio channels and to dynamically
reconfigure things while a source is playing, hence the complexity of
the pipeline.

Alas I cannot just upload my code to a public forum as this thing will
eventually be commercial. However I can upload selected portions if
need be.

In the meantime, here's a pair of .png graphs. One from launch showing
what shape I expect the pipeline to be in, and one from my program
(named 'vaal') showing the actual state of things once I enter the
PAUSED state.

https://docs.google.com/file/d/0BwCOnjTaGreOOHlUVW5WcEQtelU/edit
https://docs.google.com/file/d/0BwCOnjTaGreOZWVnbElzOEtxYmM/edit

And finally, here's a full-blown debug trace of me running the program
and it getting all the way into the playing state without actually
ever delivering any data to the output screen:

https://docs.google.com/file/d/0BwCOnjTaGreOTFRUUGhESGtZZE0/edit

On Mon, Jan 28, 2013 at 1:31 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> On Mon, 2013-01-28 at 11:41 -0500, Stirling Westrup wrote:
>
>> Right now I have an interesting problem in that caps negotiation is
>> not completing in my pipeline. This has to be a side effect of
>> dynamically building the pipeline in stages as caps negotiation
>> completes and gives the expected results if I build and run an exact
>> copy of the pipeline via gst-launch.
>>
>> For background, my pipeline can either run in pull or push mode. It
>> runs in pull mode when I supply a file video source, and in push mode
>> when I supply a live video source (like an X session capture).
>>
>> In pull mode, everything works fine. In push mode, the pipeline
>> successfully gets into the PAUSED state and a gst_pad_query_caps of
>> source pad at the end of the video processing chain returns a fixed
>> set of caps, as I would hope. However a call to
>> gst_pad_get_current_caps at that same location always returns ANY. A
>> dot-dump of the pipeline at that point shows that essentially no
>> negotiation has taken place, at all.
>>
>> I can't figure out what I need to do to ensure the pipeline completes
>> negotiation.
>
> It would be easier to help with some more information, such as:
>
>  - pipeline
>  - code
>  - png graph
>
> Otherwise one can just say: check backwards which pads get negotiated
> and not, somewhere a caps event (1.0) or buffer (0.10) must not have
> gone through.
>
>  Cheers
>   -Tim
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup


More information about the gstreamer-devel mailing list