[Bug 704769] Make libav codecs handle gracefully renegotiation.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=704769
  GStreamer | gst-libav | git

--- Comment #7 from Mathieu Duponchelle <mathieu.duponchelle at epitech.eu> 2013-07-25 08:57:41 UTC ---
Hm quite difficult to explain, I guess I'm better off first explaining the
sequence of events that leads to the bug.

1) on PAUSED, gnl_source_prepare is called, a its src pad is blocked with
GST_PAD_PROBE_BLOCK_DOWNSTREAM and an initial seek created but not sent yet.

2) when the first buffer is asked for to the decoder in alloc_output_buffer, as
it didn't do its negotiation yet it calls gst_video_decoder_negotiate.

3) negotiate calls set_caps, there are stickied events on the pad (stream-start
being the first)

4) the event is received in the source's probe callback, which triggers the
creation of a thread to send the stored seek event, which executes nearly
immediately.

5) the pad is now flushing, and the bufferpool negotiation which was to happen
next in gst_video_decoder_negotiate_default fails.

6) the process goes on in gst-libav, eventually leading to the field "linesize"
in a context implemented by libav to be set to certain values.

7) the bufferpool is finally negotiated, an alignment is set but for some
reason that context is not updated.

8) the allocation of new frames in libav starts failing with the messages I
mentioned.

I've found it quite challenging to understand how that context, which is
private to libav, is supposed to be updated. I'm certain Edward will know
better than I.

OK so that's the definition of the problem, now to the problem with my patch.

I can't wait for a specific event in that probe callback as it's blocking, and
if I ignore the stream-start well I don't get anything next.

Now if I decide to set the probe callback to not blocking, ie let the events
flow until I get caps, my problem is now that I'm gonna end up getting a
segment from the source with a stop at -1, I guess because as it has not been
seeked the driving element must be deciding to send a "default" segment. If I
drop this segment I still have a problem, because I get data flow without
segment.

I guess I could workaround all that but as I said I think it would be a pile of
hacks, not sure we want to do that.

May'be there's a better solution but I fail to see it, I also don't really want
to break something in the process.

I've spent a lot of time on this issue, and I'm a little disappointed not to
have found the correct fix in libav, but well I suppose it has to happen
sometimes :)

So I also am gonna end up by :

Edward ?

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