| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Remove setting of parser variable to NULL after free,
that makes no sense (and coverity is no doubt going
to complain about it).
|
| |
|
| |
|
|
|
|
| |
This is just a bunch of lookup tables..
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also make clamp() a static function for the same reason and use CLAMP (as
defined by GLib) in the GStreamer code.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=757597
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize to 0 these parse structures before filling them: GstH264SEIMessage,
GstH264NalUnit, GstH264PPS, GstH264SPS and GstH264SliceHdr.
When calling the functions which fill those structures, they may fail, leaving
unitialized those structures. This situation may lead to future problems, such
as a segmentation fault when freeing, for example.
This patch initializes to zero these structures, before filling them.
https://bugzilla.gnome.org/show_bug.cgi?id=755161
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize to 0 these parse structures before filling them: GstH265SEIMessage,
GstH265NalUnit, GstH265VPS, GstH265PPS, GstH265SPS and GstH265SliceHdr.
When calling the functions which fill those structures, they may fail, leaving
unitialized those structures. This situation may lead to future problems, such
as a segmentation fault when freeing, for example.
This patch initializes to zero these structures, before filling them.
https://bugzilla.gnome.org/show_bug.cgi?id=755161
|
|
|
|
|
|
|
|
|
|
|
| |
If short_term_ref_pic_set_sps_flag is FALSE, the ShortTermRefPicSet
structure is supposed to derive from slice header. Which means,
CurrRpsIdx is equal to num_short_term_ref_pic_sets. But the number
of refpicsets communicated via sps header is only num_short_term_ref_pic_sets - 1.
And we are using slice_header structure to reference the last entry, which is
ShortTermRefPicSet[num_short_term_ref_pic_sets].
https://bugzilla.gnome.org/show_bug.cgi?id=754834
|
|
|
|
|
|
| |
Fix the default_scaling_list values based on Table 7-6
https://bugzilla.gnome.org/show_bug.cgi?id=754834
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section 6.5.1: Coding tree block raster and tile scanning conversion process
Follow the equations 6-3 and 6-4
This will provide correct offset_max in slice_header for parsing
num_entry_point_offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
|
|
|
|
|
|
|
|
| |
As per 7-42 and 7-43 the ScalingFactor's scanIdx is 0,
which is "up-right-diagonal" scan. Add APIs for converting
up-right-diagonal to raster and vise versa.
https://bugzilla.gnome.org/show_bug.cgi?id=754024
|
|
|
|
|
|
|
|
| |
Being more strict on specification, According to 7.4.7.3,
delta_chroma_log2_weight_denom should be in the range of
[(0 - luma_log2_weight_denom), (7 - luma_log2_weight_denom)]
https://bugzilla.gnome.org/show_bug.cgi?id=754024
|
|
|
|
|
|
|
|
|
|
|
| |
The SPS struct might be filled out by a call to
gst_h264_parser_parse_subset_sps, which fills out
dynamically allocated data and requires a call
to gst_h264_sps_clear() to free it. Also make sure
to clear out any allocated SPS data when returning
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=753306
|
|
|
|
|
|
|
|
|
|
|
| |
ChromaLog2WeightDenom = luma_log2_weight_denom + delta_chroma_log2_weight_denom
The value of ChromaLog2WeightDenom should be in the range of 0 to 7 and
the value luma_log2_weight_denom should be also in the range of 0 to 7.
Which means , delta_chroma_log2_weight_denom can have values in the range
between -7 and 7.
https://bugzilla.gnome.org/show_bug.cgi?id=753552
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753552
|
|
|
|
|
|
| |
Register more NAL unit types so that they are dumped
by name in the debug output instead of being labelled
'Invalid'
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=751778
|
|
|
|
| |
For bits that we don't parse out at the moment.
|
| |
|
|
|
|
| |
And sprinkle some more Since markers
|
|
|
|
|
|
|
| |
g_return_val_if_fail() and g_assert() are not appropriate
for checking untrusted external data.
https://bugzilla.gnome.org/show_bug.cgi?id=673925
|
|
|
|
|
|
|
|
|
|
|
| |
- add data pointer to GstJpegSegment and pass segment
to all parsing functions, rename accordingly
- shorten GstJpegMarkerCode enum type name to GstJpegMarker
- move function gtk-doc blurbs into .c file
- add since markers
- flesh out docs for SOF markers
https://bugzilla.gnome.org/show_bug.cgi?id=673925
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=673925
|
|
|
|
|
|
|
| |
Make this function private for now, since it's unclear whether
it's actually needed seeing that gst_jpeg_parse() scans too.
https://bugzilla.gnome.org/show_bug.cgi?id=673925
|
|
|
|
|
|
|
|
| |
Fix scan for next marker code when there is an odd number of filler
(0xff) bytes before the actual marker code. Also optimize the loop
to execute with fewer instructions (~10%).
This fixes parsing for Spectralfan.mov.
|
|
|
|
|
|
|
|
|
| |
The size of a marker segment is defined to be exclusive of any initial
marker code. So, fix the size for SOI, EOI and APPn segments but also
the size of any possible segment that is usually "reserved" or not
explicitly defined.
https://bugzilla.gnome.org/show_bug.cgi?id=707447
|
|
|
|
|
| |
Fix build_huffman_table() to correctly fill in the associated HUFFVAL
entries to the default Huffman tables.
|
|
|
|
|
|
| |
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=673925
|
|
|
|
|
|
| |
trivial patch to add proper ( while checking for if(G_UNLIKELY())
https://bugzilla.gnome.org/show_bug.cgi?id=751087
|
|
|
|
|
|
|
|
|
|
| |
Switch the increment of markersize from when it is used to when it is
returned from compute_resync_marker_size.
This also makes the CHECK_REMAINING in gst_mpeg4_parse_video_packet_header
check for the actually required number of bits now and not one too few.
https://bugzilla.gnome.org/show_bug.cgi?id=739345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 916b954315abc2f94348ec0be3e116c19b080b54.
Clearly something else was intended, and it also makes
more sense to add the extra bit. The resync marker is
N zero bits plus a 1 bit, and the pattern/mask needs to
be run on N+1 bits too.
(Even after the rever the code doesn't do that of course, so
it still needs to be fixed differently.)
https://bugzilla.gnome.org/show_bug.cgi?id=739345
|
|
|
|
|
|
|
|
|
| |
The EOS and EOB nals have the size 2 which is the size of
nal unit header itself. The gst_h265_parser_identify_nalu()
is not required to scan start code again in this case.
In other cases, for a valid nalunit the minimum required size
is 3 bytes (2 byte header and at least 1 byte RBSP payload)
|
| |
|
|
|
|
|
|
| |
An SEI Nal can have more than one SEI message.
Change in API: the gst_h265_parser_parse_sei()
|
|
|
|
|
|
|
| |
The possible minimum value for num_tile_columns_minus1 and num_tile_rows_minus1
is zero (7.4.3.3).
https://bugzilla.gnome.org/show_bug.cgi?id=748641
|
|
|
|
|
|
|
| |
Add utility functions to convert quantization matrices from zig-zag scan
order into raster scan order and vice-versa
https://bugzilla.gnome.org/show_bug.cgi?id=747613
|
|
|
|
|
|
|
|
| |
Skip the byte alignment bits as per the logic of byte_alignment()
provided in hevc specification. This will fix the calculation of
slice header size.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
|
|
|
|
|
|
|
| |
Always use the equation provided in spec (7-57) for finding
the NumDeltaPocs
https://bugzilla.gnome.org/show_bug.cgi?id=747613
|
|
|
|
|
|
| |
The NumPocToalCurr should be calculated for all B and P slices.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=747613
|
|
|
|
| |
This is not needed any longer.
|
|
|
|
| |
Someone's been commiting without using gst-indent :)
|
|
|
|
|
|
|
|
| |
READ_UE_ALLOWED was almost exclusively used with min == 0, which doesn't
make much point for unsigned integers.
Add a READ_UE_MAX variant and use that instead. Also replaced two usages
of CHECK_ALLOWED (a,0,something) by CHECK_ALLOWED_MAX (a, something)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that we do not trust the bitstream when filling a table
with a fixed max size.
Additionally, the code was not quite matching what the spec says:
- a value of 3 broke from the loop before adding an entry
- an unhandled value did not add an entry
The reference algorithm does these things differently (7.3.3.1
in ITU-T Rec. H.264 (05/2003)).
This plays (apparently correctly) the original repro file, with
no stack smashing.
Based on a patch and bug report by André Draszik <git@andred.net>
|
|
|
|
|
|
|
|
|
| |
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
"warning: comparison is always true due to limited
range of data type"
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=740673
|