Skip to content

playbin: query allocation always sent twice

Submitted by Julien Isorce @cap

Link to original bug (#721400)

Description

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

Patch 265222, "videodecoder: add some debug about pool negotiation":
0001-videodecoder-add-some-debug-about-pool-negotiation.patch