Maintaining patches for gstreamer

[GoogleCodeExporter]

Hi David,
I'm happy to see you comiting again ;)
I saw that I reverted your fix against gstsoup. It's actually pretty hard
to track all the changes we have in the gstreamer-related source files.
That's why we should keep those patches in a separated folder, at least as
a reminder for each upstream merge.

Original issue reported on code.google.com by ylatuya on 25 Nov 2009 at 9:12

[GoogleCodeExporter]

For instance your last update of gst-plugins-bad overrided the rank config for 
the
DirectShow decoder wrappers

Original comment by ylatuya on 25 Nov 2009 at 9:20

[GoogleCodeExporter]

Yeah, work finally let up a bit (IOW, we released our latest version) and so I 
finally 
have a bit more time.

I agree that the patches should be maintained in a separate folder. 
Unfortunately I 
made several patches to the source (especially in the gstreamer-sharp area) and 
didn't 
track the patches. The next time we update those sources, I'll generate a patch 
and 
maintain it.

Original comment by david.g.hoyt on 1 Dec 2009 at 7:37

[GoogleCodeExporter]

As for the DirectShow rank -- is there a reason we've diverged from the 
gstreamer 
folks? I thought I saw a bug report where this was discussed at length -- we 
should 
follow whatever they decided for consistency's sake. If we differ in opinion 
and it's 
been discussed and they still decided something different, we should go with 
their 
decision. If it hasn't been brought to their attention, we should submit a 
patch and 
have it discussed so it can be included in later versions.

That said, we're submitting all our changes/patches back to the gstreamer 
folks, right?

Original comment by david.g.hoyt on 1 Dec 2009 at 7:42

[GoogleCodeExporter]

I haven't tested it lately but the reason to not include the directshow decoder
wrapper, and add it afterwards with the lowest rank is because it was not 
decoding
mp3 audio streams while mad or ffmpeg were doing it. 
Also, the dshow wrapper should not be ranked PRIMARY when other "native" 
plugins are
available like for mp3 or xvid. 
Another reason for choosing ffmpeg as the first decoder option is because most 
of the
dshow codecs are wrapped to ffmpeg and this way we skip one level of wrapping 
which
should be faster. 
I have discussed that point on IRC and the reason they rank this decoder as 
PRIMARY
is because most of the windows builds do not include specific decoders nor 
ffmpeg.
We submit upstream all the patches, but in my opinion this is more like a
configuration option specific to our build

Original comment by ylatuya on 1 Dec 2009 at 2:47

[GoogleCodeExporter]

The GStreamer should still follow your recommendation, then -- there's not much 
harm 
in ranking things appropriately. If the Windows builds don't provide the 
"native" 
versions, then the ranking system should ensure that the dshow decoders 
eventually 
get selected, right?

Original comment by david.g.hoyt on 1 Dec 2009 at 7:36

[GoogleCodeExporter]

Closing this out...

Original comment by david.g.hoyt on 6 Feb 2010 at 9:05

• Changed state: Done