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>
