In the sink event handler we end up sending multiple EOS
events per pad. Don't return FALSE when sending the
second EOS on an already-EOS pad fails. Not sure if there
was a reason for sending a second EOS, so leaving the
code in there for now, but assume all went fine if there
are source pads, which is slightly less wrong than before.
This function needs work.
that don't include pthread.h any more from public headers.
We could just fix this by including pthread.h ourselves,
but we may just as well use atomic ops for this and
simplify the code a little.
https://bugzilla.gnome.org/show_bug.cgi?id=693322
Add utility functions to convert quantization matrices from zigzag scan
order (as encoded in the bitstream) into raster scan order. Also provide
another function to reverse the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=693000
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Quantizer matrices are encoded in zigzag scan order in the bitstream,
but they are stored in raster scan order when they are parsed. However,
default matrices were also prepared in zigzag scan order, hence the
mismatch. i.e. the matrices were presented either in raster scan order
if they are explicitly present in the bitstream, or they were presented
in zigzag scan order if the default definitions were to be used instead.
One way to solve this problem is to always expose the quantization
matrices in zigzag scan order, since this is the role of the parser to
not build up stories from the source bitstream and just present what
is in there.
Utility functions will be provided to convert quantization matrices in
either scan order.
https://bugzilla.gnome.org/show_bug.cgi?id=693000
Signed-off-by: Cong Zhong <congx.zhong@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Make sure pkg-config in gst-libs/gst/insertbin/ can find
the uninstalled core/base properly. Fixes build of
insertbin in uninstalled setup if there arn't any
installed gir files to fall back to.
Fix parsing of residual bytes. This is a two-step process. First,
remaining colums of full vertical resolution (<height>) need to be
processed. Next, remaining bytes in the first row can be processed,
while taking into account the fact that we may have filled in the
first columns already. So, this is not full horizontal resolution.
The following figure helps in understanding the expected order of
operations, for a 8x5 MBs bitplane.
5 5 6 6 6 6 6 6
5 5 1 1 1 2 2 2
5 5 1 1 1 2 2 2
5 5 3 3 3 4 4 4
5 5 3 3 3 4 4 4
So, after tiles 1 to 4 are decoded, vertical tile 5 needs to be
processed (2x5 MBs) and then the horizontal tile 6 (6x1 MBs).
https://bugzilla.gnome.org/show_bug.cgi?id=692461
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix decoding of DIFF6 or NORM6 bitplanes with an odd number of lines
(3x2 "horizontal" tiles). In this case, we have to skip the first line
of macroblocks but <width> number of bytes was used to do so, instead
of the actual <stride> size.
This fixes decoding for the video sample attached to:
https://bugzilla.gnome.org/show_bug.cgi?id=668565https://bugzilla.gnome.org/show_bug.cgi?id=692461
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add gst_vc1_parse_slice_header() function to parse slice headers as
described in 7.1.2. Slice layers are optional and allowed in advanced
profile mode only. Picture header, if available (PIC_HEADER_FLAG),
is parsed but not recorded because it shall be the same as that was
previously parsed with gst_vc1_parse_frame_header().
This fixes SA00049.vc1 conformance test.
https://bugzilla.gnome.org/show_bug.cgi?id=692388
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Fix decoding of DIFF2 or NORM2 bitplanes with an odd number of macroblocks.
In particular, account for the first bit that was already parsed so that to
avoid a buffer overflow after all pairs are parsed.
This fixes SA00040.vc1 conformance test.
https://bugzilla.gnome.org/show_bug.cgi?id=692312
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
