mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-13 03:46:34 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/gst-libs/gst/mpegts/gstmpegtssection.h

432 lines
16 KiB
C
Raw Normal View History

gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/*
* mpegtspacketizer.h -
* Copyright (C) 2013 Edward Hervey
*
* Authors:
* Edward Hervey <edward@collabora.com>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
#ifndef GST_MPEGTS_SECTION_H
#define GST_MPEGTS_SECTION_H
#include <gst/gst.h>
#include <gst/mpegts/gstmpegtsdescriptor.h>
mpegts: make headers usable with c++ compiler Add G_BEGIN_DECLS G_END_DECLS https://bugzilla.gnome.org/show_bug.cgi?id=671136
2014-01-06 15:01:22 +00:00
G_BEGIN_DECLS
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
typedef struct _GstMpegtsSection GstMpegtsSection;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
#define GST_TYPE_MPEGTS_SECTION (gst_mpegts_section_get_type())
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
#define GST_MPEGTS_SECTION(section) ((GstMpegtsSection*) section)
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
#define GST_MPEGTS_SECTION_TYPE(section) (GST_MPEGTS_SECTION (section)->section_type)
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
GType gst_mpegts_section_get_type (void);
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsSectionType:
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* @GST_MPEGTS_SECTION_UNKNOWN: Unknown section type
* @GST_MPEGTS_SECTION_PAT: Program Association Table (ISO/IEC 13818-1)
* @GST_MPEGTS_SECTION_PMT: Program Map Table (ISO/IEC 13818-1)
* @GST_MPEGTS_SECTION_CAT: Conditional Access Table (ISO/IEC 13818-1)
* @GST_MPEGTS_SECTION_TSDT: Transport Stream Description Table (ISO/IEC 13818-1)
* @GST_MPEGTS_SECTION_EIT: Event Information Table (EN 300 468)
* @GST_MPEGTS_SECTION_NIT: Network Information Table (ISO/IEC 13818-1 / EN 300 468)
* @GST_MPEGTS_SECTION_BAT: Bouquet Association Table ((EN 300 468)
* @GST_MPEGTS_SECTION_SDT: Service Description Table (EN 300 468)
* @GST_MPEGTS_SECTION_TDT: Time and Date Table (EN 300 468)
* @GST_MPEGTS_SECTION_TOT: Time Offset Table (EN 300 468)
mpegts: add atsc terrestrial virtual channel table https://bugzilla.gnome.org/show_bug.cgi?id=727460
2014-04-09 08:04:46 +00:00
* @GST_MPEGTS_SECTION_ATSC_TVCT: ATSC Terrestrial Virtual Channel Table (A65)
mpegts: atsc: rename TVCT to VCT as it is the same as CVCT Make the ATSC section parse handle both TVCT and CVCT as they are nearly the same struct (CVCT uses 2 reserved bits that are ignored in TVCT). This is changing the glib type and the struct name but TVCT wasn't released in a stable package yet so there should be no problem. Also includes some parsing fixes and changes short_name to be directly stored as utf8 rather than utf16 https://bugzilla.gnome.org/show_bug.cgi?id=730642
2014-05-23 04:41:18 +00:00
* @GST_MPEGTS_SECTION_ATSC_CVCT: ATSC Cable Virtual Channel Table (A65)
mpegts: add atsc MGT section parsing Add a parsing function for MGT and also detect the EIT tables for ATSC, the EIT pids are reported inside the MGT and we are still only relying only on the table id for detecting it. In the future we would want to also check the pid and compare with whatever the MGT previously reported to confirm that it is indeed the EIT. https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-15 15:31:05 +00:00
* @GST_MPEGTS_SECTION_ATSC_MGT: ATSC Master Guide Table (A65)
mpegts: atsc: add ETT structures and parsing ETT (extended text table) contains ATSC text information with descriptions of virtual channels and events. The text can be internationalized and also compressed. https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-19 16:46:03 +00:00
* @GST_MPEGTS_SECTION_ATSC_ETT: ATSC Extended Text Table (A65)
mpegts: atsc: add atsc's EIT table parsing ATSC has its own version of the EIT table (DVB also has one). This patch adds parsing for the ATSC EIT table and also fixed the section identification to mark it as the ATSC one. The implementation aws refactored to reuse some common internal structures from ETT. Also adds its dumping function to ts-parser example https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-28 18:59:23 +00:00
* @GST_MPEGTS_SECTION_ATSC_EIT: ATSC Event Information Table (A65)
mpegts: atsc: add STT table parsing Adds the system time table structure and functions for convenient parsing of it and for getting the UTC datetime that it represents. Also adds its information dumping to the ts-parser example https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-22 04:47:48 +00:00
* @GST_MPEGTS_SECTION_ATSC_STT: ATSC System Time Table (A65)
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* Types of #GstMpegtsSection that the library handles.
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*/
typedef enum {
GST_MPEGTS_SECTION_UNKNOWN = 0,
GST_MPEGTS_SECTION_PAT,
GST_MPEGTS_SECTION_PMT,
GST_MPEGTS_SECTION_CAT,
GST_MPEGTS_SECTION_TSDT,
GST_MPEGTS_SECTION_EIT,
GST_MPEGTS_SECTION_NIT,
GST_MPEGTS_SECTION_BAT,
GST_MPEGTS_SECTION_SDT,
GST_MPEGTS_SECTION_TDT,
mpegts: add atsc terrestrial virtual channel table https://bugzilla.gnome.org/show_bug.cgi?id=727460
2014-04-09 08:04:46 +00:00
GST_MPEGTS_SECTION_TOT,
mpegts: atsc: rename TVCT to VCT as it is the same as CVCT Make the ATSC section parse handle both TVCT and CVCT as they are nearly the same struct (CVCT uses 2 reserved bits that are ignored in TVCT). This is changing the glib type and the struct name but TVCT wasn't released in a stable package yet so there should be no problem. Also includes some parsing fixes and changes short_name to be directly stored as utf8 rather than utf16 https://bugzilla.gnome.org/show_bug.cgi?id=730642
2014-05-23 04:41:18 +00:00
GST_MPEGTS_SECTION_ATSC_TVCT,
mpegts: add atsc MGT section parsing Add a parsing function for MGT and also detect the EIT tables for ATSC, the EIT pids are reported inside the MGT and we are still only relying only on the table id for detecting it. In the future we would want to also check the pid and compare with whatever the MGT previously reported to confirm that it is indeed the EIT. https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-15 15:31:05 +00:00
GST_MPEGTS_SECTION_ATSC_CVCT,
mpegts: atsc: add ETT structures and parsing ETT (extended text table) contains ATSC text information with descriptions of virtual channels and events. The text can be internationalized and also compressed. https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-19 16:46:03 +00:00
GST_MPEGTS_SECTION_ATSC_MGT,
mpegts: atsc: add STT table parsing Adds the system time table structure and functions for convenient parsing of it and for getting the UTC datetime that it represents. Also adds its information dumping to the ts-parser example https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-22 04:47:48 +00:00
GST_MPEGTS_SECTION_ATSC_ETT,
mpegts: atsc: add atsc's EIT table parsing ATSC has its own version of the EIT table (DVB also has one). This patch adds parsing for the ATSC EIT table and also fixed the section identification to mark it as the ATSC one. The implementation aws refactored to reuse some common internal structures from ETT. Also adds its dumping function to ts-parser example https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-28 18:59:23 +00:00
GST_MPEGTS_SECTION_ATSC_EIT,
mpegts: atsc: add STT table parsing Adds the system time table structure and functions for convenient parsing of it and for getting the UTC datetime that it represents. Also adds its information dumping to the ts-parser example https://bugzilla.gnome.org/show_bug.cgi?id=730435
2014-05-22 04:47:48 +00:00
GST_MPEGTS_SECTION_ATSC_STT
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
} GstMpegtsSectionType;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsSectionTableID:
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* Values for a #GstMpegtsSection table_id
mpegts: Split files and implement free functions * In order to avoid future clashing between table_id for the various mpeg-ts variants, use different enums. * In order to keep everything clean(ish) and allow for cleaner growth, split into different files (will need the same for descriptors later) * Also ... implement free functions for all table types :)
2013-07-03 15:59:02 +00:00
*
* These are the registered ITU H.222.0 | ISO/IEC 13818-1 table_id variants.
*
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* see also #GstMpegtsSectionATSCTableID, #GstMpegtsSectionDVBTableID, and
* #GstMpegtsSectionSCTETableID
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*/
typedef enum {
/* ITU H.222.0 / IEC 13818-1 */
GST_MTS_TABLE_ID_PROGRAM_ASSOCIATION = 0x00,
GST_MTS_TABLE_ID_CONDITIONAL_ACCESS = 0x01,
GST_MTS_TABLE_ID_TS_PROGRAM_MAP = 0x02,
GST_MTS_TABLE_ID_TS_DESCRIPTION = 0x03,
GST_MTS_TABLE_ID_14496_SCENE_DESCRIPTION = 0x04,
GST_MTS_TABLE_ID_14496_OBJET_DESCRIPTOR = 0x05,
GST_MTS_TABLE_ID_METADATA = 0x06,
GST_MTS_TABLE_ID_IPMP_CONTROL_INFORMATION = 0x07,
mpegts: Split files and implement free functions * In order to avoid future clashing between table_id for the various mpeg-ts variants, use different enums. * In order to keep everything clean(ish) and allow for cleaner growth, split into different files (will need the same for descriptors later) * Also ... implement free functions for all table types :)
2013-07-03 15:59:02 +00:00
/* 0x08 - 0x39 : ITU H.222.0 | ISO/IEC 13818-1 reserved */
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* IEC 13818-6 (DSM-CC) */
GST_MTS_TABLE_ID_DSM_CC_MULTIPROTO_ENCAPSULATED_DATA = 0x3A,
GST_MTS_TABLE_ID_DSM_CC_U_N_MESSAGES = 0x3B,
GST_MTS_TABLE_ID_DSM_CC_DOWNLOAD_DATA_MESSAGES = 0x3C,
GST_MTS_TABLE_ID_DSM_CC_STREAM_DESCRIPTORS = 0x3D,
GST_MTS_TABLE_ID_DSM_CC_PRIVATE_DATA = 0x3E,
GST_MTS_TABLE_ID_DSM_CC_ADDRESSABLE_SECTIONS = 0x3F,
/* Unset */
GST_MTS_TABLE_ID_UNSET = 0xFF
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
} GstMpegtsSectionTableID;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
typedef gboolean (*GstMpegtsPacketizeFunc) (GstMpegtsSection *section);
mpegts: Add functions to packetize section Sections needs to be packetized for use in i.e. mpegtsmux. These functions handles the generic common parts of a GstMpegTsSection
2013-10-28 13:44:13 +00:00
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsSection:
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* @section_type: The type of section
* @pid: The pid on which this section was found
* @table_id: The table id of this section
* @subtable_extension: This meaning differs per section. See the documentation
* of the parsed section type for the meaning of this field
* @version_number: Version of the section.
* @current_next_indicator: Applies to current/next stream or not
* @section_number: Number of the section (if multiple)
* @last_section_number: Number of the last expected section (if multiple)
* @crc: CRC
*
* Mpeg-TS Section Information (SI) (ISO/IEC 13818-1)
*/
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
struct _GstMpegtsSection
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
{
/*< private >*/
GstMiniObject parent;
/*< public >*/
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSectionType section_type;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
guint16 pid;
mpegts: Split files and implement free functions * In order to avoid future clashing between table_id for the various mpeg-ts variants, use different enums. * In order to keep everything clean(ish) and allow for cleaner growth, split into different files (will need the same for descriptors later) * Also ... implement free functions for all table types :)
2013-07-03 15:59:02 +00:00
guint8 table_id;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
guint16 subtable_extension;
guint8 version_number;
gboolean current_next_indicator;
guint8 section_number;
guint8 last_section_number;
guint32 crc;
/*< private >*/
/* data: Points to beginning of section data
* i.e. the first byte is the table_id field */
guint8 *data;
/* section_length: length of data (including final CRC if present) */
guint section_length;
/* cached_parsed: cached copy of parsed section */
gpointer *cached_parsed;
mpegts: Split files and implement free functions * In order to avoid future clashing between table_id for the various mpeg-ts variants, use different enums. * In order to keep everything clean(ish) and allow for cleaner growth, split into different files (will need the same for descriptors later) * Also ... implement free functions for all table types :)
2013-07-03 15:59:02 +00:00
/* destroy_parsed: function to clear cached_parsed */
GDestroyNotify destroy_parsed;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* offset: offset of the section within the container stream */
guint64 offset;
/* short_section: TRUE if section_syntax_indicator == 0
* FIXME : Maybe make public later on when allowing creation of
* sections to that people can create private short sections ? */
gboolean short_section;
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsPacketizeFunc packetizer;
mpegts: Add padding to public structures Allows use to add API in the future without breaking ABI. We broke the API/ABI once between 1.2 and 1.4, let's try to avoid this in the future even if this is an unstable library. https://bugzilla.gnome.org/show_bug.cgi?id=730914
2014-07-09 05:38:38 +00:00
/* Padding for future extension */
gpointer _gst_reserved[GST_PADDING];
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
};
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GBytes *gst_mpegts_section_get_data (GstMpegtsSection *section);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* PAT */
mpegts: ABI/API break: Use GPtrArray instead of GArray While it was a great idea, various g-i based bindings don't support GArray with entries greater than sizeof(gpointer) :( So let's just make everybody happy by just using GPtrArray. And since we're breaking the API, also rename the various descriptor fields to no longer have the descriptor_ prefix. It does cost a bit more in terms of memory/cpu usage, but makes it usable from bindings.
2013-08-21 06:40:16 +00:00
#define GST_TYPE_MPEGTS_PAT_PROGRAM (gst_mpegts_pat_program_get_type())
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
typedef struct _GstMpegtsPatProgram GstMpegtsPatProgram;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsPatProgram:
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* @program_number: the program number
* @network_or_program_map_PID: the network of program map PID
*
* A program entry from a Program Association Table (ITU H.222.0, ISO/IEC 13818-1).
*/
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
struct _GstMpegtsPatProgram
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
{
guint16 program_number;
guint16 network_or_program_map_PID;
};
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GPtrArray *gst_mpegts_section_get_pat (GstMpegtsSection *section);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: ABI/API break: Use GPtrArray instead of GArray While it was a great idea, various g-i based bindings don't support GArray with entries greater than sizeof(gpointer) :( So let's just make everybody happy by just using GPtrArray. And since we're breaking the API, also rename the various descriptor fields to no longer have the descriptor_ prefix. It does cost a bit more in terms of memory/cpu usage, but makes it usable from bindings.
2013-08-21 06:40:16 +00:00
GType gst_mpegts_pat_program_get_type (void);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Add support for creating PAT/PMT
2013-11-20 10:06:03 +00:00
GPtrArray *gst_mpegts_pat_new (void);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsPatProgram *gst_mpegts_pat_program_new (void);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSection *gst_mpegts_section_from_pat (GPtrArray * programs,
mpegts: Add support for creating PAT/PMT
2013-11-20 10:06:03 +00:00
guint16 ts_id);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* CAT */
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GPtrArray *gst_mpegts_section_get_cat (GstMpegtsSection *section);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* PMT */
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
typedef struct _GstMpegtsPMTStream GstMpegtsPMTStream;
typedef struct _GstMpegtsPMT GstMpegtsPMT;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
#define GST_TYPE_MPEGTS_PMT (gst_mpegts_pmt_get_type())
#define GST_TYPE_MPEGTS_PMT_STREAM (gst_mpegts_pmt_stream_get_type())
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsStreamType:
* @GST_MPEGTS_STREAM_TYPE_RESERVED_00: ITU-T | ISO/IEC Reserved
* @GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG1: ISO/IEC 11172-2 Video
* @GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG2: Rec. ITU-T H.262 | ISO/IEC 13818-2
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* Video or ISO/IEC 11172-2 constrained parameter video stream
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_AUDIO_MPEG1: ISO/IEC 11172-3 Audio
* @GST_MPEGTS_STREAM_TYPE_AUDIO_MPEG2: ISO/IEC 13818-3 Audio
* @GST_MPEGTS_STREAM_TYPE_PRIVATE_SECTIONS: private sections
* @GST_MPEGTS_STREAM_TYPE_PRIVATE_PES_PACKETS: PES packets containing private data
* @GST_MPEGTS_STREAM_TYPE_MHEG: ISO/IEC 13522 MHEG
* @GST_MPEGTS_STREAM_TYPE_DSM_CC: Annex A DSM-CC
* @GST_MPEGTS_STREAM_TYPE_H_222_1: Rec. ITU-T H.222.1
* @GST_MPEGTS_STREAM_TYPE_DSMCC_A: ISO/IEC 13818-6 type A
* @GST_MPEGTS_STREAM_TYPE_DSMCC_B: ISO/IEC 13818-6 type B
* @GST_MPEGTS_STREAM_TYPE_DSMCC_C: ISO/IEC 13818-6 type C
* @GST_MPEGTS_STREAM_TYPE_DSMCC_D: ISO/IEC 13818-6 type D
* @GST_MPEGTS_STREAM_TYPE_AUXILIARY: auxiliary streams
* @GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_ADTS: ISO/IEC 13818-7 Audio with ADTS
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* transport syntax
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG4: ISO/IEC 14496-2 Visual
* @GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_LATM: ISO/IEC 14496-3 Audio with the LATM
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* transport syntax as defined in ISO/IEC 14496-3
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_SL_FLEXMUX_PES_PACKETS: ISO/IEC 14496-1
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* SL-packetized stream or FlexMux stream carried in PES packets
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_SL_FLEXMUX_SECTIONS: ISO/IEC 14496-1 SL-packetized
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* stream or FlexMux stream carried in ISO/IEC 14496_sections
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_SYNCHRONIZED_DOWNLOAD: ISO/IEC 13818-6 Synchronized
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* Download Protocol
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_METADATA_PES_PACKETS: Metadata carried in PES packets
* @GST_MPEGTS_STREAM_TYPE_METADATA_SECTIONS: Metadata carried in metadata_sections
* @GST_MPEGTS_STREAM_TYPE_METADATA_DATA_CAROUSEL: Metadata carried in ISO/IEC
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* 13818-6 Data Carousel
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_METADATA_OBJECT_CAROUSEL: Metadata carried in
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* ISO/IEC 13818-6 Object Carousel
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_METADATA_SYNCHRONIZED_DOWNLOAD: Metadata carried in
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* ISO/IEC 13818-6 Synchronized Download Protocol
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_MPEG2_IPMP: IPMP stream (defined in ISO/IEC 13818-11,
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* MPEG-2 IPMP)
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_H264: AVC video stream conforming to one or
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* more profiles defined in Annex A of Rec. ITU-T H.264 | ISO/IEC 14496-10 or
* AVC video sub-bitstream of SVC as defined in 2.1.78 or MVC base view
* sub-bitstream, as defined in 2.1.85, or AVC video sub-bitstream of MVC, as
* defined in 2.1.88
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_CLEAN: ISO/IEC 14496-3 Audio, without
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* using any additional transport syntax, such as DST, ALS and SLS
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_MPEG4_TIMED_TEXT: ISO/IEC 14496-17 Text
* @GST_MPEGTS_STREAM_TYPE_VIDEO_RVC: Auxiliary video stream as defined in
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* ISO/IEC 23002-3
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_H264_SVC_SUB_BITSTREAM: SVC video sub-bitstream
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* of an AVC video stream conforming to one or more profiles defined in Annex G
* of Rec. ITU-T H.264 | ISO/IEC 14496-10
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_H264_MVC_SUB_BITSTREAM: MVC video sub-bitstream
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* of an AVC video stream conforming to one or more profiles defined in Annex H
* of Rec. ITU-T H.264 | ISO/IEC 14496-10
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_JP2K: Video stream conforming to one or more
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* profiles as defined in Rec. ITU-T T.800 | ISO/IEC 15444-1
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG2_STEREO_ADDITIONAL_VIEW: Additional view
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* Rec. ITU-T H.262 | ISO/IEC 13818-2 video stream for service-compatible
* stereoscopic 3D services
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_VIDEO_H264_STEREO_ADDITIONAL_VIEW: Additional view
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
* Rec. ITU-T H.264 | ISO/IEC 14496-10 video stream conforming to one or more
* profiles defined in Annex A for service-compatible stereoscopic 3D services
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @GST_MPEGTS_STREAM_TYPE_IPMP_STREAM: IPMP stream
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
*
* Type of mpeg-ts stream type.
*
* These values correspond to the base standard registered types. Depending
* on the variant of mpeg-ts being used (Bluray, ATSC, DVB, ...), other
* types might also be used, but will not conflict with these.
*
* Corresponds to table 2-34 of ITU H.222.0 | ISO/IEC 13818-1
*/
typedef enum {
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GST_MPEGTS_STREAM_TYPE_RESERVED_00 = 0x00,
GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG1 = 0x01,
GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG2 = 0x02,
GST_MPEGTS_STREAM_TYPE_AUDIO_MPEG1 = 0x03,
GST_MPEGTS_STREAM_TYPE_AUDIO_MPEG2 = 0x04,
GST_MPEGTS_STREAM_TYPE_PRIVATE_SECTIONS = 0x05,
GST_MPEGTS_STREAM_TYPE_PRIVATE_PES_PACKETS = 0x06,
GST_MPEGTS_STREAM_TYPE_MHEG = 0x07,
GST_MPEGTS_STREAM_TYPE_DSM_CC = 0x08,
GST_MPEGTS_STREAM_TYPE_H_222_1 = 0x09,
GST_MPEGTS_STREAM_TYPE_DSMCC_A = 0x0a,
GST_MPEGTS_STREAM_TYPE_DSMCC_B = 0x0b,
GST_MPEGTS_STREAM_TYPE_DSMCC_C = 0x0c,
GST_MPEGTS_STREAM_TYPE_DSMCC_D = 0x0d,
GST_MPEGTS_STREAM_TYPE_AUXILIARY = 0x0e,
GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_ADTS = 0x0f,
GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG4 = 0x10,
GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_LATM = 0x11,
GST_MPEGTS_STREAM_TYPE_SL_FLEXMUX_PES_PACKETS = 0x12,
GST_MPEGTS_STREAM_TYPE_SL_FLEXMUX_SECTIONS = 0x13,
GST_MPEGTS_STREAM_TYPE_SYNCHRONIZED_DOWNLOAD = 0x14,
GST_MPEGTS_STREAM_TYPE_METADATA_PES_PACKETS = 0x15,
GST_MPEGTS_STREAM_TYPE_METADATA_SECTIONS = 0x16,
GST_MPEGTS_STREAM_TYPE_METADATA_DATA_CAROUSEL = 0x17,
GST_MPEGTS_STREAM_TYPE_METADATA_OBJECT_CAROUSEL = 0x18,
GST_MPEGTS_STREAM_TYPE_METADATA_SYNCHRONIZED_DOWNLOAD = 0x19,
GST_MPEGTS_STREAM_TYPE_MPEG2_IPMP = 0x1a,
GST_MPEGTS_STREAM_TYPE_VIDEO_H264 = 0x1b,
GST_MPEGTS_STREAM_TYPE_AUDIO_AAC_CLEAN = 0x1c,
GST_MPEGTS_STREAM_TYPE_MPEG4_TIMED_TEXT = 0x1d,
GST_MPEGTS_STREAM_TYPE_VIDEO_RVC = 0x1e,
GST_MPEGTS_STREAM_TYPE_VIDEO_H264_SVC_SUB_BITSTREAM = 0x1f,
GST_MPEGTS_STREAM_TYPE_VIDEO_H264_MVC_SUB_BITSTREAM = 0x20,
GST_MPEGTS_STREAM_TYPE_VIDEO_JP2K = 0x21,
GST_MPEGTS_STREAM_TYPE_VIDEO_MPEG2_STEREO_ADDITIONAL_VIEW = 0x22,
GST_MPEGTS_STREAM_TYPE_VIDEO_H264_STEREO_ADDITIONAL_VIEW = 0x23,
GST_MPEGTS_STREAM_TYPE_VIDEO_HEVC = 0x24,
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
/* 0x24 - 0x7e : Rec. ITU-T H.222.0 | ISO/IEC 13818-1 Reserved */
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GST_MPEGTS_STREAM_TYPE_IPMP_STREAM = 0x7f
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
/* 0x80 - 0xff : User Private (or defined in other specs) */
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
} GstMpegtsStreamType;
mpegts: Add registered mpeg-ts stream types These are the values officially registered in the base specification (H.222.0/13818-1). Later on we can add other enums for other variants Note that the enum is not used in the structure fields (such as a pmt stream stream_type field) since it can contain values from other variants.
2013-07-04 05:45:12 +00:00
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsPMTStream:
* @stream_type: the type of stream. See #GstMpegtsStreamType
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* @pid: the PID of the stream
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @descriptors: (element-type GstMpegtsDescriptor): the descriptors of the
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* stream
*
* An individual stream definition.
*/
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
struct _GstMpegtsPMTStream
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
{
guint8 stream_type;
guint16 pid;
mpegts: more annotation fixes
2014-06-24 13:41:36 +00:00
GPtrArray *descriptors;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
};
/**
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* GstMpegtsPMT:
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
* @pcr_pid: PID of the stream containing PCR
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* @descriptors: (element-type GstMpegtsDescriptor): array of #GstMpegtsDescriptor
* @streams: (element-type GstMpegtsPMTStream): Array of #GstMpegtsPMTStream
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*
* Program Map Table (ISO/IEC 13818-1).
*
* The program_number is contained in the subtable_extension field of the
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
* container #GstMpegtsSection.
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
*/
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
struct _GstMpegtsPMT
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
{
guint16 pcr_pid;
mpegts: Add program_number to GstMpegTsPMT
2013-11-20 10:04:58 +00:00
guint16 program_number;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
mpegts: more annotation fixes
2014-06-24 13:41:36 +00:00
GPtrArray *descriptors;
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
GPtrArray *streams;
};
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
GType gst_mpegts_pmt_get_type (void);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
GType gst_mpegts_pmt_stream_get_type (void);
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsPMT *gst_mpegts_pmt_new (void);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsPMTStream *gst_mpegts_pmt_stream_new (void);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
const GstMpegtsPMT *gst_mpegts_section_get_pmt (GstMpegtsSection *section);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSection *gst_mpegts_section_from_pmt (GstMpegtsPMT *pmt, guint16 pid);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* TSDT */
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GPtrArray *gst_mpegts_section_get_tsdt (GstMpegtsSection *section);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
/* generic */
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
#define gst_mpegts_section_ref(section) ((GstMpegtsSection*) gst_mini_object_ref (GST_MINI_OBJECT_CAST (section)))
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
#define gst_mpegts_section_unref(section) (gst_mini_object_unref (GST_MINI_OBJECT_CAST (section)))
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMessage *gst_message_new_mpegts_section (GstObject *parent, GstMpegtsSection *section);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
gboolean gst_mpegts_section_send_event (GstMpegtsSection * section, GstElement * element);
mpegts: mark symbols explicitly for export with GST_EXPORT
2017-07-18 00:10:56 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSection *gst_event_parse_mpegts_section (GstEvent * event);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSection *gst_message_parse_mpegts_section (GstMessage *message);
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
GstMpegtsSection *gst_mpegts_section_new (guint16 pid,
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
guint8 * data,
gsize data_size);
mpegts: GST_EXPORT -> GST_MPEGTS_API We need different export decorators for the different libs. For now no actual change though, just rename before the release, and add prelude headers to define the new decorator to GST_EXPORT.
2018-03-13 12:47:03 +00:00
GST_MPEGTS_API
mpegts: Unify API : GstMpegts / gst_mpegts_ / GST_*_MPEGTS_ It was previously a mix and match of both variants, introducing just too much confusion. The prefix are from now on: * GstMpegts for structures and type names (and not GstMpegTs) * gst_mpegts_ for functions (and not gst_mpeg_ts_) * GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_) * GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_) The rationale for chosing that is: * the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts) * the namespace is one word under Gst * it's shorter (yah)
2014-06-25 12:50:05 +00:00
guint8 *gst_mpegts_section_packetize (GstMpegtsSection * section, gsize * output_size);
mpegts: Add functions to packetize section Sections needs to be packetized for use in i.e. mpegtsmux. These functions handles the generic common parts of a GstMpegTsSection
2013-10-28 13:44:13 +00:00
mpegts: make headers usable with c++ compiler Add G_BEGIN_DECLS G_END_DECLS https://bugzilla.gnome.org/show_bug.cgi?id=671136
2014-01-06 15:01:22 +00:00
G_END_DECLS
gst-libs: New Mpeg-TS support library Exposes various MPEG-TS (ISO/IEC 13818-1) and DVB (EN 300 468) Section Information as well as descriptors for usage by plugins and applications. This replaces entirely the old GstStructure-based system for conveying mpeg-ts information to applications and other plugins. Parsing and validation is done on a "when-needed" basis. This ensures the minimal overhead for elements and applications creating and using sections and descriptors. Since all information is made available, this also allows applications to parse custom sections and descriptors. Right now the library is targeted towards parsing, but the structures could be used in the future to allow applications to create and inject sections and descriptors (for usage by various mpeg-ts elements). https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:41:12 +00:00
#endif /* GST_MPEGTS_SECTION_H */
Reference in a new issue Copy permalink