No subject

  /* 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 */

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.