Created attachment 300660 [details] [review]
discoverer: fix GstToc leak when parsing toc messages

gst_message_parse_toc() returns a reffed GstToc which is owned by the
GstDiscovererInfo. But we have to make sure we unref its previous value before
setting the new one.

Review of attachment 300660 [details] [review]:

Looks correct but I wonder what we want to do in general when we get several ToC for the same stream.

Out of curiosity: with which file did you get multiple TOCs posted on the bus?

Thibault: I think just replacing the previous one should work fine in most cases in a discoverer context.

(In reply to Tim-Philipp Müller from comment #3)
> Out of curiosity: with which file did you get multiple TOCs posted on the
> bus?

gst-validate-launcher -t validate.file.media_check.Sintel_2010_720p_mkv

Seems there's nothing pending here about expected behavior when getting two ToCs so I pushed it:

commit d7d8fc5652ba8f99a90b8a8e17526f45d13e3f21
Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Date:   Tue Mar 31 13:26:21 2015 +0200

    discoverer: fix GstToc leak when parsing toc messages
    
    gst_message_parse_toc() returns a reffed GstToc which is owned by the
    GstDiscovererInfo. But we have to make sure we unref its previous value before
    setting the new one.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=747103

Yes indeed. I should also add that it's the exact same ToC here (posted once by audio/video sink each).