[Bug 793551] vc1parse: parsing issues with vc1 streams encoded in non-WMV containers

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sun Feb 18 00:29:24 UTC 2018


https://bugzilla.gnome.org/show_bug.cgi?id=793551

--- Comment #3 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Ok, found it. So this has nothing to do with Matroska, it has to do with your
broken encoder/muxer. Clearly you are setting a codec data defined as per the
"A.5 VC-1 stream headers in CodecPrivateData". Matroska does not redefine this.
This byte is defined by "A.6 ASF binding byte for Advanced Profile in ASF
CodecPrivateData."

According to the spec, the least significant bit is reserved and should always
be 1. So this CODEC data is a violation of the spec. For the rest, if we
consider the rest, we have:

  Bit 1 = 0 :: b frame might be present
  Bit 2 = 1 :: there no slice
  Bit 3 = 0 :: multiple entry headers might be present
  Bit 4 = 0 :: multiple sequence headers might be present
  Bit 5 = 1 :: there is no interlaced frames
  Bit 6 = 0 :: reserved no default
  Bit 7 = 0 :: reserved no default

Now, if FFMPEG accepts it, I think we should also do. So I'll relax the
validation a bit. It will still be safe really. The remaining question is if
it's vc1parser job to actually fix it. This way, we don't maintain this bug in
transmuxing. It's a very minor issue in the bitstream to be honest.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list