video pipeline caps negotiation problem

[Dan Taylor-2]

I have two pipelines, one of which negotiates caps correctly for me, and
one of which doesn't.

The analog TV pipeline comes back with a new "set caps" when I call
gst_pad_peer_accept_caps(),
but the digital pipeline doesn't.  In the following debug print clips,
you can see that set_caps()
is interleaved within my buffer_alloc(), because that's where I call
gst_pad_peer_accept_caps().

There is a video (and analog, not shown) backend that is identical for
both pipelines, and, of
course, I have had to handle the "sometimes" pads of the demuxer (and
audio decoder).  What does
NOT happen in the digital pipeline is the scaling that I want to occur,
so the image is too large
to be fully displayed.

The fbdevsink modifications are an in-progress attempt to make it more
friendly for embedded
systems, so it now has a buffer pool, "keep-aspect" handling, a bounding
box, and a few other
features.  There is still much to be done (rounding up the strides, for
example, which should
be breaking the analog, but doesn't ).

Does anyone have any ideas for why the gst_pad_peer_accept_caps() does
NOT trigger a set_caps()
in the digital pipeline?


VERSIONS:

gstreamer-0.10.22, gst-plugins-base-0.10.22, gst-plugins-good-0.10.14,
gst-plugins-bad-0.10.10,
gst-fluendo-mpegdemux-0.10.15


VIDEO BACKEND:

        gst_bin_add_many (GST_BIN (vbin), vqueue0, vscale, vfilter,
                          vqueue1, vcolor, vsink, NULL);

        vscale:     videoscale
        vfilter:    capsfilter
        vcolor:     ffmpegcolorspace
        vsink:      HIGHLY modified fbdevsink

ANALOG:

        gst_bin_add_many (GST_BIN (vbin), vsource, vqueue, vcrop,
vdelace, NULL);

        vsource:    v4l2src
        vcrop:      videocrop
        vdelace:    deinterlace2

        gst_bin_add_many (GST_BIN (video_pipeline), video_frontend,
video_backend, NULL);

gst_fbdevsink_buffer_alloc: requesting fit of 720x472 to 927x608 window
with original aspect ratio
gst_fbdevsink_buffer_alloc: peer pad accepts our desired caps; buffer
size is now 2254464 bytes
gst_fbdevsink_buffer_alloc: want buffer of size 2254464 (4,927,608)
gst_fbdevsink_buffer_alloc: buffer 0x80af6b8, fbdevsink 0x81580b0
gst_fbdevsink_set_caps: fbdevsink width 720, height 472
gst_fbdevsink_buffer_alloc: requesting fit of 720x472 to 927x608 window
with original aspect ratio
gst_fbdevsink_buffer_alloc: peer pad accepts our desired caps; buffer
size is now 2254464 bytes
gst_fbdevsink_set_caps: fbdevsink width 927, height 608
gst_fbdevsink_buffer_alloc: want buffer of size 2254464 (4,927,608)


DIGITAL:

        gst_bin_add_many (GST_BIN (digital_frontend), tsource, tqueue,
tdemux,
                          aqueue, adecode, vqueue, vdecode, NULL);

        tsource:    dvbsrc
        tdemux:     flutsdemux
        vdecode:    mpeg2dec

        gst_bin_add_many (GST_BIN (digital_pipeline), digital_frontend,
video_backend, audio_backend, NULL);

gst_fbdevsink_buffer_alloc: requesting fit of 1280x720 to 1080x608
window with original aspect ratio
gst_fbdevsink_buffer_alloc: peer pad accepts our desired caps; buffer
size is now 2626560 bytes
gst_fbdevsink_buffer_alloc: want buffer of size 2626560 (4,1080,608)
gst_fbdevsink_buffer_alloc: buffer 0x80af6b8, fbdevsink 0x816c050
gst_fbdevsink_set_caps: fbdevsink width 1280, height 720
gst_fbdevsink_buffer_alloc: requesting fit of 1280x720 to 1080x608
window with original aspect ratio
gst_fbdevsink_buffer_alloc: sending request for fit 1080x608
gst_fbdevsink_buffer_alloc: peer pad accepts our desired caps; buffer
size is now 2626560 bytes
gst_fbdevsink_buffer_alloc: requesting fit of 1280x720 to 1080x608
window with original aspect ratio
gst_fbdevsink_buffer_alloc: sending request for fit 1080x608
gst_fbdevsink_buffer_alloc: peer pad accepts our desired caps; buffer
size is now 2626560 bytes



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Fri, 2009-02-27 at 19:26 -0800, Dan Taylor wrote:
> gstreamer-0.10.22, gst-plugins-base-0.10.22, gst-plugins-good-0.10.14,
> gst-plugins-bad-0.10.10,
> gst-fluendo-mpegdemux-0.10.15

  For your information, the fluendo mpeg demuxers landed in -bad back in
September and have been maintained there since. So you can safely remove
gst-fluendo-mpegdemux. (Just replace flutsdemux by mpegtsdemux). They
also have more bugfixes in them (including maybe one for your
situation).

   Edward


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Dan Taylor-2]

 

> -----Original Message-----
> From: Edward Hervey [mailto:[hidden email]]
> Sent: Sunday, March 01, 2009 11:28 PM
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] video pipeline caps negotiation problem
>
> On Fri, 2009-02-27 at 19:26 -0800, Dan Taylor wrote:
> > gstreamer-0.10.22, gst-plugins-base-0.10.22,
> gst-plugins-good-0.10.14,
> > gst-plugins-bad-0.10.10,
> > gst-fluendo-mpegdemux-0.10.15
>
>   For your information, the fluendo mpeg demuxers landed in
> -bad back in
> September and have been maintained there since. So you can
> safely remove
> gst-fluendo-mpegdemux. (Just replace flutsdemux by mpegtsdemux). They
> also have more bugfixes in them (including maybe one for your
> situation).
>
>    Edward

I just tried it, and the symptom is exactly the same:  there is no
second set_caps, so every buffer request gets a successful
renegotiation, but the image is still too large for the display.

Anyone have another idea why the videoscale element is NOT taking
care of the scaling I need in digital, while it does so with analog?

Thanks,

Dan

>
>
> --------------------------------------------------------------
> ----------------
> Open Source Business Conference (OSBC), March 24-25, 2009,
> San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise
> -Strategies to boost innovation and cut costs with open
> source participation
> -Receive a $600 discount off the registration fee with the
> source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel