GNOME Bugzilla – Bug 608167
[decodebin2] Doesn't push out full topology
Last modified: 2010-01-26 17:58:58 UTC
Created attachment 152319 [details] [review] read all caps I'll take a simple example, but this behaviour happens with many other cases, mostly those when a parser is being used. When taking a simple mp3 file (i.e. not surrounded with id3), the resulting topology isn't complete. We end up with "typefind ! mp3parse ! mad" being plugged in internally. One would expect the stream topology to contain: * the upstream caps (i.e. the caps from typefind.src) * the caps between mp3parse and mad * the final caps from mad (from its source pad) Right now the resulting topology structure contains: * the upstream caps (audio/mpeg, mpegversion=(int)1, layer=(int)3) * the final caps (audio/x-raw-int, endianness=(int)1234, channels=(int)2, width=(int)16, dept....) The problem is that this information isn't complete, it's missing the caps between mp3parse and mad, which contain quite a bit more information like this: audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)2, layer=(int)3, rate=(int)22050, channels=(int)2, parsed=(boolean)true For some reason, the code writing the topology structure misses out the caps between mp3parse and mad, the attached patch fixes that issue.
Ideally the topology code should figure out that two caps are compatible (like the final and middle caps from above), and only give the intersected caps.
Comment on attachment 152319 [details] [review] read all caps Feel free to push this. Code path isn't active by default afaict, so should be low risk.
commit c60f94da58a6bc3b61f991a3f9519fef1666bba6 Author: Edward Hervey <bilboed@bilboed.com> Date: Tue Jan 26 16:47:40 2010 +0100 decodebin2: Don't skip an element when getting the topology Fixes #608167