summaryrefslogtreecommitdiff
path: root/gst-libs/gst/codecparsers
Commit message (Collapse)AuthorAgeFilesLines
* codecparsers: vp9: minor clean-upTim-Philipp Müller2015-12-301-2/+1
| | | | | | Remove setting of parser variable to NULL after free, that makes no sense (and coverity is no doubt going to complain about it).
* codecparsers: vp9: fix macro namespacing and rename GstVp9InterpFilterTim-Philipp Müller2015-12-302-21/+21
|
* codecparsers: vp9: fix doc typos and sprinkle some Since markersTim-Philipp Müller2015-12-302-22/+56
|
* codecparsers: vp9: move license blurb into header and remove aux filesTim-Philipp Müller2015-12-306-164/+59
| | | | This is just a bunch of lookup tables..
* codecparsers: Add another G_GNUC_INTERNALSebastian Dröge2015-12-301-0/+1
|
* codecparsers: Spread some G_GNUC_INTERNAL in various placesSebastian Dröge2015-12-305-6/+33
|
* vp9parser: Fix indentation to make gst-indent happierSebastian Dröge2015-12-301-182/+185
|
* vp9parser: Rename symbols to prevent symbol conflictsSebastian Dröge2015-12-304-17/+15
| | | | | Also make clamp() a static function for the same reason and use CLAMP (as defined by GLib) in the GStreamer code.
* codecparsers: Add VP9 codec parserSreerenj Balachandran2015-12-308-3/+1726
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=757597
* codecparser: h264: initialize parsing structuresVíctor Manuel Jáquez Leal2015-10-291-43/+13
| | | | | | | | | | | | | 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
* codecparser: h265: initialize parsing structuresVíctor Manuel Jáquez Leal2015-10-291-106/+14
| | | | | | | | | | | | | 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
* codecparsers: h265: Fix the selection of Active Ref Pic SetSreerenj Balachandran2015-09-101-4/+3
| | | | | | | | | | | 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
* codecparsers: h265 : Fix default scaling list valuesSreerenj Balachandran2015-09-101-2/+2
| | | | | | Fix the default_scaling_list values based on Table 7-6 https://bugzilla.gnome.org/show_bug.cgi?id=754834
* codecparsers: h265: Fix tile row and column parsingXuGuangxin2015-08-262-18/+43
| | | | | | | | | | | | 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>
* codecparsers: h265: Add APIs for up-right-diagonal/raster scan conversionlyb2015-08-242-0/+141
| | | | | | | | 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
* codecparsers: h265: Fix the range of delta_chroma_log2_weight_denomXuGuangxin2015-08-241-2/+4
| | | | | | | | 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
* h264parse: Clear SPS info after processing.Jan Schmidt2015-08-151-1/+4
| | | | | | | | | | | 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
* codecparsers: h265: Fix the range of delta_chroma_log2_weight_denomSreerenj Balachandran2015-08-121-1/+1
| | | | | | | | | | | 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
* codecparsers: h265: Fix the parsing of ref_pic_lists_modificationSreerenj Balachandran2015-08-121-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=753552
* h264parse: Add more NAL types for debugging output.Jan Schmidt2015-07-291-2/+6
| | | | | | Register more NAL unit types so that they are dumped by name in the debug output instead of being labelled 'Invalid'
* mpegvideometa: add meta transform functionHyunjun Ko2015-07-071-1/+33
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=751778
* codecparsers: jpeg: add some padding to ScanHdr structTim-Philipp Müller2015-06-211-0/+6
| | | | For bits that we don't parse out at the moment.
* codecparsers: jpeg: fix docs for table parsing functionsTim-Philipp Müller2015-06-211-3/+2
|
* docs: add new JPEG codecparser API to the docsTim-Philipp Müller2015-06-212-0/+41
| | | | And sprinkle some more Since markers
* codecparsers: jpeg: fix validity checking of data parsedTim-Philipp Müller2015-06-211-46/+61
| | | | | | | 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
* codecparsers: jpeg: fix up APITim-Philipp Müller2015-06-212-182/+207
| | | | | | | | | | | - 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
* codecparsers: jpeg: tweak API a littleTim-Philipp Müller2015-06-212-29/+84
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=673925
* codecparsers: jpeg: hide gst_jpeg_scan_for_marker_code()Tim-Philipp Müller2015-06-212-17/+15
| | | | | | | 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
* codecparsers: jpeg: fix and optimize scan for next marker code.Gwenole Beauchesne2015-06-211-9/+8
| | | | | | | | 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.
* codecparsers: jpeg: fix calculation of segment size.Gwenole Beauchesne2015-06-211-2/+3
| | | | | | | | | 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
* codecparsers: jpeg: fix default Huffman tables generation.Wind Yuan2015-06-211-0/+1
| | | | | Fix build_huffman_table() to correctly fill in the associated HUFFVAL entries to the default Huffman tables.
* codecparsers: jpeg: add JPEG bitstream parserGwenole Beauchesne2015-06-213-0/+1027
| | | | | | Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com> https://bugzilla.gnome.org/show_bug.cgi?id=673925
* nalutils: trivial patch to check ifVineeth TM2015-06-161-6/+3
| | | | | | trivial patch to add proper ( while checking for if(G_UNLIKELY()) https://bugzilla.gnome.org/show_bug.cgi?id=751087
* codecparsers: mpeg4: actually return full number of bits of resync markerLuis de Bethencourt2015-06-131-2/+2
| | | | | | | | | | 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
* Revert "codecparsers: remove ignored increment of return"Tim-Philipp Müller2015-06-131-1/+1
| | | | | | | | | | | | | | 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
* codecparser: h265: Fix nal unit size checkingSreerenj Balachandran2015-04-301-2/+2
| | | | | | | | | 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)
* codecparser: h265: Calculate crop rectangle dimensionsSreerenj Balachandran2015-04-302-1/+18
|
* codecparser: h265: Fix parsing multiple SEI messages in a single SEI NalSreerenj Balachandran2015-04-302-41/+115
| | | | | | An SEI Nal can have more than one SEI message. Change in API: the gst_h265_parser_parse_sei()
* codecparser: h265: Fix the number of tile rows/columns parsingSreerenj Balachandran2015-04-291-2/+2
| | | | | | | 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
* codecparsers: h265: add helpers to convert quantization matricesSreerenj Balachandran2015-04-262-0/+139
| | | | | | | 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
* codecparser: h265: skip byte alignment bits while parsing slice headerSreerenj Balachandran2015-04-261-0/+8
| | | | | | | | 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
* codecparser: h265: Fix the NumDeltaPocs calculationSreerenj Balachandran2015-04-261-5/+4
| | | | | | | Always use the equation provided in spec (7-57) for finding the NumDeltaPocs https://bugzilla.gnome.org/show_bug.cgi?id=747613
* codecparser: h265: Fix the NumPocTotalCurr calculationSreerenj Balachandran2015-04-261-17/+18
| | | | | | The NumPocToalCurr should be calculated for all B and P slices. https://bugzilla.gnome.org/show_bug.cgi?id=747613
* codecparser: h265: Fix nal size calculation for EOS and EOBSreerenj Balachandran2015-04-261-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=747613
* Remove obsolete Android build cruftTim-Philipp Müller2015-04-261-16/+0
| | | | This is not needed any longer.
* codecparsers: Indent fileEdward Hervey2015-01-231-49/+47
| | | | Someone's been commiting without using gst-indent :)
* codecparsers: Add READ_UE_MAX macroEdward Hervey2015-01-233-130/+123
| | | | | | | | 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)
* Constify some static arrays everywhereSebastian Dröge2015-01-213-3/+3
|
* h264parser: fix stack smashingVincent Penquerc'h2015-01-141-4/+8
| | | | | | | | | | | | | | | 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>
* codecparsers: fix some compiler warningsJulien Isorce2014-11-252-8/+15
| | | | | | | | | 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
View Lorry Controller Status