Caps Negotiation Confusion.

[Stirling Westrup]

... and just like that, the whole thing started working. Still not
quite sure why...

On Tue, Jan 29, 2013 at 3:54 PM, Stirling Westrup <swestrup at gmail.com> wrote:
> Even more info: If I run my pipeline under valgrind's helgrind tool,
> it works. I do get a bunch of errors reported by helgrind though. I'm
> hoping one or more of them will shed some light on things.
>
> On Tue, Jan 29, 2013 at 2:05 PM, Stirling Westrup <swestrup at gmail.com> wrote:
>> Reading through the above log, I am more confused than ever. As far as
>> I can tell, full caps negotiation does take place (although it happens
>> far later than I expected) and all the elements *seem* to accept the
>> caps event they get (I say seems because I'm not 100% sure what all
>> the debug statements actually mean).
>>
>> However my graph dump once in the playing state still doesn't show
>> correctly negotiated caps. I don't get it.
>>
>>
>> On Mon, Jan 28, 2013 at 4:20 PM, Stirling Westrup <swestrup at gmail.com> wrote:
>>> 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
>>
>>
>>
>> --
>> 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
>
>
>
> --
> 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



-- 
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