After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655223 - [x264enc] properly handle stream-format from caps
[x264enc] properly handle stream-format from caps
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
git master
Other All
: Normal normal
: 0.10.19
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2011-07-24 20:22 UTC by Christian Fredrik Kalager Schaller
Modified: 2011-08-01 13:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

dotfile dump showing issue (610.41 KB, image/png)
2011-07-24 20:22 UTC, Christian Fredrik Kalager Schaller
x264enc: Properly set the stream format in setcaps (2.22 KB, patch)
2011-07-30 22:31 UTC, Thiago Sousa Santos
committed Details | Review

Description Christian Fredrik Kalager Schaller 2011-07-24 20:22:27 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.
Comment 1 Thiago Sousa Santos 2011-07-25 03:30:41 UTC
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:
Comment 2 Christian Fredrik Kalager Schaller 2011-07-25 06:46:43 UTC
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.
Comment 3 Christian Fredrik Kalager Schaller 2011-07-25 06:52:11 UTC
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.
Comment 4 Alessandro Decina 2011-07-25 07:33:46 UTC
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 */
Comment 5 Sebastian Dröge (slomo) 2011-07-25 07:40:41 UTC
(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
Comment 6 Thiago Sousa Santos 2011-07-25 11:54:32 UTC
Patches in should help here.
Comment 7 Christian Fredrik Kalager Schaller 2011-07-26 10:59:49 UTC
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.
Comment 8 Christian Fredrik Kalager Schaller 2011-07-26 13:10:32 UTC
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.
Comment 9 Thiago Sousa Santos 2011-07-30 16:37:54 UTC
Are you using transmaggedon to reproduce this? Or using a custom application?
Comment 10 Thiago Sousa Santos 2011-07-30 22:31:59 UTC
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
Comment 11 Christian Fredrik Kalager Schaller 2011-07-31 08:34:52 UTC
Yes, I am using Transmageddon to reproduce this and this patch fixes the issue. Thanks!
Comment 12 Thiago Sousa Santos 2011-07-31 17:16:40 UTC
commit 19f1c38d4ea16c8c199a1b4cd8d21beef3a70b6c
Author: Thiago Santos <>
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