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

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #1 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Interestingly, you can replace vc1parse with avdec_vc1 and it decodes it.
Looking at that decoder, it seems to pretty much ignore the codec_data
(extradata). So it seems a little redundant somehow.

Meanwhile, looking at the generated data, with my very limited knowledge of VC1
headers forma you can see that the code_data from matroska starts with:

  240000010f...

So 1 byte set to 0x24, followed by a start code with 0x0F, VC1_SEQUENCE. And
later one we can see another startcode with 0x0E, VC1_ENTRYPOINT. So the only
thing that blocks the parser is that is currently expect the two first bytes to
be 0x01, which can be demonstrated with the following pipeline:

  gst-launch-1.0 -v filesrc location=hddvd_demo_1080p.mkv ! matroskademux !
capssetter
caps=video/x-wmv,codec_data=\(buffer\)010000010fdbfe3bf21bca3bf886f180ca02020309a5b8d707fc0000010e5ac7fcefc86c40
! vc1parse ! fakesink

If someone can point me to what defines these numbers, 0x01 and 0x24, writing a
patch to supports this (or fixing matroskademux maybe ?) seems rather trivial.

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