[Bug 697672] VP8 passed through rtpbin decodes a single frame and then fails to decode until a key frame passed through

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=697672
  GStreamer | gst-plugins-bad | 1.0.5

--- Comment #6 from tcdgreenwood at hotmail.com 2013-04-10 13:00:49 UTC ---
I think what is happening is that caps are set correctly on the startup of the
pipeline, and when the rtpbin get's it's recv_rtp_src_0_XXXX_XXX pad added. 
This gets to the point where rtpvp8depay logs "Set caps" and marks discont on
the stream - since this is before the first packets it's perfectly happy it
throws away nothing since nothing has gone through.  A little bit later there
is another caps event passing which clears the payload type map and hence
causes caps events on rtpvp8depay and vp8dec - killing both.

For H.264 this works I believe partially by some sensible code and partially by
a mechanism I don't understand (or perhaps sheer luck).  The gstavviddec.c:415
checks if caps events actually change caps and so the video codec doesn't
re-start - this is sensible.  It seems that the rtph264depay element receives
the caps event just after it's pushed the buffer it was working on so the
discontinuity doesn't lead it to clear part of the packet.

Possible fixes:
1. Stop the second caps event - not sure how
2. Stop the rtp depayloader's and video codec's from resetting when the caps
don't actually change
3. Stop gstrtpptdemux.c from sending downstream caps events or clearing it's
payload type map when it get's upstream caps.  Presumably if the application
actually wants to change the payload type to caps mapping it will use the
clear-pt-map signal anyway

I propose that 2 and 3 could be done regardless at least from the point of view
that restarting codecs etc is a bad thing and should be avoided if possible.  I
really have no clue why the second caps event happens - perhaps someone could
tell me (I'd be glad to learn).

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