GNOME Bugzilla – Bug 655223
[x264enc] properly handle stream-format from caps
Last modified: 2011-08-01 13:30:14 UTC
Created attachment 192578 [details] dotfile dump showing issue It seems x264enc by default output video in stream-format=avc, while avimux demand stream format 'byte-stream'. As attached png shows, this causes encodebin to fail to mux a stream.
Didn't the recent patches by Olivier and another one by me fixed this? Are you using git version? The bug with the patches is: https://bugzilla.gnome.org/show_bug.cgi?id=644233
I have got of core, base and bad, will make sure also Ugly is up-to-date. But I think the patches are the reason for this issue, not the solution. Because even creating a pad on encodebin for h264 only works if stream format is byte-stream, which means it is impossible to remux a h264 stream set to 'avc'. So I am quite convinced this is a encodebin issue caused by adding stream-format to h264 caps.
Ok, just tested with everything up-to-date, the issue is not solved with latest git versions of everything. Encodebin simply does not seem to want to deal with anything which has stream format set to 'avc', so it needs to be fixed be able to use it as a valid format and plug the h264 parser as needed.
The code that plugs parsers is still commented out in encodebin. From the code: /* FIXME : * * The usage of parsers in encoding/muxing scenarios is * just too undefined to just use as-is. * * Take the use-case where you want to re-mux a stream of type * "my/media". You create a StreamEncodingProfile with that type * as the target (as-is). And you use decodebin2/uridecodebin * upstream. * * * demuxer exposes "my/media" * * a parser is available for "my/media" which has a source pad * caps of "my/media,parsed=True" * * decodebin2/uridecodebin exposes a new pad with the parsed caps * * You request a new stream from encodebin, which will match the * streamprofile and creates a group (i.e. going through this method) * There is a matching parser (the same used in the decoder) whose * source pad caps intersects with the stream profile caps, you * therefore use it... * * ... but that parser has a "my/media,parsed=False" sink pad caps * * ... and you can't link your decodebin pad to encodebin. * * In the end, it comes down to parsers only taking into account the * decoding use-cases. * * One way to solve that might be to : * * Make parsers sink pad caps be "framed={False,True}" and the * source pad caps be "framed=True" * * Modify decodebin2 accordingly to avoid looping and chaining * an infinite number of parsers * * Another way would be to have "well-known" caps properties to specify * whether a stream has been parsed or not. * * currently we fail. aacparse uses 'framed' and mp3parse uses 'parsed' */ /* FIXME : Re-enable once parser situation is un-$#*@(%$#ed */
(In reply to comment #4) > * One way to solve that might be to : > * * Make parsers sink pad caps be "framed={False,True}" and the > * source pad caps be "framed=True" > * * Modify decodebin2 accordingly to avoid looping and chaining > * an infinite number of parsers That's fixed now in decodebin2 since a few releases and in decodebin with latest GIT. parsers only need to be changed to accept framed/parsed input now
Patches in https://bugzilla.gnome.org/show_bug.cgi?id=650652 should help here.
Just tried applying the updated patches from 650652, the pipeline still fails with the exact same problem that is shown in the attached dotfile dump png, x264enc outputs AVC, while avimux wants byte-stream, no parser plugged.
Just struck me, I guess the reason Thiagos patches had no effect is that while they enable the plugging of parsers in encodebin for parsed/non-parsed content, the issue here is that the stream-format needs changing.And since there was no format which had format settings in the caps at the time of the writing of encodebin I would assume the case is simply not handled. That said, in this specific bug it actually seems like x264enc is outputing the wrong stream format instead of the one avimux demands, so somehow that information from avimux doesn't reach x264enc.So of course plugging a parser would solve it (and some of the other bugs I filled), a better fix for this specific bug would of course be that x264 realized that avimux wants byte-stream and not avc and thus outputs that.
Are you using transmaggedon to reproduce this? Or using a custom application?
Created attachment 192927 [details] [review] x264enc: Properly set the stream format in setcaps Patch to fix x264enc to properly use the stream format from downstream caps
Yes, I am using Transmageddon to reproduce this and this patch fixes the issue. Thanks!
commit 19f1c38d4ea16c8c199a1b4cd8d21beef3a70b6c Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Sat Jul 30 18:47:44 2011 -0300 x264enc: Properly set the stream format in setcaps Do not forget to set the selected format to the options string when getting it from caps https://bugzilla.gnome.org/show_bug.cgi?id=655223