Created attachment 389222 [details, diff] patch for libav plugin While either of of the plugins is built against no-longer-that recent version of ffmpeg, Something Bad Happens, though it's hard to tell how bad it really is. I've described the problem in the upstream bug, but given the upstream builds against libav, they seem to not really care that much.
I can't find the patch for -ffmpeg plugin, even though I'm nearly certain I've wrote one back at that time... Then again, it was almost the same, the differences came only from the code changes in the plugin (mostly in the last chunk). It didn't get into upstream bugzilla, due to the status of 0.10 branch.
...and rereading the upstream bug, I've noticed I didn't described the symptoms, just the problem. The symptoms were that during a first run after gstreamer upgrade, at automatic plugin cache refresh, a few vague warnings were printed and the resulting cache had not quite correct content.
Created attachment 389234 [details, diff] patch for ffmpeg plugin After digging a bit deeper, I've found the other patch after all.
this is obsolete now with latest versions in the tree
...why am I not surprised, yet another bug closed without being really fixed... Could you point me to the gst-libav commit that has fixed it ? Also, to your backport in 0.10. As of media-libs/ffmpeg-2.6.1, 'stream_segment,ssegment' is still present among muxers, so the problem is still valid.
Created attachment 404532 [details] trivial program listing formats This piece of code lists both muxers and demuxers. Link with libavformat.
Created attachment 404534 [details] slight correction of previous code (output not affected)
(In reply to Rafał Mużyło from comment #5) > ...why am I not surprised, yet another bug closed without being really > fixed... > Please stay away from making assumptions like this, the problem is that I misunderstood what this bug was about... but it's not a "general policy" to close bugs without being fixed as you blame
If you could reply to https://bugzilla.gnome.org/show_bug.cgi?id=734451#c3 maybe there are more chances to get it fixed finally in upstream too :) Thanks
(In reply to Pacho Ramos from comment #8) > (In reply to Rafał Mużyło from comment #5) > > ...why am I not surprised, yet another bug closed without being really > > fixed... > > > > Please stay away from making assumptions like this, the problem is that I > misunderstood what this bug was about... but it's not a "general policy" to > close bugs without being fixed as you blame As the things stand, my plans are to hold both herds (gstreamer *and* gnome) in contempt until 3 months after a certain gtk-doc bug will get a proper fix. As for the upstream bug, I kind of ignored that comment, as ...really...the technical side already has a correct solution, the only thing remaining is bikeshedding where exactly put the fix - it's their code, they should know that better than I do.
Maybe the way to go is to finally try to jump the gap, become a dev and finally help fixing things directly instead of pushing us constantly to get it done (we are not only maintaining one or two packages, they are a ton and in various areas, and we cannot be forced to fix things at the rate you want and to accept all your complaints and rants)
@comment 11: Once again, I wouldn't be complaining about this that much, if not for the two things: - time that passed since I've mentioned this problem (close to a year since multilib gstreamer, still several months since gstreamer 1.4.0 release) - the fact, that this wouldn't be a problem in the first place, as it only became a problem with gstreamer multilib and I informed the author of the conversion while he was converting
It looks like upstream solved it and committed the fix for their development version (1.7), then, if they don't get any regression or problem with that change, it should be finally solved in 1.8
1.8 in the tree
