[Bug 721400] New: playbin: query allocation always sent twice

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=721400
  GStreamer | gst-plugins-base | git

           Summary: playbin: query allocation always sent twice
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: julien.isorce at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=265222)
 View: https://bugzilla.gnome.org/attachment.cgi?id=265222
 Review: https://bugzilla.gnome.org/review?bug=721400&attachment=265222

videodecoder: add some debug about pool negotiation

* steps to reproduce:
GST_DEBUG=*videodecoder*:5,2  gst-launch-1.0 playbin
uri=http://clips.vorwaerts-gmbh.de/big_buck_bunny.mp4


* actual result:
2 allocation queries. During the second one, the decoder decides the same pool
instance as previously and fails to set the config because already active. 
But the caps didn't changed so no really a big problem.
Also at the end it inactivate it and then reactivate the same pool.
This is just weird and not optimal.

Maybe the decoder should call "gst_video_decoder_reset (decoder, TRUE, TRUE);"
before to send the query again, just like when going from paused to ready
state.

Another solution would be to also call "gst_pad_check_reconfigure
(decoder->srcpad);" in "done" label of "gst_video_decoder_negotiate_pool".
After all if the first negotiate succeded, why not clear the reconfigure flag.

What do you think ? :)


* log with the attached patch that add debug and GST_DEBUG=*videodecoder*:5,2 :
0:00:00.073061995 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3122:gst_video_decoder_negotiate_pool:<avdec_h264-0> about to
query allocation
0:00:00.146459932 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3080:gst_video_decoder_decide_allocation_default:<avdec_h264-0>
setting config <xvimagebufferpool0>
0:00:00.146623625 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3132:gst_video_decoder_negotiate_pool:<avdec_h264-0>
ALLOCATION (1) params: allocation query
0:00:00.187834955 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3122:gst_video_decoder_negotiate_pool:<avdec_h264-0> about to
query allocation
0:00:00.188163056 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3080:gst_video_decoder_decide_allocation_default:<avdec_h264-0>
setting config <xvimagebufferpool0>
0:00:00.188183331 31870      0x1b356d0 WARN              bufferpool
gstbufferpool.c:632:gst_buffer_pool_set_config:<xvimagebufferpool0> can't
change config, we are active
0:00:00.188215961 31870      0x1b356d0 WARN              bufferpool
gstbufferpool.c:632:gst_buffer_pool_set_config:<xvimagebufferpool0> can't
change config, we are active
0:00:00.188225047 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3132:gst_video_decoder_negotiate_pool:<avdec_h264-0>
ALLOCATION (1) params: allocation query
0:00:00.188289928 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3162:gst_video_decoder_negotiate_pool:<avdec_h264-0>
inactivate pool <xvimagebufferpool0>
0:00:00.189572092 31870      0x1b356d0 DEBUG           videodecoder
gstvideodecoder.c:3169:gst_video_decoder_negotiate_pool:<avdec_h264-0> activate
pool <xvimagebufferpool0>

* other infos:
(In reply to comment #15 of https://bugzilla.gnome.org/show_bug.cgi?id=720597)
> I think it's correct that
> another ALLOCATION query happens if one happened before and then things are
> relinked (e.g. because decodebin exposes the pads, or because it continues
> autoplugging). Doing two ALLOCATION queries just because and if nothing has
> changed is not ideal though, but is this happening here?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.