GNOME Bugzilla – Bug 664750
[0.11] [gstmpeg4videoparse] src caps should not be fixed
Last modified: 2012-07-17 19:53:16 UTC
Created attachment 202082 [details] [review] Patch decodebin links elements with fixed srccaps immediately. This doesn't work for the parser as it needs to see data to determine real values for dimensions and framerate.
Comment on attachment 202082 [details] [review] Patch This patch is not correct, mpeg4videoparse will not set the width/height/framerate on all streams. This information is only present in some streams. What exactly is the problem you're trying to solve here? It shouldn't matter for decodebin2 if the template caps are fixed or not. The only difference is, that if the caps are fixed it will immediately continue linking downstream (i.e. an decoder) instead of waiting. This shouldn't cause any problems
Okay, this doesn't work. Once decodebin instantiates the mpeg4parser, the src caps are fixed so it doesn't bother pushing any data to it. That means when next element is linked, only template caps are taken into account. mpeg4videoparser template caps are video/mpeg, mpegversion=(int)4,systemstream=(boolean)false So autoplug-continue is called with caps video/mpeg, mpegversion=(int)4,systemstream=(boolean)false ffdec_mp4 has however template sink caps video/mpeg, mpegversion=(int)4,width=(int)[ 16, 4096 ],height=(int)[ 16, 4096 ],framerate=(fraction)[ 0/1, 2147483647/1 ] so when decodebin searches for plugin that than handle src caps from mp4videoparser it skips the ffmpeg. It goes like this: Autoplug continue: video/x-msvideo Autoplug continue: video/mpeg, mpegversion=(int)4, framerate=(fraction)5000000/208541, width=(int)640, height=(int)352 // This is from demuxer Autoplug continue: video/mpeg, mpegversion=(int)4, parsed=(boolean)true, systemstream=(boolean)false // This is from parser. No framerate, width or height as decodebin didn't push any data to it because of fixed caps When the parser doesn't have fixed caps everything works as it should: Autoplug continue: video/x-msvideo Autoplug continue: video/mpeg, mpegversion=(int)4, framerate=(fraction)5000000/208541, width=(int)640, height=(int)352 // demuer Autoplug continue: video/mpeg, mpegversion=(int)4, framerate=(fraction)65534/2733, width=(int)640, height=(int)352, systemstream=(boolean)false, parsed=(boolean)true, codec_data=(buffer)000001b0f5000001b50900000100000001200886c7fffb0aad8a02160a4c7f000001b25876694430303530, pixel-aspect-ratio=(fraction)1/1 // parser Now maybe the problem is not in the parser itself but in decodebin, but I thought the check for fixed caps is there for a reason.
I see, this is only with 0.11, right? Not with latest GIT (or releases) of 0.10? The pad caps compatibility checks changed there and are stricter (and more correct) now. IMHO at least the width/height should always be set inside the MPEG4 streams and thus be set on the output caps of mpeg4videoparse. Don't know about the framerate but it seems to be optional, which makes sense. Could you check if this is correct and prepare a patch that always sets width/height and adds width/height to the template caps? The second part would be ffdec_mpeg4 or in general the ffmpeg decoders. They really shouldn't require a framerate at all on the template caps and most of the probably shouldn't require width/height either.
Yes, this is only concerning 0.11. I'll do a patch for width/height only. I'm not sure about ffmpegdec. The caps do seem to require framerate, but there is a check in ffmpegdec_setcaps for absent framerate. However I think in that case it still expects framerate from decoder when there is no other way of calculating frame duration (perhaps a corner case?)
Created attachment 202153 [details] [review] Second take
Can't seem to be able to reproduce this with latest master.
> Can't seem to be able to reproduce this with latest master. Can be closed then, right? If not, please re-open.