mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-07-01 20:30:41 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/subprojects/gst-plugins-bad/gst/mpegtsdemux/mpegtspacketizer.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2606 lines
89 KiB
C
Raw Normal View History

mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
/*
tsdemux: Minor refactoring/code cleaning ... add some debugging symbols in the mean time.
2012-02-15 14:06:57 +00:00
* mpegtspacketizer.c -
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
* Copyright (C) 2007, 2008 Alessandro Decina, Zaheer Merali
tsdemux: Minor refactoring/code cleaning ... add some debugging symbols in the mean time.
2012-02-15 14:06:57 +00:00
*
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
* Authors:
* Zaheer Merali <zaheerabbas at merali dot org>
* Alessandro Decina <alessandro@nnva.org>
*
* 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
Fix FSF address https://bugzilla.gnome.org/show_bug.cgi?id=687520
2012-11-03 20:38:00 +00:00
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
* Boston, MA 02110-1301, USA.
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
*/
Use g_memdup2() where available and add fallback for older GLib versions g_memdup() is deprecated since GLib 2.68 and we want to avoid deprecation warnings with recent versions of GLib. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2280>
2021-05-23 18:15:25 +00:00
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
#include <string.h>
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
#include <stdlib.h>
tsdemux: fix glib deprecation
2012-02-16 12:54:24 +00:00
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* Skew calculation pameters */
#define MAX_TIME (2 * GST_SECOND)
tsdemux: fix glib deprecation
2012-02-16 12:54:24 +00:00
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
/* maximal PCR time */
#define PCR_MAX_VALUE (((((guint64)1)<<33) * 300) + 298)
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
#define PCR_GST_MAX_VALUE (PCR_MAX_VALUE * GST_MSECOND / (PCR_MSECOND))
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
#define PTS_DTS_MAX_VALUE (((guint64)1) << 33)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
#include "mpegtspacketizer.h"
#include "gstmpegdesc.h"
GST_DEBUG_CATEGORY_STATIC (mpegts_packetizer_debug);
#define GST_CAT_DEFAULT mpegts_packetizer_debug
static void _init_local (void);
G_DEFINE_TYPE_EXTENDED (MpegTSPacketizer2, mpegts_packetizer, G_TYPE_OBJECT, 0,
_init_local ());
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
#define ABSDIFF(a,b) ((a) < (b) ? (b) - (a) : (a) - (b))
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
#define PACKETIZER_GROUP_LOCK(p) g_mutex_lock(&((p)->group_lock))
#define PACKETIZER_GROUP_UNLOCK(p) g_mutex_unlock(&((p)->group_lock))
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
static void mpegts_packetizer_dispose (GObject * object);
static void mpegts_packetizer_finalize (GObject * object);
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
static GstClockTime calculate_skew (MpegTSPacketizer2 * packetizer,
MpegTSPCR * pcr, guint64 pcrtime, GstClockTime time);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
static void _close_current_group (MpegTSPCR * pcrtable);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
static void record_pcr (MpegTSPacketizer2 * packetizer, MpegTSPCR * pcrtable,
guint64 pcr, guint64 offset);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
#define CONTINUITY_UNSET 255
#define VERSION_NUMBER_UNSET 255
#define TABLE_ID_UNSET 0xFF
tsdemux: Minor refactoring/code cleaning ... add some debugging symbols in the mean time.
2012-02-15 14:06:57 +00:00
#define PACKET_SYNC_BYTE 0x47
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
static inline MpegTSPCR *
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
get_pcr_table (MpegTSPacketizer2 * packetizer, guint16 pid)
{
MpegTSPCR *res;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
res = packetizer->observations[packetizer->pcrtablelut[pid]];
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (res == NULL)) {
/* If we don't have a PCR table for the requested PID, create one .. */
res = g_new0 (MpegTSPCR, 1);
/* Add it to the last table position */
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->observations[packetizer->lastobsid] = res;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
/* Update the pcrtablelut */
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->pcrtablelut[pid] = packetizer->lastobsid;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
/* And increment the last know slot */
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->lastobsid++;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
/* Finally set the default values */
res->pid = pid;
res->base_time = GST_CLOCK_TIME_NONE;
res->base_pcrtime = GST_CLOCK_TIME_NONE;
res->last_pcrtime = GST_CLOCK_TIME_NONE;
res->window_pos = 0;
res->window_filling = TRUE;
res->window_min = 0;
res->skew = 0;
res->prev_send_diff = GST_CLOCK_TIME_NONE;
res->prev_out_time = GST_CLOCK_TIME_NONE;
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
res->pcroffset = 0;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
mpegtsdemux: drop use of GSlice Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3695>
2023-01-08 18:46:03 +00:00
res->current = g_new0 (PCROffsetCurrent, 1);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
}
return res;
}
tsdemux: Fix leak of PCROffsetGroup https://bugzilla.gnome.org/show_bug.cgi?id=722462
2014-01-17 23:19:36 +00:00
static void
pcr_offset_group_free (PCROffsetGroup * group)
{
g_free (group->values);
mpegtsdemux: drop use of GSlice Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3695>
2023-01-08 18:46:03 +00:00
g_free (group);
tsdemux: Fix leak of PCROffsetGroup https://bugzilla.gnome.org/show_bug.cgi?id=722462
2014-01-17 23:19:36 +00:00
}
mpegtspacketizer: flush observations too Flush the previous observations when the packetizer is flushed. Also don't leak them in the dispose.
2012-11-11 11:45:03 +00:00
static void
flush_observations (MpegTSPacketizer2 * packetizer)
{
gint i;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
for (i = 0; i < packetizer->lastobsid; i++) {
tsdemux: Fix leak of PCROffsetGroup https://bugzilla.gnome.org/show_bug.cgi?id=722462
2014-01-17 23:19:36 +00:00
g_list_free_full (packetizer->observations[i]->groups,
(GDestroyNotify) pcr_offset_group_free);
mpegtsdemux: drop use of GSlice Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3695>
2023-01-08 18:46:03 +00:00
g_free (packetizer->observations[i]->current);
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
g_free (packetizer->observations[i]);
packetizer->observations[i] = NULL;
mpegtspacketizer: flush observations too Flush the previous observations when the packetizer is flushed. Also don't leak them in the dispose.
2012-11-11 11:45:03 +00:00
}
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
memset (packetizer->pcrtablelut, 0xff, 0x2000);
packetizer->lastobsid = 0;
mpegtspacketizer: flush observations too Flush the previous observations when the packetizer is flushed. Also don't leak them in the dispose.
2012-11-11 11:45:03 +00:00
}
tsdemux: GAP detection All pads of a stream are now added at the beginning. In order to cope with streams that don't get any data (forever or for a long time) we detect gaps and push out GAP events when needed. Cleanups and commenting by Jan Schmidt <jan@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=734040
2014-10-20 10:30:50 +00:00
GstClockTime
mpegts_packetizer_get_current_time (MpegTSPacketizer2 * packetizer,
guint16 pcr_pid)
{
MpegTSPCR *pcrtable = get_pcr_table (packetizer, pcr_pid);
if (pcrtable == NULL)
return GST_CLOCK_TIME_NONE;
return mpegts_packetizer_pts_to_ts (packetizer, pcrtable->last_pcrtime,
pcr_pid);
}
mpegtspacketizer: Speed up section parsing Only create subtables when needed. It was previously creating one every single time ... to check if one was present. And speed up code to detect whether a subtable was already present or not. Overall makes section pushing 2 times faster.
2013-06-23 13:12:58 +00:00
static inline MpegTSPacketizerStreamSubtable *
find_subtable (GSList * subtables, guint8 table_id, guint16 subtable_extension)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
mpegtspacketizer: Speed up section parsing Only create subtables when needed. It was previously creating one every single time ... to check if one was present. And speed up code to detect whether a subtable was already present or not. Overall makes section pushing 2 times faster.
2013-06-23 13:12:58 +00:00
GSList *tmp;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* FIXME: Make this an array ! */
mpegtspacketizer: Speed up section parsing Only create subtables when needed. It was previously creating one every single time ... to check if one was present. And speed up code to detect whether a subtable was already present or not. Overall makes section pushing 2 times faster.
2013-06-23 13:12:58 +00:00
for (tmp = subtables; tmp; tmp = tmp->next) {
MpegTSPacketizerStreamSubtable *sub =
(MpegTSPacketizerStreamSubtable *) tmp->data;
if (sub->table_id == table_id
&& sub->subtable_extension == subtable_extension)
return sub;
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: fix find_subtable() return value find_subtable() returns a pointer, so return NULL and not FALSE when nothing is found. https://bugzilla.gnome.org/show_bug.cgi?id=748527
2015-04-27 13:44:28 +00:00
return NULL;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
static gboolean
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
seen_section_before (MpegTSPacketizerStream * stream, guint8 table_id,
guint16 subtable_extension, guint8 version_number, guint8 section_number,
Revert "mpegtspacketizer: memcmp potentially seen_before data" This reverts commit fcad4cc646a23e4e621ec5e8485958ab78d98090. This was wrong is so many ways. * The memcmp was badly used (it should use == 0 to check the data is identical, and not != 0) * There was no boundary checks on the present stream section_data when passing it to memcmp. * The return value should have been TRUE (i.e. we have done all checks, none of them failed, therefore the section has been seen before) * stream->section_data would *always* be NULL if the section had already been processed Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1559 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3421>
2022-11-16 08:42:08 +00:00
guint8 last_section_number)
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
{
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
MpegTSPacketizerStreamSubtable *subtable;
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* Check if we've seen this table_id/subtable_extension first */
subtable = find_subtable (stream->subtables, table_id, subtable_extension);
if (!subtable) {
mpegtspacketizer: Fix typo in debug output
2014-03-29 09:19:52 +00:00
GST_DEBUG ("Haven't seen subtable");
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
return FALSE;
}
/* If we have, check it has the same version_number */
if (subtable->version_number != version_number) {
GST_DEBUG ("Different version number");
return FALSE;
}
/* Did the number of sections change ? */
if (subtable->last_section_number != last_section_number) {
GST_DEBUG ("Different last_section_number");
return FALSE;
}
/* Finally return whether we saw that section or not */
Revert "mpegtspacketizer: memcmp potentially seen_before data" This reverts commit fcad4cc646a23e4e621ec5e8485958ab78d98090. This was wrong is so many ways. * The memcmp was badly used (it should use == 0 to check the data is identical, and not != 0) * There was no boundary checks on the present stream section_data when passing it to memcmp. * The return value should have been TRUE (i.e. we have done all checks, none of them failed, therefore the section has been seen before) * stream->section_data would *always* be NULL if the section had already been processed Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1559 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3421>
2022-11-16 08:42:08 +00:00
return MPEGTS_BIT_IS_SET (subtable->seen_section, section_number);
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
static MpegTSPacketizerStreamSubtable *
mpegts_packetizer_stream_subtable_new (guint8 table_id,
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
guint16 subtable_extension, guint8 last_section_number)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
MpegTSPacketizerStreamSubtable *subtable;
subtable = g_new0 (MpegTSPacketizerStreamSubtable, 1);
subtable->version_number = VERSION_NUMBER_UNSET;
subtable->table_id = table_id;
subtable->subtable_extension = subtable_extension;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
subtable->last_section_number = last_section_number;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
return subtable;
}
static MpegTSPacketizerStream *
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegts_packetizer_stream_new (guint16 pid)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
MpegTSPacketizerStream *stream;
stream = (MpegTSPacketizerStream *) g_new0 (MpegTSPacketizerStream, 1);
stream->continuity_counter = CONTINUITY_UNSET;
stream->subtables = NULL;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
stream->table_id = TABLE_ID_UNSET;
stream->pid = pid;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
return stream;
}
static void
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegts_packetizer_clear_section (MpegTSPacketizerStream * stream)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
stream->continuity_counter = CONTINUITY_UNSET;
stream->section_length = 0;
stream->section_offset = 0;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
stream->table_id = TABLE_ID_UNSET;
Remove unnecessary NULL checks before g_free() g_free() is NULL-safe
2015-11-17 23:23:17 +00:00
g_free (stream->section_data);
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
stream->section_data = NULL;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
static void
mpegts_packetizer_stream_subtable_free (MpegTSPacketizerStreamSubtable *
subtable)
{
g_free (subtable);
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
static void
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegts_packetizer_stream_free (MpegTSPacketizerStream * stream)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegts_packetizer_clear_section (stream);
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
g_slist_foreach (stream->subtables,
(GFunc) mpegts_packetizer_stream_subtable_free, NULL);
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
g_slist_free (stream->subtables);
g_free (stream);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
static void
mpegts_packetizer_class_init (MpegTSPacketizer2Class * klass)
{
GObjectClass *gobject_class;
gobject_class = G_OBJECT_CLASS (klass);
gobject_class->dispose = mpegts_packetizer_dispose;
gobject_class->finalize = mpegts_packetizer_finalize;
}
static void
mpegts_packetizer_init (MpegTSPacketizer2 * packetizer)
{
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
g_mutex_init (&packetizer->group_lock);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packetizer->adapter = gst_adapter_new ();
packetizer->offset = 0;
packetizer->empty = TRUE;
packetizer->streams = g_new0 (MpegTSPacketizerStream *, 8192);
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
packetizer->packet_size = 0;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
packetizer->calculate_skew = FALSE;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
packetizer->calculate_offset = FALSE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_data = NULL;
packetizer->map_size = 0;
packetizer->map_offset = 0;
packetizer->need_sync = FALSE;
mpegtspacketizer: Reduce usage of GstAdapter Peek as much as possible in one go. Ideally we should remove usage of adapter altogether, but for the time being it provides a big enough speedup (around 2 times faster per packet processed).
2012-06-05 07:44:45 +00:00
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
memset (packetizer->pcrtablelut, 0xff, 0x2000);
memset (packetizer->observations, 0x0, sizeof (packetizer->observations));
packetizer->lastobsid = 0;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->nb_seen_offsets = 0;
packetizer->refoffset = -1;
packetizer->last_in_time = GST_CLOCK_TIME_NONE;
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
packetizer->pcr_discont_threshold = GST_SECOND;
tsparse: Forward incoming timestamps Ensure we properly forward the upstream PTS/DTS on the regular and program source pads. All packets being processed will carry over the latest PTS/DTS (as a reconstructed GstBuffer). Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1419 And properly forward PTS/DTS for program pads (which wasn't the case before) Original patch by Vivia Nikolaidou <vivia@ahiru.eu> Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1769>
2020-11-05 11:48:27 +00:00
packetizer->last_pts = GST_CLOCK_TIME_NONE;
packetizer->last_dts = GST_CLOCK_TIME_NONE;
tsdemux: Handle "negative" timestamps This is only enabled in push time mode. Furthermore it's only enabled for now if PCR is to be ignored. The problem is dealing with streams where the initial PTS/DTS observation might be greater than following ones (from other PID for example). Before this patch, this would result in sending buffers without any timestamp which would cause a wide variety of issues. Instead, pad segment and buffer timestamps with an extra value (packetizer->extra_shift, default to 2s), to ensure that we can get valid timestamps on outgoing buffers (even if that means they are before the segment start). Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
2021-09-05 09:57:18 +00:00
packetizer->extra_shift = 0;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
static void
mpegts_packetizer_dispose (GObject * object)
{
MpegTSPacketizer2 *packetizer = GST_MPEGTS_PACKETIZER (object);
if (!packetizer->disposed) {
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
if (packetizer->packet_size)
packetizer->packet_size = 0;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
if (packetizer->streams) {
int i;
for (i = 0; i < 8192; i++) {
if (packetizer->streams[i])
mpegts_packetizer_stream_free (packetizer->streams[i]);
}
g_free (packetizer->streams);
}
gst_adapter_clear (packetizer->adapter);
g_object_unref (packetizer->adapter);
tsdemux: clear mutex resources in dispose https://bugzilla.gnome.org/show_bug.cgi?id=736390
2014-09-10 08:58:03 +00:00
g_mutex_clear (&packetizer->group_lock);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packetizer->disposed = TRUE;
packetizer->offset = 0;
packetizer->empty = TRUE;
mpegtspacketizer: Cache the GIConv Avoids having to constantly open/free them (which will end up being very often with EIT/NIT).
2012-06-29 14:14:02 +00:00
mpegtspacketizer: flush observations too Flush the previous observations when the packetizer is flushed. Also don't leak them in the dispose.
2012-11-11 11:45:03 +00:00
flush_observations (packetizer);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
if (G_OBJECT_CLASS (mpegts_packetizer_parent_class)->dispose)
G_OBJECT_CLASS (mpegts_packetizer_parent_class)->dispose (object);
}
static void
mpegts_packetizer_finalize (GObject * object)
{
if (G_OBJECT_CLASS (mpegts_packetizer_parent_class)->finalize)
G_OBJECT_CLASS (mpegts_packetizer_parent_class)->finalize (object);
}
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
static inline guint64
mpegtsdemux: create function for pcr parsing
2011-02-23 14:21:22 +00:00
mpegts_packetizer_compute_pcr (const guint8 * data)
{
guint32 pcr1;
guint16 pcr2;
guint64 pcr, pcr_ext;
pcr1 = GST_READ_UINT32_BE (data);
pcr2 = GST_READ_UINT16_BE (data + 4);
pcr = ((guint64) pcr1) << 1;
pcr |= (pcr2 & 0x8000) >> 15;
pcr_ext = (pcr2 & 0x01ff);
return pcr * 300 + pcr_ext % 300;
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
static gboolean
mpegts_packetizer_parse_adaptation_field_control (MpegTSPacketizer2 *
packetizer, MpegTSPacketizerPacket * packet)
{
guint8 length, afcflags;
guint8 *data;
length = *packet->data++;
mpegtsdemux: adaptation field length == 0 is valid it can be used to insert a single stuffing byte do not parse the following payload as adaptation field
2011-04-11 12:53:28 +00:00
/* an adaptation field with length 0 is valid and
* can be used to insert a single stuffing byte */
if (!length) {
packet->afc_flags = 0;
return TRUE;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
if ((packet->scram_afc_cc & 0x30) == 0x20) {
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
/* no payload, adaptation field of 183 bytes */
mpegtspacketizer: Skip packets with corrupted length This is similar to what we do for packets with payload
2013-10-11 08:32:52 +00:00
if (length > 183) {
mpegtspacketizer: Unify debug statements Use 0x%04x for PIDs
2015-04-17 13:32:56 +00:00
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d > 183",
mpegtspacketizer: Skip packets with corrupted length This is similar to what we do for packets with payload
2013-10-11 08:32:52 +00:00
packet->pid, packet->scram_afc_cc & 0x30, length);
return FALSE;
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
if (length != 183) {
mpegtspacketizer: Unify debug statements Use 0x%04x for PIDs
2015-04-17 13:32:56 +00:00
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d != 183",
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packet->pid, packet->scram_afc_cc & 0x30, length);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_MEMDUMP ("Unknown payload", packet->data + length,
packet->data_end - packet->data - length);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: be more tolerant when parsing the adaptation field According to the specification, the adaptation field length must be 183 if there is no payload data and < 183 if the packet contains an adaptation field and payload data. Unfortunately some payloaders always set the flag for payload data, even if the adaptation field length is 183. Don't return with an error in this case. Clear the payload data flag instead and parse the adaptation field as usual. This avoids visual artefacts for such streams.
2020-04-06 08:19:23 +00:00
} else if (length == 183) {
/* Note: According to the specification, the adaptation field length
* must be 183 if there is no payload data and < 183 if the packet
* contains an adaptation field and payload data.
* Some payloaders always set the flag for payload data, even if the
* adaptation field length is 183. This just means a zero length
* payload so we clear the payload flag here and continue.
*/
tsdemux: Demote warning to simple debug That issue is actually handled, so don't pollute the logs with such warning. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2340>
2022-05-02 07:15:57 +00:00
GST_DEBUG ("PID 0x%04x afc == 0x%02x and length %d == 183 (ignored)",
mpegtspacketizer: be more tolerant when parsing the adaptation field According to the specification, the adaptation field length must be 183 if there is no payload data and < 183 if the packet contains an adaptation field and payload data. Unfortunately some payloaders always set the flag for payload data, even if the adaptation field length is 183. Don't return with an error in this case. Clear the payload data flag instead and parse the adaptation field as usual. This avoids visual artefacts for such streams.
2020-04-06 08:19:23 +00:00
packet->pid, packet->scram_afc_cc & 0x30, length);
packet->scram_afc_cc &= ~0x10;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
} else if (length > 182) {
mpegtspacketizer: Unify debug statements Use 0x%04x for PIDs
2015-04-17 13:32:56 +00:00
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d > 182",
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packet->pid, packet->scram_afc_cc & 0x30, length);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
return FALSE;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
if (packet->data + length > packet->data_end) {
mpegtspacketizer: Unify debug statements Use 0x%04x for PIDs
2015-04-17 13:32:56 +00:00
GST_DEBUG
("PID 0x%04x afc length %d overflows the buffer current %d max %d",
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packet->pid, length, (gint) (packet->data - packet->data_start),
(gint) (packet->data_end - packet->data_start));
return FALSE;
}
data = packet->data;
packet->data += length;
afcflags = packet->afc_flags = *data++;
mpegtsdemux: Add more flag debugging for PES and TS packets Helps with debugging issues. And also remove unused variable (opcr) This will also allow us in the future to properly detect: * random-access location (to enable keyframe observation and potentially seeking * discont location (to properly handle resets) * splice location (to properly handle new stream changes)
2013-07-26 05:53:06 +00:00
GST_DEBUG ("flags: %s%s%s%s%s%s%s%s%s",
afcflags & 0x80 ? "discontinuity " : "",
afcflags & 0x40 ? "random_access " : "",
afcflags & 0x20 ? "elementary_stream_priority " : "",
afcflags & 0x10 ? "PCR " : "",
afcflags & 0x08 ? "OPCR " : "",
afcflags & 0x04 ? "splicing_point " : "",
afcflags & 0x02 ? "transport_private_data " : "",
afcflags & 0x01 ? "extension " : "", afcflags == 0x00 ? "<none>" : "");
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
/* PCR */
if (afcflags & MPEGTS_AFC_PCR_FLAG) {
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
MpegTSPCR *pcrtable = NULL;
mpegtsdemux: create function for pcr parsing
2011-02-23 14:21:22 +00:00
packet->pcr = mpegts_packetizer_compute_pcr (data);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
data += 6;
GST_DEBUG ("pcr 0x%04x %" G_GUINT64_FORMAT " (%" GST_TIME_FORMAT
") offset:%" G_GUINT64_FORMAT, packet->pid, packet->pcr,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (packet->pcr)), packet->offset);
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
if (packetizer->calculate_skew
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
&& GST_CLOCK_TIME_IS_VALID (packetizer->last_in_time)) {
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcrtable = get_pcr_table (packetizer, packet->pid);
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
calculate_skew (packetizer, pcrtable, packet->pcr,
packetizer->last_in_time);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
}
if (packetizer->calculate_offset) {
if (!pcrtable)
pcrtable = get_pcr_table (packetizer, packet->pid);
record_pcr (packetizer, pcrtable, packet->pcr, packet->offset);
}
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Add more flag debugging for PES and TS packets Helps with debugging issues. And also remove unused variable (opcr) This will also allow us in the future to properly detect: * random-access location (to enable keyframe observation and potentially seeking * discont location (to properly handle resets) * splice location (to properly handle new stream changes)
2013-07-26 05:53:06 +00:00
#ifndef GST_DISABLE_GST_DEBUG
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
/* OPCR */
if (afcflags & MPEGTS_AFC_OPCR_FLAG) {
mpegtsdemux: Add more flag debugging for PES and TS packets Helps with debugging issues. And also remove unused variable (opcr) This will also allow us in the future to properly detect: * random-access location (to enable keyframe observation and potentially seeking * discont location (to properly handle resets) * splice location (to properly handle new stream changes)
2013-07-26 05:53:06 +00:00
/* Note: We don't use/need opcr for the time being */
guint64 opcr = mpegts_packetizer_compute_pcr (data);
data += 6;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
GST_DEBUG ("opcr %" G_GUINT64_FORMAT " (%" GST_TIME_FORMAT ")",
mpegtsdemux: Add more flag debugging for PES and TS packets Helps with debugging issues. And also remove unused variable (opcr) This will also allow us in the future to properly detect: * random-access location (to enable keyframe observation and potentially seeking * discont location (to properly handle resets) * splice location (to properly handle new stream changes)
2013-07-26 05:53:06 +00:00
opcr, GST_TIME_ARGS (PCRTIME_TO_GSTTIME (opcr)));
}
if (afcflags & MPEGTS_AFC_SPLICING_POINT_FLAG) {
GST_DEBUG ("splice_countdown: %u", *data++);
}
if (afcflags & MPEGTS_AFC_TRANSPORT_PRIVATE_DATA_FLAG) {
guint8 len = *data++;
GST_MEMDUMP ("private data", data, len);
data += len;
}
if (afcflags & MPEGTS_AFC_EXTENSION_FLAG) {
guint8 extlen = *data++;
guint8 flags = *data++;
GST_DEBUG ("extension size:%d flags : %s%s%s", extlen,
flags & 0x80 ? "ltw " : "",
flags & 0x40 ? "piecewise_rate " : "",
flags & 0x20 ? "seamless_splice " : "");
if (flags & 0x80) {
GST_DEBUG ("legal time window: valid_flag:%d offset:%d", *data >> 7,
GST_READ_UINT16_BE (data) & 0x7fff);
data += 2;
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Add more flag debugging for PES and TS packets Helps with debugging issues. And also remove unused variable (opcr) This will also allow us in the future to properly detect: * random-access location (to enable keyframe observation and potentially seeking * discont location (to properly handle resets) * splice location (to properly handle new stream changes)
2013-07-26 05:53:06 +00:00
#endif
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
return TRUE;
}
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
static MpegTSPacketizerPacketReturn
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegts_packetizer_parse_packet (MpegTSPacketizer2 * packetizer,
MpegTSPacketizerPacket * packet)
{
guint8 *data;
mpegtspacketizer: Speedup packet parsing Avoid using bitshifting where not needed. Speeds up packet parsing by 3% (this is *the* hotspot of mpeg-ts elements).
2013-06-23 13:26:14 +00:00
guint8 tmp;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
data = packet->data_start;
mpegtspacketizer: Speedup packet parsing Avoid using bitshifting where not needed. Speeds up packet parsing by 3% (this is *the* hotspot of mpeg-ts elements).
2013-06-23 13:26:14 +00:00
data += 1;
tmp = *data;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
/* transport_error_indicator 1 */
mpegtspacketizer: Speedup packet parsing Avoid using bitshifting where not needed. Speeds up packet parsing by 3% (this is *the* hotspot of mpeg-ts elements).
2013-06-23 13:26:14 +00:00
if (G_UNLIKELY (tmp & 0x80))
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
return PACKET_BAD;
/* payload_unit_start_indicator 1 */
mpegtspacketizer: Speedup packet parsing Avoid using bitshifting where not needed. Speeds up packet parsing by 3% (this is *the* hotspot of mpeg-ts elements).
2013-06-23 13:26:14 +00:00
packet->payload_unit_start_indicator = tmp & 0x40;
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
/* transport_priority 1 */
/* PID 13 */
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packet->pid = GST_READ_UINT16_BE (data) & 0x1FFF;
data += 2;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packet->scram_afc_cc = tmp = *data++;
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
/* transport_scrambling_control 2 */
mpegtspacketizer: Speedup packet parsing Avoid using bitshifting where not needed. Speeds up packet parsing by 3% (this is *the* hotspot of mpeg-ts elements).
2013-06-23 13:26:14 +00:00
if (G_UNLIKELY (tmp & 0xc0))
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
return PACKET_BAD;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packet->data = data;
mpegtspacketiser: Always initialise packet AFC flags and PCR fields Also fix a slight typo in a comment about the smoothing algorithm
2014-06-04 11:31:21 +00:00
packet->afc_flags = 0;
packet->pcr = G_MAXUINT64;
if (FLAGS_HAS_AFC (tmp)) {
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
if (!mpegts_packetizer_parse_adaptation_field_control (packetizer, packet))
return FALSE;
mpegtspacketiser: Always initialise packet AFC flags and PCR fields Also fix a slight typo in a comment about the smoothing algorithm
2014-06-04 11:31:21 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: be more tolerant when parsing the adaptation field According to the specification, the adaptation field length must be 183 if there is no payload data and < 183 if the packet contains an adaptation field and payload data. Unfortunately some payloaders always set the flag for payload data, even if the adaptation field length is 183. Don't return with an error in this case. Clear the payload data flag instead and parse the adaptation field as usual. This avoids visual artefacts for such streams.
2020-04-06 08:19:23 +00:00
if (FLAGS_HAS_PAYLOAD (packet->scram_afc_cc))
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
packet->payload = packet->data;
else
packet->payload = NULL;
tsdemux: Detect and handle scrambled packets Users (tsdemux/mpegtsparse) can decide what to do with that
2012-05-18 08:13:19 +00:00
return PACKET_OK;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +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
static GstMpegtsSection *
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegts_packetizer_parse_section_header (MpegTSPacketizer2 * packetizer,
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
MpegTSPacketizerStream * stream)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
MpegTSPacketizerStreamSubtable *subtable;
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 *res;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: Speed up section parsing Only create subtables when needed. It was previously creating one every single time ... to check if one was present. And speed up code to detect whether a subtable was already present or not. Overall makes section pushing 2 times faster.
2013-06-23 13:12:58 +00:00
subtable =
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
find_subtable (stream->subtables, stream->table_id,
stream->subtable_extension);
mpegtspacketizer: Speed up section parsing Only create subtables when needed. It was previously creating one every single time ... to check if one was present. And speed up code to detect whether a subtable was already present or not. Overall makes section pushing 2 times faster.
2013-06-23 13:12:58 +00:00
if (subtable) {
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("Found previous subtable_extension:0x%04x",
stream->subtable_extension);
if (G_UNLIKELY (stream->version_number != subtable->version_number)) {
/* If the version number changed, reset the subtable */
subtable->version_number = stream->version_number;
subtable->last_section_number = stream->last_section_number;
memset (subtable->seen_section, 0, 32);
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
} else {
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("Appending new subtable_extension: 0x%04x",
stream->subtable_extension);
subtable = mpegts_packetizer_stream_subtable_new (stream->table_id,
stream->subtable_extension, stream->last_section_number);
subtable->version_number = stream->version_number;
mpegtspacketizer: Better detect already seen section In some cases (NIT on highly-populated DVB-C operator for example), there will be more than one section emitted for the same subtable and version number. In order not to lose those updates for the same version number, we checked against the CRC of the previous section we parsed. The problem is that, while it made sure we didn't lose any information, it also meant that if the same section came back (same version, same CRC) later on we would re-process it, re-parse it and re-emit it. This version improves on that by keeping a list of previously observed CRC for identical PID/subtable/version-number and will only process sections if they really were never seen in the past (as opposed to just before). On a 30s clip, this brings down the number of NIT section parsing from 4541 down to 663. https://bugzilla.gnome.org/show_bug.cgi?id=614479
2013-06-19 18:39:54 +00:00
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
stream->subtables = g_slist_prepend (stream->subtables, subtable);
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_MEMDUMP ("Full section data", stream->section_data,
stream->section_length);
/* TODO ? : Replace this by an efficient version (where we provide all
* pre-parsed header data) */
res =
gst_mpegts_section_new (stream->pid, stream->section_data,
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
stream->section_length);
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
stream->section_data = NULL;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
mpegts_packetizer_clear_section (stream);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (res) {
/* NOTE : Due to the new mpegts-si system, There is a insanely low probability
* that we might have gotten a section that was corrupted (i.e. wrong crc)
* and that we consider it as seen.
*
* The reason why we consider this as acceptable is because all the previous
* checks were already done:
* * transport layer checks (DVB)
* * 0x47 validation
* * continuity counter validation
* * subtable validation
* * section_number validation
* * section_length validation
*
* The probability of this happening vs the overhead of doing CRC checks
* on all sections (including those we would not use) is just not worth it.
* */
MPEGTS_BIT_SET (subtable->seen_section, stream->section_number);
res->offset = stream->offset;
}
mpegtspacketizer: Clarify debug statements Use hex values in more cases (since that's how PID/table_id/... are represented in the various specs).
2012-06-03 08:58:20 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
return res;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
void
mpegts_packetizer_clear (MpegTSPacketizer2 * packetizer)
mpegtspacketizer: Avoid copying GValueArray Just give the GValueArray to the container GValue.
2013-06-05 09:20:49 +00:00
{
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
guint i;
tsdemux: handle pcr_pid == 0x1fff Streams without PCR make senses in HLS, where the playlist timestamps can be used to seek or calculate the duration. https://bugzilla.gnome.org/show_bug.cgi?id=608148
2016-05-31 11:09:43 +00:00
MpegTSPCR *pcrtable;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
mpegtspacketizer: simplify variable reset Just set it directly to 0, instead of checking and reseting
2016-03-03 14:31:01 +00:00
packetizer->packet_size = 0;
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (packetizer->streams) {
int i;
for (i = 0; i < 8192; i++) {
if (packetizer->streams[i]) {
mpegts_packetizer_stream_free (packetizer->streams[i]);
}
}
memset (packetizer->streams, 0, 8192 * sizeof (MpegTSPacketizerStream *));
}
mpegtspacketizer: Avoid copying GValueArray Just give the GValueArray to the container GValue.
2013-06-05 09:20:49 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
gst_adapter_clear (packetizer->adapter);
packetizer->offset = 0;
packetizer->empty = TRUE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->need_sync = FALSE;
packetizer->map_data = NULL;
packetizer->map_size = 0;
packetizer->map_offset = 0;
packetizer->last_in_time = GST_CLOCK_TIME_NONE;
tsparse: Forward incoming timestamps Ensure we properly forward the upstream PTS/DTS on the regular and program source pads. All packets being processed will carry over the latest PTS/DTS (as a reconstructed GstBuffer). Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1419 And properly forward PTS/DTS for program pads (which wasn't the case before) Original patch by Vivia Nikolaidou <vivia@ahiru.eu> Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1769>
2020-11-05 11:48:27 +00:00
packetizer->last_pts = GST_CLOCK_TIME_NONE;
packetizer->last_dts = GST_CLOCK_TIME_NONE;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
tsdemux: handle pcr_pid == 0x1fff Streams without PCR make senses in HLS, where the playlist timestamps can be used to seek or calculate the duration. https://bugzilla.gnome.org/show_bug.cgi?id=608148
2016-05-31 11:09:43 +00:00
pcrtable = packetizer->observations[packetizer->pcrtablelut[0x1fff]];
if (pcrtable)
pcrtable->base_time = GST_CLOCK_TIME_NONE;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Close current PCR group */
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
for (i = 0; i < MAX_PCR_OBS_CHANNELS; i++) {
if (packetizer->observations[i])
_close_current_group (packetizer->observations[i]);
else
break;
}
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Avoid copying GValueArray Just give the GValueArray to the container GValue.
2013-06-05 09:20:49 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
void
mpegts_packetizer_flush (MpegTSPacketizer2 * packetizer, gboolean hard)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
guint i;
tsdemux: handle pcr_pid == 0x1fff Streams without PCR make senses in HLS, where the playlist timestamps can be used to seek or calculate the duration. https://bugzilla.gnome.org/show_bug.cgi?id=608148
2016-05-31 11:09:43 +00:00
MpegTSPCR *pcrtable;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("Flushing");
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (packetizer->streams) {
for (i = 0; i < 8192; i++) {
if (packetizer->streams[i]) {
mpegts_packetizer_clear_section (packetizer->streams[i]);
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
gst_adapter_clear (packetizer->adapter);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packetizer->offset = 0;
packetizer->empty = TRUE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->need_sync = FALSE;
packetizer->map_data = NULL;
packetizer->map_size = 0;
packetizer->map_offset = 0;
packetizer->last_in_time = GST_CLOCK_TIME_NONE;
tsparse: Forward incoming timestamps Ensure we properly forward the upstream PTS/DTS on the regular and program source pads. All packets being processed will carry over the latest PTS/DTS (as a reconstructed GstBuffer). Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1419 And properly forward PTS/DTS for program pads (which wasn't the case before) Original patch by Vivia Nikolaidou <vivia@ahiru.eu> Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1769>
2020-11-05 11:48:27 +00:00
packetizer->last_pts = GST_CLOCK_TIME_NONE;
packetizer->last_dts = GST_CLOCK_TIME_NONE;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
tsdemux: handle pcr_pid == 0x1fff Streams without PCR make senses in HLS, where the playlist timestamps can be used to seek or calculate the duration. https://bugzilla.gnome.org/show_bug.cgi?id=608148
2016-05-31 11:09:43 +00:00
pcrtable = packetizer->observations[packetizer->pcrtablelut[0x1fff]];
if (pcrtable)
pcrtable->base_time = GST_CLOCK_TIME_NONE;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Close current PCR group */
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
for (i = 0; i < MAX_PCR_OBS_CHANNELS; i++) {
if (packetizer->observations[i])
_close_current_group (packetizer->observations[i]);
else
break;
}
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (hard) {
/* For pull mode seeks in tsdemux the observation must be preserved */
flush_observations (packetizer);
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
void
mpegts_packetizer_remove_stream (MpegTSPacketizer2 * packetizer, gint16 pid)
{
MpegTSPacketizerStream *stream = packetizer->streams[pid];
if (stream) {
mpegtspacketizer: Unify debug statements Use 0x%04x for PIDs
2015-04-17 13:32:56 +00:00
GST_INFO ("Removing stream for PID 0x%04x", pid);
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegts_packetizer_stream_free (stream);
packetizer->streams[pid] = NULL;
mpegtspacketizer: Speed up descriptor parsing/packing descriptors are stored as a GValueArray of GString. The downside is that there is no way to "pass" ownership of a GValue to a GValueArray which previously resulted in expensive copy/free of the (already expensive) GString. Here we estimate first the size of the GValueArray, then create it, then directly use the GValue of that array. Speeds up total SI parsing by ~30%
2013-06-05 10:49:09 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
MpegTSPacketizer2 *
mpegts_packetizer_new (void)
mpegtsbase/packetizer: Add CAT section handling Allows reporting the global EMM
2012-06-03 08:56:28 +00:00
{
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
MpegTSPacketizer2 *packetizer;
mpegtsbase/packetizer: Add CAT section handling Allows reporting the global EMM
2012-06-03 08:56:28 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packetizer =
GST_MPEGTS_PACKETIZER (g_object_new (GST_TYPE_MPEGTS_PACKETIZER, NULL));
mpegtsbase/packetizer: Add CAT section handling Allows reporting the global EMM
2012-06-03 08:56:28 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
return packetizer;
mpegtsbase/packetizer: Add CAT section handling Allows reporting the global EMM
2012-06-03 08:56:28 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
void
mpegts_packetizer_push (MpegTSPacketizer2 * packetizer, GstBuffer * buffer)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
tsdemux: Skew correction should use the upstream DTS The MPEG-TS packetiser should use the upstream DTS for skew correction when running in that mode, as the DTS carries the upstream arrival time. The PTS (if it's set at all) is less useful, and can be invalid.
2019-02-12 13:54:50 +00:00
GstClockTime ts;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (G_UNLIKELY (packetizer->empty)) {
packetizer->empty = FALSE;
packetizer->offset = GST_BUFFER_OFFSET (buffer);
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("Pushing %" G_GSIZE_FORMAT " byte from offset %"
G_GUINT64_FORMAT, gst_buffer_get_size (buffer),
GST_BUFFER_OFFSET (buffer));
gst_adapter_push (packetizer->adapter, buffer);
tsdemux: Skew correction should use the upstream DTS The MPEG-TS packetiser should use the upstream DTS for skew correction when running in that mode, as the DTS carries the upstream arrival time. The PTS (if it's set at all) is less useful, and can be invalid.
2019-02-12 13:54:50 +00:00
/* If the buffer has a valid timestamp, store it - preferring DTS,
* which is where upstream arrival times should be stored */
ts = GST_BUFFER_DTS_OR_PTS (buffer);
if (GST_CLOCK_TIME_IS_VALID (ts))
packetizer->last_in_time = ts;
tsparse: Forward incoming timestamps Ensure we properly forward the upstream PTS/DTS on the regular and program source pads. All packets being processed will carry over the latest PTS/DTS (as a reconstructed GstBuffer). Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1419 And properly forward PTS/DTS for program pads (which wasn't the case before) Original patch by Vivia Nikolaidou <vivia@ahiru.eu> Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1769>
2020-11-05 11:48:27 +00:00
packetizer->last_pts = GST_BUFFER_PTS (buffer);
packetizer->last_dts = GST_BUFFER_DTS (buffer);
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
static void
mpegts_packetizer_flush_bytes (MpegTSPacketizer2 * packetizer, gsize size)
{
if (size > 0) {
GST_LOG ("flushing %" G_GSIZE_FORMAT " bytes from adapter", size);
gst_adapter_flush (packetizer->adapter, size);
}
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_data = NULL;
packetizer->map_size = 0;
packetizer->map_offset = 0;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
}
static gboolean
mpegts_packetizer_map (MpegTSPacketizer2 * packetizer, gsize size)
{
gsize available;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
if (packetizer->map_size - packetizer->map_offset >= size)
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return TRUE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
available = gst_adapter_available (packetizer->adapter);
if (available < size)
return FALSE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_data =
(guint8 *) gst_adapter_map (packetizer->adapter, available);
if (!packetizer->map_data)
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return FALSE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_size = available;
packetizer->map_offset = 0;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
GST_LOG ("mapped %" G_GSIZE_FORMAT " bytes from adapter", available);
return TRUE;
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
static gboolean
mpegts_try_discover_packet_size (MpegTSPacketizer2 * packetizer)
{
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
guint8 *data;
gsize size, i, j;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
static const guint psizes[] = {
MPEGTS_NORMAL_PACKETSIZE,
MPEGTS_M2TS_PACKETSIZE,
MPEGTS_DVB_ASI_PACKETSIZE,
MPEGTS_ATSC_PACKETSIZE
};
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (!mpegts_packetizer_map (packetizer, 4 * MPEGTS_MAX_PACKETSIZE))
return FALSE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
size = packetizer->map_size - packetizer->map_offset;
data = packetizer->map_data + packetizer->map_offset;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
for (i = 0; i + 3 * MPEGTS_MAX_PACKETSIZE < size; i++) {
/* find a sync byte */
if (data[i] != PACKET_SYNC_BYTE)
continue;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
/* check for 4 consecutive sync bytes with each possible packet size */
for (j = 0; j < G_N_ELEMENTS (psizes); j++) {
guint packet_size = psizes[j];
if (data[i + packet_size] == PACKET_SYNC_BYTE &&
data[i + 2 * packet_size] == PACKET_SYNC_BYTE &&
data[i + 3 * packet_size] == PACKET_SYNC_BYTE) {
packetizer->packet_size = packet_size;
goto out;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
out:
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_offset += i;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (packetizer->packet_size == 0) {
GST_DEBUG ("Could not determine packet size in %" G_GSIZE_FORMAT
" bytes buffer, flush %" G_GSIZE_FORMAT " bytes", size, i);
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return FALSE;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
GST_INFO ("have packetsize detected: %u bytes", packetizer->packet_size);
if (packetizer->packet_size == MPEGTS_M2TS_PACKETSIZE &&
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_offset >= 4)
packetizer->map_offset -= 4;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return TRUE;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
static gboolean
mpegts_packetizer_sync (MpegTSPacketizer2 * packetizer)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
{
mpegtsdemux: fix uninitialized variable warning https://bugzilla.gnome.org/show_bug.cgi?id=710759
2013-10-23 15:58:49 +00:00
gboolean found = FALSE;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
guint8 *data;
guint packet_size;
gsize size, sync_offset, i;
packet_size = packetizer->packet_size;
if (!mpegts_packetizer_map (packetizer, 3 * packet_size))
return FALSE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
size = packetizer->map_size - packetizer->map_offset;
data = packetizer->map_data + packetizer->map_offset;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (packet_size == MPEGTS_M2TS_PACKETSIZE)
sync_offset = 4;
else
sync_offset = 0;
for (i = sync_offset; i + 2 * packet_size < size; i++) {
if (data[i] == PACKET_SYNC_BYTE &&
data[i + packet_size] == PACKET_SYNC_BYTE &&
data[i + 2 * packet_size] == PACKET_SYNC_BYTE) {
found = TRUE;
break;
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->map_offset += i - sync_offset;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (!found)
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return found;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
MpegTSPacketizerPacketReturn
mpegts_packetizer_next_packet (MpegTSPacketizer2 * packetizer,
MpegTSPacketizerPacket * packet)
{
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
guint8 *packet_data;
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
guint packet_size;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
gsize sync_offset;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
packet_size = packetizer->packet_size;
if (G_UNLIKELY (!packet_size)) {
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
if (!mpegts_try_discover_packet_size (packetizer))
return PACKET_NEED_MORE;
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
packet_size = packetizer->packet_size;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
/* M2TS packets don't start with the sync byte, all other variants do */
if (packet_size == MPEGTS_M2TS_PACKETSIZE)
sync_offset = 4;
else
sync_offset = 0;
while (1) {
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
if (packetizer->need_sync) {
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (!mpegts_packetizer_sync (packetizer))
return PACKET_NEED_MORE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->need_sync = FALSE;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (!mpegts_packetizer_map (packetizer, packet_size))
return PACKET_NEED_MORE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packet_data = &packetizer->map_data[packetizer->map_offset + sync_offset];
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
/* Check sync byte */
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (G_UNLIKELY (*packet_data != PACKET_SYNC_BYTE)) {
GST_DEBUG ("lost sync");
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->need_sync = TRUE;
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
} else {
tsdemux: fix M2TS stream resync Sync byte scan is incorrect for M2TS streams because the timestamp 4 bytes were not included in the flush size. This can result in an infinite loop. Rework the scan code to be clearer and work in all cases.
2013-05-27 20:22:32 +00:00
/* ALL mpeg-ts variants contain 188 bytes of data. Those with bigger
* packet sizes contain either extra data (timesync, FEC, ..) either
* before or after the data */
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
packet->data_start = packet_data;
tsdemux: fix M2TS stream resync Sync byte scan is incorrect for M2TS streams because the timestamp 4 bytes were not included in the flush size. This can result in an infinite loop. Rework the scan code to be clearer and work in all cases.
2013-05-27 20:22:32 +00:00
packet->data_end = packet->data_start + 188;
packet->offset = packetizer->offset;
GST_LOG ("offset %" G_GUINT64_FORMAT, packet->offset);
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
packetizer->offset += packet_size;
tsdemux: fix M2TS stream resync Sync byte scan is incorrect for M2TS streams because the timestamp 4 bytes were not included in the flush size. This can result in an infinite loop. Rework the scan code to be clearer and work in all cases.
2013-05-27 20:22:32 +00:00
GST_MEMDUMP ("data_start", packet->data_start, 16);
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return mpegts_packetizer_parse_packet (packetizer, packet);
mpegtspacketizer: Reduce usage of GstAdapter Peek as much as possible in one go. Ideally we should remove usage of adapter altogether, but for the time being it provides a big enough speedup (around 2 times faster per packet processed).
2012-06-05 07:44:45 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
}
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
MpegTSPacketizerPacketReturn
mpegts_packetizer_process_next_packet (MpegTSPacketizer2 * packetizer)
{
MpegTSPacketizerPacket packet;
mpegtspacketizer: Don't leak buffer in fast variant
2012-04-02 13:25:46 +00:00
MpegTSPacketizerPacketReturn ret;
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
mpegtspacketizer: Don't leak buffer in fast variant
2012-04-02 13:25:46 +00:00
ret = mpegts_packetizer_next_packet (packetizer, &packet);
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
if (ret != PACKET_NEED_MORE)
mpegts_packetizer_clear_packet (packetizer, &packet);
mpegtspacketizer: Don't leak buffer in fast variant
2012-04-02 13:25:46 +00:00
return ret;
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
}
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
void
mpegts_packetizer_clear_packet (MpegTSPacketizer2 * packetizer,
MpegTSPacketizerPacket * packet)
{
mpegtsdemux: Remove unneeded variables * packet.origts is no longer used since the PCR refactoring done ages ago * known_packet_size is a duplicate of packet_size != 0 * caps was never used outside of the packetizer
2013-07-07 08:25:27 +00:00
guint8 packet_size = packetizer->packet_size;
mpegtspacketizer: Fix flushing/sync handling There was a stray adapter_flush() now that we used a temporary buffer
2012-07-24 18:39:41 +00:00
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
if (packetizer->map_data) {
packetizer->map_offset += packet_size;
if (packetizer->map_size - packetizer->map_offset < packet_size)
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
}
}
mpegtspacketizer: Fix flushing/sync handling There was a stray adapter_flush() now that we used a temporary buffer
2012-07-24 18:39:41 +00:00
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
gboolean
mpegts_packetizer_has_packets (MpegTSPacketizer2 * packetizer)
{
if (G_UNLIKELY (!packetizer->packet_size)) {
if (!mpegts_try_discover_packet_size (packetizer))
return FALSE;
mpegtspacketizer: Reduce usage of GstAdapter Peek as much as possible in one go. Ideally we should remove usage of adapter altogether, but for the time being it provides a big enough speedup (around 2 times faster per packet processed).
2012-06-05 07:44:45 +00:00
}
mpegtspacketizer: rework TS packet sync and extraction The previous code could enter an infinite loop because the adapter state could get out of sync with its mapped data state after sync was lost. The code was pretty confusing so it's been rewritten to be clearer. The easiest way to reproduce the infinite loop is to use the breakmydata element before tsdemux to trigger a resync. https://bugzilla.gnome.org/show_bug.cgi?id=708161
2013-09-16 09:46:27 +00:00
return gst_adapter_available (packetizer->adapter) >= packetizer->packet_size;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/*
* Ideally it should just return a section if:
* * The section is complete
* * The section is valid (sanity checks for length for example)
* * The section applies now (current_next_indicator)
* * The section is an update or was never seen
*
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
* The section should be a new GstMpegtsSection:
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
* * properly initialized
* * With pid, table_id AND section_type set (move logic from mpegtsbase)
* * With data copied into it (yes, minor overhead)
*
* In all other cases it should just return NULL
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
*
* If more than one section is available, the 'remaining' field will
* be set to the beginning of a valid GList containing other sections.
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +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 *
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegts_packetizer_push_section (MpegTSPacketizer2 * packetizer,
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
MpegTSPacketizerPacket * packet, GList ** remaining)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +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 *section;
GstMpegtsSection *res = NULL;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
MpegTSPacketizerStream *stream;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
gboolean long_packet;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
guint8 pointer = 0, table_id;
mpegtspacketizer: Reset values before parsing each section
2016-11-22 10:58:44 +00:00
guint16 subtable_extension;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
gsize to_read;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
guint section_length;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* data points to the current read location
* data_start points to the beginning of the data to accumulate */
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
guint8 *data, *data_start;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
guint8 packet_cc;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
GList *others = NULL;
guint8 version_number, section_number, last_section_number;
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
gboolean cc_discont = FALSE;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
data = packet->data;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packet_cc = FLAGS_CONTINUITY_COUNTER (packet->scram_afc_cc);
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Get our filter */
stream = packetizer->streams[packet->pid];
if (G_UNLIKELY (stream == NULL)) {
if (!packet->payload_unit_start_indicator) {
/* Early exit (we need to start with a section start) */
GST_DEBUG ("PID 0x%04x waiting for section start", packet->pid);
goto out;
}
stream = mpegts_packetizer_stream_new (packet->pid);
packetizer->streams[packet->pid] = stream;
}
GST_MEMDUMP ("Full packet data", packet->data,
packet->data_end - packet->data);
/* This function is split into several parts:
*
* Pre checks (packet-wide). Determines where we go next
* accumulate_data: store data and check if section is complete
* section_start: handle beginning of a section, if needed loop back to
* accumulate_data
*
* The trigger that makes the loop stop and return is if:
* 1) We do not have enough data for the current packet
* 2) There is remaining data after a packet which is only made
* of stuffing bytes (0xff).
*
* Pre-loop checks, related to the whole incoming packet:
*
* If there is a CC-discont:
* If it is a PUSI, skip the pointer and handle section_start
* If not a PUSI, reset and return nothing
* If there is not a CC-discont:
* If it is a PUSI
* If pointer, accumulate that data and check for complete section
* (loop)
* If it is not a PUSI
* Accumulate the expected data and check for complete section
* (loop)
mpegtsdemux: Deliver all packets to tsparse 34af8ed66a7c63048ce0bdf59bbe61011d7c6292 changed the code to use the packetizer's packets instead of the incoming buffers, but mpegtsbase didn't actually push all packets to the subclass. As a result, padding (PID 0x1FFF) packets got lost. Add a new boolean to toggle pushing unknown packets to mpegtsbase and have mpegtsparse make use of it. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1300>
2020-05-26 20:40:04 +00:00
*
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
**/
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
if (packet->payload_unit_start_indicator)
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
pointer = *data++;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
if (stream->continuity_counter == CONTINUITY_UNSET ||
(stream->continuity_counter + 1) % 16 != packet_cc) {
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
if (stream->continuity_counter != CONTINUITY_UNSET) {
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
GST_WARNING ("PID 0x%04x section discontinuity (%d vs %d)", packet->pid,
stream->continuity_counter, packet_cc);
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
cc_discont = TRUE;
}
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
mpegts_packetizer_clear_section (stream);
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
stream->continuity_counter = packet_cc;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* If not a PUSI, not much we can do */
if (!packet->payload_unit_start_indicator) {
GST_LOG ("PID 0x%04x continuity discont/unset and not PUSI, bailing out",
packet->pid);
goto out;
}
/* If PUSI, skip pointer data and carry on to section start */
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
data += pointer;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
pointer = 0;
GST_LOG ("discont, but PUSI, skipped %d bytes and doing section start",
pointer);
goto section_start;
}
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
if (packet->payload_unit_start_indicator && pointer == 0) {
/* If the pointer is zero, we're guaranteed to be able to handle it */
GST_LOG
("PID 0x%04x PUSI and pointer == 0, skipping straight to section_start parsing",
packet->pid);
mpegts_packetizer_clear_section (stream);
stream->continuity_counter = packet_cc;
goto section_start;
}
stream->continuity_counter = packet_cc;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
GST_LOG ("Accumulating data from beginning of packet");
data_start = data;
accumulate_data:
/* If not the beginning of a new section, accumulate what we have */
stream->continuity_counter = packet_cc;
to_read = MIN (stream->section_length - stream->section_offset,
packet->data_end - data_start);
memcpy (stream->section_data + stream->section_offset, data_start, to_read);
stream->section_offset += to_read;
/* Point data to after the data we accumulated */
data = data_start + to_read;
GST_DEBUG ("Appending data (need %d, have %d)", stream->section_length,
stream->section_offset);
/* Check if we have enough */
if (stream->section_offset < stream->section_length) {
GST_DEBUG ("PID 0x%04x, section not complete (Got %d, need %d)",
stream->pid, stream->section_offset, stream->section_length);
goto out;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Small sanity check. We should have collected *exactly* the right amount */
if (G_UNLIKELY (stream->section_offset != stream->section_length))
GST_WARNING ("PID 0x%04x Accumulated too much data (%d vs %d) !",
stream->pid, stream->section_offset, stream->section_length);
GST_DEBUG ("PID 0x%04x Section complete", stream->pid);
if ((section = mpegts_packetizer_parse_section_header (packetizer, stream))) {
if (res)
others = g_list_append (others, section);
else
res = section;
}
mpegtspacketizer: Make sure in all cases that we have enough data left for reading a section start In some cases we ended up parsing sections without.
2016-11-22 10:42:45 +00:00
section_start:
mpegtspacketizer: Reset values before parsing each section
2016-11-22 10:58:44 +00:00
subtable_extension = 0;
version_number = 0;
last_section_number = 0;
section_number = 0;
table_id = 0;
mpegtspacketizer: Make sure in all cases that we have enough data left for reading a section start In some cases we ended up parsing sections without.
2016-11-22 10:42:45 +00:00
/* FIXME : We need at least 3 bytes (or 8 for long packets) with current algorithm :(
mpegtsdemux: Avoid parsing section without enough data This is actually a workaround (we'll be skipping the upcoming section) This will only happen for sections where the beginning is located within the last 8 bytes of a packet (which is the minimum we need to properly identify any section beginning). Later we should figure out a way to store those bytes and mark that some analysis needs to happen. The probability of this happening is too low for me to care right now and do that fix. There is a good chance that section will eventually be repeated and won't end up on such border.
2013-07-08 06:44:43 +00:00
* We might end up losing sections that start across two packets (srsl...) */
mpegtspacketizer: Make sure in all cases that we have enough data left for reading a section start In some cases we ended up parsing sections without.
2016-11-22 10:42:45 +00:00
if (data > packet->data_end - 3 || *data == 0xff) {
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* flush stuffing bytes and leave */
mpegts_packetizer_clear_section (stream);
goto out;
}
/* We have more data to process ... */
GST_DEBUG ("PID 0x%04x, More section present in packet (remaining bytes:%"
mpegtspacketizer: Fix format string compiler warning
2014-11-24 12:28:42 +00:00
G_GSIZE_FORMAT ")", stream->pid, (gsize) (packet->data_end - data));
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
GST_MEMDUMP ("section_start", data, packet->data_end - data);
data_start = data;
/* Beginning of a new section */
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/*
* section_syntax_indicator means that the header is of the following format:
* * table_id (8bit)
* * section_syntax_indicator (1bit) == 0
* * reserved/private fields (3bit)
* * section_length (12bit)
* * data (of size section_length)
* * NO CRC !
*/
long_packet = data[1] & 0x80;
/* Fast path for short packets */
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
if (!long_packet) {
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* We can create the section now (function will check for size) */
GST_DEBUG ("Short packet");
section_length = (GST_READ_UINT16_BE (data + 1) & 0xfff) + 3;
/* Only do fast-path if we have enough byte */
mpegtspacketizer: Fix off-by-one error This went un-noticed for 6 years :( The issue is that for short sections (without subtables and CRC), we would always fail when checking whether we had enough data or not and then default to the long section checking. Use the long section checking would then cause interesting side-effects for short sections (such as believing they were already seen and therefore would be dropped/ignored).
2019-09-26 15:13:30 +00:00
if (data + section_length <= packet->data_end) {
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
if ((section =
Use g_memdup2() where available and add fallback for older GLib versions g_memdup() is deprecated since GLib 2.68 and we want to avoid deprecation warnings with recent versions of GLib. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2280>
2021-05-23 18:15:25 +00:00
gst_mpegts_section_new (packet->pid, g_memdup2 (data,
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
section_length), section_length))) {
GST_DEBUG ("PID 0x%04x Short section complete !", packet->pid);
section->offset = packet->offset;
if (res)
others = g_list_append (others, section);
else
res = section;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
}
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Advance reader and potentially read another section */
data += section_length;
if (data < packet->data_end && *data != 0xff)
goto section_start;
/* If not, exit */
mpegtspacketizer: catch section lengths extending past the buffer length This is probably the cause for an occasional crash while streaming MPEG. Blind fix after staring at the code and following logic, so may or may not fix the issue, I cannot test. (Port of 4275a70cb55d375afa702917f7359ec117ed49d4 from mpegdemux)
2012-02-27 12:45:29 +00:00
goto out;
}
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* We don't have enough bytes to do short section shortcut */
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
}
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Beginning of a new section, do as much pre-parsing as possible */
/* table_id : 8 bit */
table_id = *data++;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* section_syntax_indicator : 1 bit
* other_fields (reserved) : 3 bit
* section_length : 12 bit */
section_length = (GST_READ_UINT16_BE (data) & 0x0FFF) + 3;
data += 2;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
if (long_packet) {
mpegtspacketizer: Make sure in all cases that we have enough data left for reading a section start In some cases we ended up parsing sections without.
2016-11-22 10:42:45 +00:00
/* Do we have enough data for a long packet? */
if (data > packet->data_end - 5)
goto out;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* subtable_extension (always present, we are in a long section) */
/* subtable extension : 16 bit */
subtable_extension = GST_READ_UINT16_BE (data);
data += 2;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
/* reserved : 2 bit
* version_number : 5 bit
* current_next_indicator : 1 bit */
/* Bail out now if current_next_indicator == 0 */
mpegtspacketizer: Correct condition check for current next indicator https://bugzilla.gnome.org/show_bug.cgi?id=708106
2013-09-15 11:39:16 +00:00
if (G_UNLIKELY (!(*data & 0x01))) {
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
GST_DEBUG
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
("PID 0x%04x table_id 0x%02x section does not apply (current_next_indicator == 0)",
packet->pid, table_id);
goto out;
}
version_number = *data++ >> 1 & 0x1f;
/* section_number : 8 bit */
section_number = *data++;
/* last_section_number : 8 bit */
last_section_number = *data++;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
} else {
subtable_extension = 0;
version_number = 0;
section_number = 0;
last_section_number = 0;
}
GST_DEBUG
("PID 0x%04x length:%d table_id:0x%02x subtable_extension:0x%04x version_number:%d section_number:%d(last:%d)",
packet->pid, section_length, table_id, subtable_extension, version_number,
section_number, last_section_number);
to_read = MIN (section_length, packet->data_end - data_start);
/* Check as early as possible whether we already saw this section
* i.e. that we saw a subtable with:
* * same subtable_extension (might be zero)
* * same version_number
* * same last_section_number
* * same section_number was seen
*/
mpegts: Check continuity counter on section streams This wasn't really done, and is needed in order to detect potential section changes for sections that have got identical information (such as when switching between streams that have the same PAT/PMT pid and subtable information). Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
2022-12-06 10:30:47 +00:00
if (!cc_discont && seen_section_before (stream, table_id, subtable_extension,
Revert "mpegtspacketizer: memcmp potentially seen_before data" This reverts commit fcad4cc646a23e4e621ec5e8485958ab78d98090. This was wrong is so many ways. * The memcmp was badly used (it should use == 0 to check the data is identical, and not != 0) * There was no boundary checks on the present stream section_data when passing it to memcmp. * The return value should have been TRUE (i.e. we have done all checks, none of them failed, therefore the section has been seen before) * stream->section_data would *always* be NULL if the section had already been processed Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1559 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3421>
2022-11-16 08:42:08 +00:00
version_number, section_number, last_section_number)) {
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
("PID 0x%04x Already processed table_id:0x%02x subtable_extension:0x%04x, version_number:%d, section_number:%d",
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
packet->pid, table_id, subtable_extension, version_number,
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
section_number);
/* skip data and see if we have more sections after */
data = data_start + to_read;
if (data == packet->data_end || *data == 0xff)
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
goto out;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
goto section_start;
}
if (G_UNLIKELY (section_number > last_section_number)) {
GST_WARNING
("PID 0x%04x corrupted packet (section_number:%d > last_section_number:%d)",
packet->pid, section_number, last_section_number);
goto out;
}
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Copy over already parsed values */
stream->table_id = table_id;
stream->section_length = section_length;
stream->version_number = version_number;
stream->subtable_extension = subtable_extension;
stream->section_number = section_number;
stream->last_section_number = last_section_number;
stream->offset = packet->offset;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Create enough room to store chunks of sections */
stream->section_data = g_malloc (stream->section_length);
stream->section_offset = 0;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
/* Finally, accumulate and check if we parsed enough */
goto accumulate_data;
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
out:
packet->data = data;
mpegtsdemux: Fix multiple-SI detection/parsing We had two issues with the previous code: 1) We were badly handling PUSI-flagged packets. We were discarding the initial data (if pointer != 0) whereas we should have been accumulating it with the previous data (if there was a continuity of course). => First series of information loss 2) We were not checking whether there were more sections after the end of one (i.e. when the following byte was not a stuff byte). This fixes those two issues. Fixes #677443 https://bugzilla.gnome.org/show_bug.cgi?id=677443
2013-07-07 06:29:37 +00:00
*remaining = others;
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("result: %p", res);
mpegtspacketizer: Avoid usage of GstBuffer internally The overhead of creating/using 188 byte GstBuffer from GstAdapter is too expensive. We now peek the next packet, and provide a data/size which is only valid until the packetizerpacket is cleared. In addition, cleanup all the internal code to deal with that new behaviour and remove double-checks which are no longer needed. The section_length is now the corrected section_length (i.e. with the additional 3 bytes). Avoid using gst_adapter_prev_timestamp and instead track the timestamp ourself.
2012-05-21 15:48:54 +00:00
mpegtsdemux: add MPEG TS demuxer rewrite from Edward Hervey with contributions from Miquel Angel Farre Guiu and Zaheer Abbas Merali
2011-02-16 16:57:42 +00:00
return res;
}
static void
_init_local (void)
{
GST_DEBUG_CATEGORY_INIT (mpegts_packetizer_debug, "mpegtspacketizer", 0,
"MPEG transport stream parser");
}
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
static void
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
mpegts_packetizer_resync (MpegTSPCR * pcr, GstClockTime time,
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
GstClockTime gstpcrtime, gboolean reset_skew)
{
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->base_time = time;
pcr->base_pcrtime = gstpcrtime;
pcr->prev_out_time = GST_CLOCK_TIME_NONE;
pcr->prev_send_diff = GST_CLOCK_TIME_NONE;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
if (reset_skew) {
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window_filling = TRUE;
pcr->window_pos = 0;
pcr->window_min = 0;
pcr->window_size = 0;
pcr->skew = 0;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
}
/* Code mostly copied from -good/gst/rtpmanager/rtpjitterbuffer.c */
/* For the clock skew we use a windowed low point averaging algorithm as can be
* found in Fober, Orlarey and Letz, 2005, "Real Time Clock Skew Estimation
* over Network Delays":
* http://www.grame.fr/Ressources/pub/TR-050601.pdf
* http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1546
*
* The idea is that the jitter is composed of:
*
mpegtsdemux: Fix comment about the jitter description According to the information provided below, the Jitter (J) is defined by a network delay (D) + a noise(i) Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5494>
2023-10-16 20:58:24 +00:00
* J = D + n
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
*
mpegtspacketiser: Always initialise packet AFC flags and PCR fields Also fix a slight typo in a comment about the smoothing algorithm
2014-06-04 11:31:21 +00:00
* D : a constant network delay.
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
* n : random added noise. The noise is concentrated around 0
*
* In the receiver we can track the elapsed time at the sender with:
*
* send_diff(i) = (Tsi - Ts0);
*
* Tsi : The time at the sender at packet i
* Ts0 : The time at the sender at the first packet
*
* This is the difference between the RTP timestamp in the first received packet
* and the current packet.
*
* At the receiver we have to deal with the jitter introduced by the network.
*
* recv_diff(i) = (Tri - Tr0)
*
* Tri : The time at the receiver at packet i
* Tr0 : The time at the receiver at the first packet
*
* Both of these values contain a jitter Ji, a jitter for packet i, so we can
* write:
*
* recv_diff(i) = (Cri + D + ni) - (Cr0 + D + n0))
*
* Cri : The time of the clock at the receiver for packet i
* D + ni : The jitter when receiving packet i
*
documentation: fixed a heap o' typos
2019-09-02 19:08:44 +00:00
* We see that the network delay is irrelevant here as we can eliminate D:
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
*
* recv_diff(i) = (Cri + ni) - (Cr0 + n0))
*
* The drift is now expressed as:
*
* Drift(i) = recv_diff(i) - send_diff(i);
*
* We now keep the W latest values of Drift and find the minimum (this is the
* one with the lowest network jitter and thus the one which is least affected
* by it). We average this lowest value to smooth out the resulting network skew.
*
* Both the window and the weighting used for averaging influence the accuracy
* of the drift estimation. Finding the correct parameters turns out to be a
* compromise between accuracy and inertia.
*
* We use a 2 second window or up to 512 data points, which is statistically big
* enough to catch spikes (FIXME, detect spikes).
* We also use a rather large weighting factor (125) to smoothly adapt. During
* startup, when filling the window, we use a parabolic weighting factor, the
* more the window is filled, the faster we move to the detected possible skew.
*
* Returns: @time adjusted with the clock skew.
*/
static GstClockTime
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
calculate_skew (MpegTSPacketizer2 * packetizer,
MpegTSPCR * pcr, guint64 pcrtime, GstClockTime time)
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
{
guint64 send_diff, recv_diff;
gint64 delta;
gint64 old;
gint pos, i;
GstClockTime gstpcrtime, out_time;
mpegtsdemux: Fix for compiling without GST_DEBUG Protect debug-only variables/usage, and in one case remove a useless variable.
2013-06-05 13:51:58 +00:00
#ifndef GST_DISABLE_GST_DEBUG
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
guint64 slope;
mpegtsdemux: Fix for compiling without GST_DEBUG Protect debug-only variables/usage, and in one case remove a useless variable.
2013-06-05 13:51:58 +00:00
#endif
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
gstpcrtime = PCRTIME_TO_GSTTIME (pcrtime) + pcr->pcroffset;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* first time, lock on to time and gstpcrtime */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (!GST_CLOCK_TIME_IS_VALID (pcr->base_time))) {
pcr->base_time = time;
pcr->prev_out_time = GST_CLOCK_TIME_NONE;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
GST_DEBUG ("Taking new base time %" GST_TIME_FORMAT, GST_TIME_ARGS (time));
}
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (!GST_CLOCK_TIME_IS_VALID (pcr->base_pcrtime))) {
pcr->base_pcrtime = gstpcrtime;
pcr->prev_send_diff = -1;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
GST_DEBUG ("Taking new base pcrtime %" GST_TIME_FORMAT,
GST_TIME_ARGS (gstpcrtime));
}
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
/* Handle PCR wraparound and resets */
if (GST_CLOCK_TIME_IS_VALID (pcr->last_pcrtime) &&
gstpcrtime < pcr->last_pcrtime) {
if (pcr->last_pcrtime - gstpcrtime > PCR_GST_MAX_VALUE / 2) {
/* PCR wraparound */
GST_DEBUG ("PCR wrap");
pcr->pcroffset += PCR_GST_MAX_VALUE;
gstpcrtime = PCRTIME_TO_GSTTIME (pcrtime) + pcr->pcroffset;
send_diff = gstpcrtime - pcr->base_pcrtime;
} else if (GST_CLOCK_TIME_IS_VALID (time)
&& pcr->last_pcrtime - gstpcrtime > 15 * GST_SECOND) {
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
/* Time jumped backward by > 15 seconds, and we have a timestamp
* to use to close the discont. Assume a reset */
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
GST_DEBUG ("PCR reset");
/* Calculate PCR we would have expected for the given input time,
* essentially applying the reverse correction process
*
* We want to find the PCR offset to apply
* pcroffset = (corrected) gstpcrtime - (received) gstpcrtime
*
* send_diff = (corrected) gstpcrtime - pcr->base_pcrtime
* recv_diff = time - pcr->base_time
* out_time = pcr->base_time + send_diff
*
* We are assuming that send_diff == recv_diff
* (corrected) gstpcrtime - pcr->base_pcrtime = time - pcr->base_time
* Giving us:
* (corrected) gstpcrtime = time - pcr->base_time + pcr->base_pcrtime
*
* And therefore:
* pcroffset = time - pcr->base_time + pcr->base_pcrtime - (received) gstpcrtime
**/
pcr->pcroffset += time - pcr->base_time + pcr->base_pcrtime - gstpcrtime;
gstpcrtime = PCRTIME_TO_GSTTIME (pcrtime) + pcr->pcroffset;
send_diff = gstpcrtime - pcr->base_pcrtime;
GST_DEBUG ("Introduced offset is now %" GST_TIME_FORMAT
" corrected pcr time %" GST_TIME_FORMAT,
GST_TIME_ARGS (pcr->pcroffset), GST_TIME_ARGS (gstpcrtime));
} else {
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
/* Small jumps backward, assume some arrival jitter and skip it */
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
send_diff = 0;
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
mpegtspacketizer: Handle PCR issues with adaptive streams A lot of content producers out there targetting "adaptive streaming" are riddled with non-compliant PCR streams (essentially all the players out there just use PTS/DTS and don't care about the PCR). In order to gracefully cope with these, we detect them appropriately and any small (< 15s) PCR resets get gracefully ignored. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1785>
2020-11-09 17:27:14 +00:00
/* The following code are the different ways we deal with small-ish
* jitter, ranging in severity from "can be ignored" to "this needs a full
* resync" */
if (time == pcr->base_time) {
/* If this comes from a non-fully-timestamped source (i.e. adaptive
* streams), then cope with the fact that some producers generate utter
* PCR garbage on fragment ends.
*
* We detect this comes from a non-fully-timestamped source by the fact
* that the buffer time never changes */
GST_DEBUG ("Ignoring PCR resets on non-fully timestamped stream");
} else if (pcr->last_pcrtime - gstpcrtime < GST_SECOND) {
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
GST_WARNING
("(small) backward timestamps at server or no buffer timestamps. Ignoring.");
/* This will trigger the no_skew logic before but leave other state
* intact */
time = GST_CLOCK_TIME_NONE;
} else {
/* A bigger backward step than packet out-of-order can account for. Reset base PCR time
* to be resynched the next time we see a PCR */
GST_WARNING
("backward timestamps at server or no buffer timestamps. Resync base PCR");
pcr->base_pcrtime = GST_CLOCK_TIME_NONE;
}
mpegtspacketizer: Better detect PCR resets Assume that any differences in PCR greater than 15s means there is a reset in the stream.
2012-07-19 11:35:51 +00:00
}
} else
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
send_diff = gstpcrtime - pcr->base_pcrtime;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("gstpcr %" GST_TIME_FORMAT ", buftime %" GST_TIME_FORMAT
", base %" GST_TIME_FORMAT ", send_diff %" GST_TIME_FORMAT,
mpegtspacketizer: Fix issues with skew code * Always try to get a timestamp for the algorithm * Remove dead variable * Return proper default value
2012-02-24 16:47:38 +00:00
GST_TIME_ARGS (gstpcrtime), GST_TIME_ARGS (time),
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
GST_TIME_ARGS (pcr->base_pcrtime), GST_TIME_ARGS (send_diff));
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
mpegtspacketizer: Detect PCR wraparound in skew code If the received PCR is going backwards (by a safe margin), include that wraparound for further calculation. https://bugzilla.gnome.org/show_bug.cgi?id=674536
2012-05-20 11:27:29 +00:00
/* keep track of the last extended pcrtime */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->last_pcrtime = gstpcrtime;
mpegtspacketizer: Detect PCR wraparound in skew code If the received PCR is going backwards (by a safe margin), include that wraparound for further calculation. https://bugzilla.gnome.org/show_bug.cgi?id=674536
2012-05-20 11:27:29 +00:00
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* we don't have an arrival timestamp so we can't do skew detection. we
* should still apply a timestamp based on RTP timestamp and base_time */
if (!GST_CLOCK_TIME_IS_VALID (time)
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
|| !GST_CLOCK_TIME_IS_VALID (pcr->base_time))
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
goto no_skew;
/* elapsed time at receiver, includes the jitter */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
recv_diff = time - pcr->base_time;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
/* Ignore packets received at 100% the same time (i.e. from the same input buffer) */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (time == pcr->prev_in_time
&& GST_CLOCK_TIME_IS_VALID (pcr->prev_in_time)))
mpegtspacketizer: clock fix and minor addition * Don't take into account packets that arrived at the same time as previous ones for clock skew estimation * Add convenience method for processing the next ts packet
2012-03-01 16:53:41 +00:00
goto no_skew;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* measure the diff */
delta = ((gint64) recv_diff) - ((gint64) send_diff);
mpegtsdemux: Fix for compiling without GST_DEBUG Protect debug-only variables/usage, and in one case remove a useless variable.
2013-06-05 13:51:58 +00:00
#ifndef GST_DISABLE_GST_DEBUG
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* measure the slope, this gives a rought estimate between the sender speed
* and the receiver speed. This should be approximately 8, higher values
* indicate a burst (especially when the connection starts) */
slope = recv_diff > 0 ? (send_diff * 8) / recv_diff : 8;
mpegtsdemux: Fix for compiling without GST_DEBUG Protect debug-only variables/usage, and in one case remove a useless variable.
2013-06-05 13:51:58 +00:00
#endif
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("time %" GST_TIME_FORMAT ", base %" GST_TIME_FORMAT
", recv_diff %" GST_TIME_FORMAT ", slope %" G_GUINT64_FORMAT,
GST_TIME_ARGS (time), GST_TIME_ARGS (pcr->base_time),
GST_TIME_ARGS (recv_diff), slope);
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* if the difference between the sender timeline and the receiver timeline
* changed too quickly we have to resync because the server likely restarted
* its timestamps. */
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
if (ABS (delta - pcr->skew) > packetizer->pcr_discont_threshold) {
mpegtspacketizer: Handle PCR issues with adaptive streams A lot of content producers out there targetting "adaptive streaming" are riddled with non-compliant PCR streams (essentially all the players out there just use PTS/DTS and don't care about the PCR). In order to gracefully cope with these, we detect them appropriately and any small (< 15s) PCR resets get gracefully ignored. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1785>
2020-11-09 17:27:14 +00:00
GST_WARNING ("delta - skew: %" GST_STIME_FORMAT " too big, reset skew",
GST_STIME_ARGS (delta - pcr->skew));
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
mpegts_packetizer_resync (pcr, time, gstpcrtime, TRUE);
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
send_diff = 0;
delta = 0;
}
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pos = pcr->window_pos;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (pcr->window_filling)) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* we are filling the window */
GST_DEBUG ("filling %d, delta %" G_GINT64_FORMAT, pos, delta);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window[pos++] = delta;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* calc the min delta we observed */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (pos == 1 || delta < pcr->window_min))
pcr->window_min = delta;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
if (G_UNLIKELY (send_diff >= MAX_TIME || pos >= MAX_WINDOW)) {
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window_size = pos;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* window filled */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
GST_DEBUG ("min %" G_GINT64_FORMAT, pcr->window_min);
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* the skew is now the min */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->skew = pcr->window_min;
pcr->window_filling = FALSE;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
} else {
gint perc_time, perc_window, perc;
/* figure out how much we filled the window, this depends on the amount of
* time we have or the max number of points we keep. */
perc_time = send_diff * 100 / MAX_TIME;
perc_window = pos * 100 / MAX_WINDOW;
perc = MAX (perc_time, perc_window);
/* make a parabolic function, the closer we get to the MAX, the more value
* we give to the scaling factor of the new value */
perc = perc * perc;
/* quickly go to the min value when we are filling up, slowly when we are
* just starting because we're not sure it's a good value yet. */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->skew =
(perc * pcr->window_min + ((10000 - perc) * pcr->skew)) / 10000;
pcr->window_size = pos + 1;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
} else {
/* pick old value and store new value. We keep the previous value in order
* to quickly check if the min of the window changed */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
old = pcr->window[pos];
pcr->window[pos++] = delta;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (delta <= pcr->window_min)) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* if the new value we inserted is smaller or equal to the current min,
* it becomes the new min */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window_min = delta;
} else if (G_UNLIKELY (old == pcr->window_min)) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
gint64 min = G_MAXINT64;
/* if we removed the old min, we have to find a new min */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
for (i = 0; i < pcr->window_size; i++) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* we found another value equal to the old min, we can stop searching now */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (pcr->window[i] == old) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
min = old;
break;
}
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (pcr->window[i] < min)
min = pcr->window[i];
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window_min = min;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
/* average the min values */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->skew = (pcr->window_min + (124 * pcr->skew)) / 125;
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("delta %" G_GINT64_FORMAT ", new min: %" G_GINT64_FORMAT,
delta, pcr->window_min);
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
/* wrap around in the window */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_UNLIKELY (pos >= pcr->window_size))
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
pos = 0;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->window_pos = pos;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
no_skew:
/* the output time is defined as the base timestamp plus the PCR time
* adjusted for the clock skew .*/
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (pcr->base_time != -1) {
out_time = pcr->base_time + send_diff;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* skew can be negative and we don't want to make invalid timestamps */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (pcr->skew < 0 && out_time < -pcr->skew) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
out_time = 0;
} else {
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
out_time += pcr->skew;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
/* check if timestamps are not going backwards, we can only check this if we
* have a previous out time and a previous send_diff */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (G_LIKELY (pcr->prev_out_time != -1 && pcr->prev_send_diff != -1)) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* now check for backwards timestamps */
if (G_UNLIKELY (
/* if the server timestamps went up and the out_time backwards */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
(send_diff > pcr->prev_send_diff
&& out_time < pcr->prev_out_time) ||
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* if the server timestamps went backwards and the out_time forwards */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
(send_diff < pcr->prev_send_diff
&& out_time > pcr->prev_out_time) ||
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
/* if the server timestamps did not change */
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
send_diff == pcr->prev_send_diff)) {
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
GST_DEBUG ("backwards timestamps, using previous time");
out_time = GSTTIME_TO_MPEGTIME (out_time);
}
}
} else {
/* We simply use the pcrtime without applying any skew compensation */
mpegtspacketizer: Fix issues with skew code * Always try to get a timestamp for the algorithm * Remove dead variable * Return proper default value
2012-02-24 16:47:38 +00:00
out_time = time;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
}
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->prev_out_time = out_time;
pcr->prev_in_time = time;
pcr->prev_send_diff = send_diff;
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
GST_DEBUG ("skew %" G_GINT64_FORMAT ", out %" GST_TIME_FORMAT,
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcr->skew, GST_TIME_ARGS (out_time));
mpegtspacketizer: Estimate clock skew and retimestamps buffers more precisly Apply the EPTLA algotithm to estimate clock skew. Reusing code from -good/gst/rtpmanager/rtpjitterbuffer.c
2012-02-23 17:46:09 +00:00
return out_time;
}
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
static void
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
_reevaluate_group_pcr_offset (MpegTSPCR * pcrtable, PCROffsetGroup * group)
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
{
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
PCROffsetGroup *prev = NULL;
#ifndef GST_DISABLE_GST_DEBUG
PCROffsetGroup *first = pcrtable->groups->data;
#endif
PCROffsetCurrent *current = pcrtable->current;
GList *tmp;
/* Go over all ESTIMATED groups until the target group */
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
PCROffsetGroup *cur = (PCROffsetGroup *) tmp->data;
/* Skip groups that don't need re-evaluation */
if (!(cur->flags & PCR_GROUP_FLAG_ESTIMATED)) {
GST_DEBUG ("Skipping group %p pcr_offset (currently %" GST_TIME_FORMAT
")", cur, GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->pcr_offset)));
prev = cur;
continue;
}
/* This should not happen ! The first group is *always* correct (zero) */
if (G_UNLIKELY (prev == NULL)) {
GST_ERROR ("First PCR Group was not estimated (bug). Setting to zero");
cur->pcr_offset = 0;
cur->flags &= ~PCR_GROUP_FLAG_ESTIMATED;
return;
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Finally do the estimation of this group's PCR offset based on the
* previous group information */
GST_DEBUG ("Re-evaluating group %p pcr_offset (currently %" GST_TIME_FORMAT
")", group, GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->pcr_offset)));
GST_DEBUG ("cur->first_pcr:%" GST_TIME_FORMAT " prev->first_pcr:%"
GST_TIME_FORMAT, GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->first_pcr)),
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (prev->first_pcr)));
if (G_UNLIKELY (cur->first_pcr < prev->first_pcr)) {
guint64 prevbr, lastbr;
guint64 prevpcr;
guint64 prevoffset, lastoffset;
/* Take the previous group pcr_offset and figure out how much to add
* to it for the current group */
mpegtspacketizer: Remove or move variable assignments To where they're needed
2014-02-07 10:54:07 +00:00
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Right now we do a dumb bitrate estimation
* estimate bitrate (prev - first) : bitrate from the start
* estimate bitrate (prev) : bitrate of previous group
* estimate bitrate (last - first) : bitrate from previous group
*
* We will use raw (non-corrected/non-absolute) PCR values in a first time
* to detect wraparound/resets/gaps...
*
documentation: fixed a heap o' typos
2019-09-02 19:08:44 +00:00
* We will use the corrected/absolute PCR values to calculate
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
* bitrate and estimate the target group pcr_offset.
* */
/* If the current window estimator is over the previous group, used those
* values as the latest (since they are more recent) */
if (current->group == prev && current->pending[current->last].offset) {
prevoffset =
current->pending[current->last].offset + prev->first_offset;
prevpcr = current->pending[current->last].pcr + prev->first_pcr;
/* prevbr: bitrate(prev) */
prevbr =
gst_util_uint64_scale (PCR_SECOND,
current->pending[current->last].offset,
current->pending[current->last].pcr);
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Previous group bitrate (%" G_GUINT64_FORMAT " / %"
GST_TIME_FORMAT ") : %" G_GUINT64_FORMAT,
current->pending[current->last].offset,
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (current->pending[current->last].
pcr)), prevbr);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
} else if (prev->values[prev->last_value].offset) {
prevoffset = prev->values[prev->last_value].offset + prev->first_offset;
prevpcr = prev->values[prev->last_value].pcr + prev->first_pcr;
/* prevbr: bitrate(prev) (FIXME : Cache) */
prevbr =
gst_util_uint64_scale (PCR_SECOND,
prev->values[prev->last_value].offset,
prev->values[prev->last_value].pcr);
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Previous group bitrate (%" G_GUINT64_FORMAT " / %"
GST_TIME_FORMAT ") : %" G_GUINT64_FORMAT,
prev->values[prev->last_value].offset,
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (prev->values[prev->last_value].
pcr)), prevbr);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
} else {
GST_DEBUG ("Using overall bitrate");
prevoffset = prev->values[prev->last_value].offset + prev->first_offset;
prevpcr = prev->values[prev->last_value].pcr + prev->first_pcr;
prevbr = gst_util_uint64_scale (PCR_SECOND,
prev->first_offset, prev->pcr_offset);
}
lastoffset = cur->values[cur->last_value].offset + cur->first_offset;
GST_DEBUG ("Offset first:%" G_GUINT64_FORMAT " prev:%" G_GUINT64_FORMAT
" cur:%" G_GUINT64_FORMAT, first->first_offset, prevoffset,
lastoffset);
GST_DEBUG ("PCR first:%" GST_TIME_FORMAT " prev:%" GST_TIME_FORMAT
" cur:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (first->first_pcr)),
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (prevpcr)),
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->values[cur->last_value].pcr +
cur->first_pcr)));
if (prevpcr - cur->first_pcr > (PCR_MAX_VALUE * 9 / 10)) {
gfloat diffprev;
mpegtspacketizer: Remove or move variable assignments To where they're needed
2014-02-07 10:54:07 +00:00
guint64 guess_offset;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Let's assume there is a PCR wraparound between the previous and current
* group.
* [ prev ]... PCR_MAX | 0 ...[ current ]
* The estimated pcr_offset would therefore be:
* current.first + (PCR_MAX_VALUE - prev.first)
*
* 1) Check if bitrate(prev) would be consistent with bitrate (cur - prev)
*/
guess_offset = PCR_MAX_VALUE - prev->first_pcr + cur->first_pcr;
lastbr = gst_util_uint64_scale (PCR_SECOND, lastoffset - prevoffset,
guess_offset + cur->values[cur->last_value].pcr - (prevpcr -
prev->first_pcr));
GST_DEBUG ("Wraparound prev-cur (guess_offset:%" GST_TIME_FORMAT
") bitrate:%" G_GUINT64_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (guess_offset)), lastbr);
diffprev = (float) 100.0 *(ABSDIFF (prevbr, lastbr)) / (float) prevbr;
GST_DEBUG ("Difference with previous bitrate:%f", diffprev);
if (diffprev < 10.0) {
GST_DEBUG ("Difference < 10.0, Setting pcr_offset to %"
G_GUINT64_FORMAT, guess_offset);
cur->pcr_offset = guess_offset;
if (diffprev < 1.0) {
GST_DEBUG ("Difference < 1.0, Removing ESTIMATED flags");
cur->flags &= ~PCR_GROUP_FLAG_ESTIMATED;
}
}
/* Indicate the the previous group is before a wrapover */
prev->flags |= PCR_GROUP_FLAG_WRAPOVER;
} else {
guint64 resetprev;
/* Let's assume there was a PCR reset between the previous and current
* group
* [ prev ] ... x | x - reset ... [ current ]
*
* The estimated pcr_offset would then be
* = current.first - (x - reset) + (x - prev.first) + 100ms (for safety)
* = current.first + reset - prev.first + 100ms (for safety)
*/
/* In order to calculate the reset, we estimate what the PCR would have
* been by using prevbr */
/* FIXME : Which bitrate should we use ??? */
GST_DEBUG ("Using prevbr:%" G_GUINT64_FORMAT " and taking offsetdiff:%"
G_GUINT64_FORMAT, prevbr, cur->first_offset - prev->first_offset);
resetprev =
gst_util_uint64_scale (PCR_SECOND,
cur->first_offset - prev->first_offset, prevbr);
GST_DEBUG ("Estimated full PCR for offset %" G_GUINT64_FORMAT
", using prevbr:%"
GST_TIME_FORMAT, cur->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (resetprev)));
cur->pcr_offset = prev->pcr_offset + resetprev + 100 * PCR_MSECOND;
GST_DEBUG ("Adjusted group PCR_offset to %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->pcr_offset)));
/* Indicate the the previous group is before a reset */
prev->flags |= PCR_GROUP_FLAG_RESET;
}
} else {
/* FIXME : Detect gaps if bitrate difference is really too big ? */
cur->pcr_offset = prev->pcr_offset + cur->first_pcr - prev->first_pcr;
GST_DEBUG ("Assuming there is no gap, setting pcr_offset to %"
GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (cur->pcr_offset)));
/* Remove the reset and wrapover flag (if it was previously there) */
prev->flags &= ~PCR_GROUP_FLAG_RESET;
prev->flags &= ~PCR_GROUP_FLAG_WRAPOVER;
}
/* Remember prev for the next group evaluation */
prev = cur;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
}
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
static PCROffsetGroup *
_new_group (guint64 pcr, guint64 offset, guint64 pcr_offset, guint flags)
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
{
mpegtsdemux: drop use of GSlice Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3695>
2023-01-08 18:46:03 +00:00
PCROffsetGroup *group = g_new0 (PCROffsetGroup, 1);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Input PCR %" GST_TIME_FORMAT " offset:%" G_GUINT64_FORMAT
" pcr_offset:%" G_GUINT64_FORMAT " flags:%d",
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (pcr)), offset, pcr_offset, flags);
group->flags = flags;
group->values = g_new0 (PCROffset, DEFAULT_ALLOCATED_OFFSET);
/* The first pcr/offset diff is always 0/0 */
group->values[0].pcr = group->values[0].offset = 0;
group->nb_allocated = DEFAULT_ALLOCATED_OFFSET;
/* Store the full values */
group->first_pcr = pcr;
group->first_offset = offset;
group->pcr_offset = pcr_offset;
GST_DEBUG ("Created group starting with pcr:%" GST_TIME_FORMAT " offset:%"
G_GUINT64_FORMAT " pcr_offset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->first_pcr)),
group->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->pcr_offset)));
return group;
}
static void
_insert_group_after (MpegTSPCR * pcrtable, PCROffsetGroup * group,
PCROffsetGroup * prev)
{
if (prev == NULL) {
/* First group */
pcrtable->groups = g_list_prepend (pcrtable->groups, group);
} else {
GList *tmp, *toinsert, *prevlist = NULL, *nextlist = NULL;
/* Insert before next and prev */
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
if (tmp->data == prev) {
prevlist = tmp;
nextlist = tmp->next;
break;
}
}
mpegtsdemux: catch prev-not-found when inserting in the group list While this probably should never happen if callers are well behaved, this avoids a crash if it does. With a warning about it. Unsure if it'd be better to not add at all, but it should not happen... Coverity 1139713
2014-04-09 13:13:46 +00:00
if (!prevlist) {
/* The non NULL prev given isn't in the list */
GST_WARNING ("Request to insert before a group which isn't in the list");
pcrtable->groups = g_list_prepend (pcrtable->groups, group);
} else {
toinsert = g_list_append (NULL, group);
toinsert->next = nextlist;
toinsert->prev = prevlist;
prevlist->next = toinsert;
if (nextlist)
nextlist->prev = toinsert;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
}
static void
_use_group (MpegTSPCR * pcrtable, PCROffsetGroup * group)
{
PCROffsetCurrent *current = pcrtable->current;
memset (current, 0, sizeof (PCROffsetCurrent));
current->group = group;
current->pending[0] = group->values[group->last_value];
current->last_value = current->pending[0];
current->write = 1;
current->prev = group->values[group->last_value];
current->first_pcr = group->first_pcr;
current->first_offset = group->first_offset;
}
/* Create a new group with the specified values after prev
* Set current to that new group */
static void
_set_current_group (MpegTSPCR * pcrtable,
PCROffsetGroup * prev, guint64 pcr, guint64 offset, gboolean contiguous)
{
PCROffsetGroup *group;
guint flags = 0;
guint64 pcr_offset = 0;
/* Handle wraparound/gap (only if contiguous with previous group) */
if (contiguous) {
guint64 lastpcr = prev->first_pcr + prev->values[prev->last_value].pcr;
/* Set CLOSED flag on previous group and remember pcr_offset */
prev->flags |= PCR_GROUP_FLAG_CLOSED;
pcr_offset = prev->pcr_offset;
/* Wraparound ? */
if (lastpcr > pcr) {
/* In offset-mode, a PCR wraparound is only actually consistent if
* we have a very high confidence (99% right now, might need to change
* later) */
if (lastpcr - pcr > (PCR_MAX_VALUE * 99 / 100)) {
GST_WARNING ("WRAPAROUND detected. diff %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (lastpcr - pcr)));
/* The previous group closed at PCR_MAX_VALUE */
pcr_offset += PCR_MAX_VALUE - prev->first_pcr + pcr;
} else {
GST_WARNING ("RESET detected. diff %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (lastpcr - pcr)));
/* The previous group closed at the raw last_pcr diff (+100ms for safety) */
pcr_offset += prev->values[prev->last_value].pcr + 100 * PCR_MSECOND;
}
} else if (lastpcr < pcr - 500 * PCR_MSECOND) {
GST_WARNING ("GAP detected. diff %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (pcr - lastpcr)));
/* The previous group closed at the raw last_pcr diff (+500ms for safety) */
pcr_offset += prev->values[prev->last_value].pcr + 500 * PCR_MSECOND;
} else
/* Normal continuation (contiguous in time) */
pcr_offset += pcr - prev->first_pcr;
} else if (prev != NULL)
/* If we are not contiguous and it's not the first group, the pcr_offset
* will be estimated */
flags = PCR_GROUP_FLAG_ESTIMATED;
group = _new_group (pcr, offset, pcr_offset, flags);
_use_group (pcrtable, group);
_insert_group_after (pcrtable, group, prev);
if (!contiguous)
_reevaluate_group_pcr_offset (pcrtable, group);
}
static inline void
_append_group_values (PCROffsetGroup * group, PCROffset pcroffset)
{
mpegtspacketizer: Don't add existing values to group If the last value is already identical, there is no need in adding it yet-another-time
2016-11-24 10:11:35 +00:00
/* Only append if new values */
if (group->values[group->last_value].offset == pcroffset.offset &&
group->values[group->last_value].pcr == pcroffset.pcr) {
GST_DEBUG ("Same values, ignoring");
} else {
group->last_value++;
/* Resize values if needed */
if (G_UNLIKELY (group->nb_allocated == group->last_value)) {
group->nb_allocated += DEFAULT_ALLOCATED_OFFSET;
group->values =
g_realloc (group->values, group->nb_allocated * sizeof (PCROffset));
}
group->values[group->last_value] = pcroffset;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
GST_DEBUG ("First PCR:%" GST_TIME_FORMAT " offset:%" G_GUINT64_FORMAT
" PCR_offset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->first_pcr)),
group->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->pcr_offset)));
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Last PCR: +%" GST_TIME_FORMAT " offset: +%" G_GUINT64_FORMAT,
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (pcroffset.pcr)), pcroffset.offset);
}
/* Move last values from current (if any) to the current group
* and reset current.
* Note: This does not set the CLOSED flag (since we have no next
* contiguous group) */
static void
_close_current_group (MpegTSPCR * pcrtable)
{
PCROffsetCurrent *current = pcrtable->current;
PCROffsetGroup *group = current->group;
if (group == NULL)
return;
GST_DEBUG ("Closing group and resetting current");
/* Store last values */
_append_group_values (group, current->pending[current->last]);
memset (current, 0, sizeof (PCROffsetCurrent));
/* And re-evaluate all groups */
}
static void
record_pcr (MpegTSPacketizer2 * packetizer, MpegTSPCR * pcrtable,
guint64 pcr, guint64 offset)
{
PCROffsetCurrent *current = pcrtable->current;
mpegtspacketizer: Fix wraparound detection issue Using 32bit unsigned values for corrected pcr/offset meant that we potentially ended up in bogus values Furthermore, refpcr - refpcroffset could end up being negative, which PCRTIME_TO_GSTTIME() can't handle (and returned a massive positive value)
2014-06-13 08:37:46 +00:00
gint64 corpcr, coroffset;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
packetizer->nb_seen_offsets += 1;
tsdemux: GAP detection All pads of a stream are now added at the beginning. In order to cope with streams that don't get any data (forever or for a long time) we detect gaps and push out GAP events when needed. Cleanups and commenting by Jan Schmidt <jan@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=734040
2014-10-20 10:30:50 +00:00
pcrtable->last_pcrtime = PCRTIME_TO_GSTTIME (pcr);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* FIXME : Invert logic later (probability is higher that we have a
* current estimator) */
/* Check for current */
if (G_UNLIKELY (current->group == NULL)) {
PCROffsetGroup *prev = NULL;
GList *tmp;
/* No current estimator. This happens for the initial value, or after
* discont and flushes. Figure out where we need to record this position.
mpegtsdemux: Deliver all packets to tsparse 34af8ed66a7c63048ce0bdf59bbe61011d7c6292 changed the code to use the packetizer's packets instead of the incoming buffers, but mpegtsbase didn't actually push all packets to the subclass. As a result, padding (PID 0x1FFF) packets got lost. Add a new boolean to toggle pushing unknown packets to mpegtsbase and have mpegtsparse make use of it. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1300>
2020-05-26 20:40:04 +00:00
*
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
* Possible choices:
* 1) No groups at all:
* Create a new group with pcr/offset
* Initialize current to that group
* 2) Entirely within an existing group
* bail out (FIXME: Make this detection faster)
* 3) Not in any group
* Create a new group with pcr/offset at the right position
* Initialize current to that group
*/
GST_DEBUG ("No current window estimator, Checking for group to use");
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
PCROffsetGroup *group = (PCROffsetGroup *) tmp->data;
GST_DEBUG ("First PCR:%" GST_TIME_FORMAT " offset:%" G_GUINT64_FORMAT
" PCR_offset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->first_pcr)),
group->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->pcr_offset)));
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Last PCR: +%" GST_TIME_FORMAT " offset: +%" G_GUINT64_FORMAT,
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->values[group->last_value].
pcr)), group->values[group->last_value].offset);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Check if before group */
if (offset < group->first_offset) {
GST_DEBUG ("offset is before that group");
break;
}
/* Check if within group */
if (offset <=
(group->values[group->last_value].offset + group->first_offset)) {
GST_DEBUG ("Already observed PCR offset %" G_GUINT64_FORMAT, offset);
return;
}
/* Check if just after group (i.e. continuation of it) */
if (!(group->flags & PCR_GROUP_FLAG_CLOSED) &&
pcr - group->first_pcr - group->values[group->last_value].pcr <=
100 * PCR_MSECOND) {
GST_DEBUG ("Continuation of existing group");
_use_group (pcrtable, group);
return;
}
/* Else after group */
prev = group;
}
_set_current_group (pcrtable, prev, pcr, offset, FALSE);
return;
}
corpcr = pcr - current->first_pcr;
coroffset = offset - current->first_offset;
/* FIXME : Detect if we've gone into the next group !
* FIXME : Close group when that happens */
GST_DEBUG ("first:%d, last:%d, write:%d", current->first, current->last,
current->write);
GST_DEBUG ("First PCR:%" GST_TIME_FORMAT " offset:%" G_GUINT64_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (current->first_pcr)),
current->first_offset);
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Last PCR: +%" GST_TIME_FORMAT " offset: +%" G_GUINT64_FORMAT,
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (current->pending[current->last].pcr)),
mpegtspacketizer: Fix debug statement
2014-06-10 12:27:53 +00:00
current->pending[current->last].offset);
mpegtspacketizer: Fix wraparound detection issue Using 32bit unsigned values for corrected pcr/offset meant that we potentially ended up in bogus values Furthermore, refpcr - refpcroffset could end up being negative, which PCRTIME_TO_GSTTIME() can't handle (and returned a massive positive value)
2014-06-13 08:37:46 +00:00
GST_DEBUG ("To add (corrected) PCR:%" GST_TIME_FORMAT " offset:%"
G_GINT64_FORMAT, GST_TIME_ARGS (PCRTIME_TO_GSTTIME (corpcr)), coroffset);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Do we need to close the current group ? */
/* Check for wrapover/discont */
if (G_UNLIKELY (corpcr < current->pending[current->last].pcr)) {
/* FIXME : ignore very small deltas (< 500ms ?) which are most likely
* stray values */
GST_DEBUG
("PCR smaller than previously observed one, handling discont/wrapover");
/* Take values from current and put them in the current group (closing it) */
/* Create new group with new pcr/offset just after the current group
* and mark it as a wrapover */
/* Initialize current to that group with new values */
_append_group_values (current->group, current->pending[current->last]);
_set_current_group (pcrtable, current->group, pcr, offset, TRUE);
return;
}
/* If PCR diff is greater than 500ms, create new group */
Revert "mpegtspacketizer: Convert PCR times to GStreamer times before comparing them against 500 * GST_MSECOND" This reverts commit 9f186c6ab32c1e949916d385186b2d400190add6. That commit was actually completely wrong, nevermind.
2014-08-05 08:42:28 +00:00
if (G_UNLIKELY (corpcr - current->pending[current->last].pcr >
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
500 * PCR_MSECOND)) {
GST_DEBUG ("New PCR more than 500ms away, handling discont");
/* Take values from current and put them in the current group (closing it) */
/* Create new group with pcr/offset just after the current group
* and mark it as a discont */
/* Initialize current to that group with new values */
_append_group_values (current->group, current->pending[current->last]);
_set_current_group (pcrtable, current->group, pcr, offset, TRUE);
return;
}
if (G_UNLIKELY (corpcr == current->last_value.pcr)) {
GST_DEBUG ("Ignoring same PCR (stream is drunk)");
return;
}
/* update current window */
current->pending[current->write].pcr = corpcr;
current->pending[current->write].offset = coroffset;
current->last_value = current->pending[current->write];
current->last = (current->last + 1) % PCR_BITRATE_NEEDED;
current->write = (current->write + 1) % PCR_BITRATE_NEEDED;
GST_DEBUG ("first:%d, last:%d, write:%d", current->first, current->last,
current->write);
GST_DEBUG ("First PCR:%" GST_TIME_FORMAT " offset:%" G_GUINT64_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (current->first_pcr)),
current->first_offset);
mpegtspacketizer: Store PCR time/byte offsets in 64 bit integers 32 bit integers are going to overflow, especially the PCR offset to the first PCR will overflow after about 159 seconds. This makes playback of streams stop at 159 seconds as suddenly the timestamps are starting again from 0. Now we have a few more years time until it happens again and 64 bits are too small.
2014-08-05 09:45:55 +00:00
GST_DEBUG ("Last PCR: +%" GST_TIME_FORMAT " offset: +%" G_GUINT64_FORMAT,
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (current->pending[current->last].pcr)),
current->pending[current->last].offset);
/* If we haven't stored enough values, bail out */
if (current->write != current->first) {
GST_DEBUG
("Not enough observations to calculate bitrate (first:%d, last:%d)",
current->first, current->last);
return;
}
/* If we are at least 1s away from reference value AND we have filled our
* window, we can start comparing bitrates */
if (current->pending[current->first].pcr - current->prev.pcr > PCR_SECOND) {
/* Calculate window bitrate */
current->cur_bitrate = gst_util_uint64_scale (PCR_SECOND,
current->pending[current->last].offset -
current->pending[current->first].offset,
current->pending[current->last].pcr -
current->pending[current->first].pcr);
GST_DEBUG ("Current bitrate is now %" G_GUINT64_FORMAT,
current->cur_bitrate);
/* Calculate previous bitrate */
current->prev_bitrate =
gst_util_uint64_scale (PCR_SECOND,
current->pending[current->first].offset - current->prev.offset,
current->pending[current->first].pcr - current->prev.pcr);
GST_DEBUG ("Previous group bitrate now %" G_GUINT64_FORMAT,
current->prev_bitrate);
/* FIXME : Better bitrate changes ? Currently 10% changes */
if (ABSDIFF (current->cur_bitrate,
current->prev_bitrate) * 10 > current->prev_bitrate) {
GST_DEBUG ("Current bitrate changed by more than 10%% (old:%"
G_GUINT64_FORMAT " new:%" G_GUINT64_FORMAT ")", current->prev_bitrate,
current->cur_bitrate);
/* If we detected a change in bitrate, this means that
* d(first - prev) is a different bitrate than d(last - first).
*
* Two conclusions can be made:
* 1) d(first - prev) is a complete bitrate "chain" (values between the
* reference value and first pending value have consistent bitrate).
* 2) next values (from second pending value onwards) will no longer have
* the same bitrate.
*
* The question remains as to how long the new bitrate change is going to
* last for (it might be short or longer term). For this we need to restart
* bitrate estimation.
*
* * We move over first to the last value of group (a new chain ends and
* starts from there)
* * We remember that last group value as our new window reference
* * We restart our window filing from the last observed value
*
* Once our new window is filled we will end up in two different scenarios:
* 1) Either the bitrate change was consistent, and therefore the bitrate
* will have remained constant over at least 2 window length
* 2) The bitrate change was very short (1 window duration) and we will
* close that chain and restart again.
* X) And of course if any discont/gaps/wrapover happen in the meantime they
* will also close the group.
*/
_append_group_values (current->group, current->pending[current->first]);
current->prev = current->pending[current->first];
current->first = current->last;
current->write = (current->first + 1) % PCR_BITRATE_NEEDED;
return;
}
}
/* Update read position */
current->first = (current->first + 1) % PCR_BITRATE_NEEDED;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* convert specified offset into stream time */
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
GstClockTime
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegts_packetizer_offset_to_ts (MpegTSPacketizer2 * packetizer,
guint64 offset, guint16 pid)
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
{
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
PCROffsetGroup *last;
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
MpegTSPCR *pcrtable;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GList *tmp;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
GstClockTime res;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
guint64 lastpcr, lastoffset;
GST_DEBUG ("offset %" G_GUINT64_FORMAT, offset);
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
if (G_UNLIKELY (!packetizer->calculate_offset))
return GST_CLOCK_TIME_NONE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
if (G_UNLIKELY (packetizer->refoffset == -1))
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
return GST_CLOCK_TIME_NONE;
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
if (G_UNLIKELY (offset < packetizer->refoffset))
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
return GST_CLOCK_TIME_NONE;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcrtable = get_pcr_table (packetizer, pid);
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
if (g_list_length (pcrtable->groups) < 1) {
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_WARNING ("Not enough observations to return a duration estimate");
mpegtsdemux: check value before using as denominator
2013-04-15 23:01:29 +00:00
return GST_CLOCK_TIME_NONE;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
if (g_list_length (pcrtable->groups) > 1) {
GST_LOG ("Using last group");
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
/* FIXME : Refine this later to use neighbouring groups */
tmp = g_list_last (pcrtable->groups);
last = tmp->data;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
if (G_UNLIKELY (last->flags & PCR_GROUP_FLAG_ESTIMATED))
_reevaluate_group_pcr_offset (pcrtable, last);
mpegtsdemux: check value before using as denominator
2013-04-15 23:01:29 +00:00
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
/* lastpcr is the full value in PCR from the first first chunk of data */
lastpcr = last->values[last->last_value].pcr + last->pcr_offset;
/* lastoffset is the full offset from the first chunk of data */
lastoffset =
last->values[last->last_value].offset + last->first_offset -
packetizer->refoffset;
} else {
PCROffsetCurrent *current = pcrtable->current;
mpegtspacketizer: Don't dereference NULL if we have no PCR yet Can happen sometimes if the duration is requested before we received enough data with a PCR.
2014-07-03 12:15:36 +00:00
if (!current->group) {
PACKETIZER_GROUP_UNLOCK (packetizer);
GST_LOG ("No PCR yet");
return GST_CLOCK_TIME_NONE;
}
mpegtspacketizer: Fix duration evaluation in push mode When working in push mode, we need to be able to evaluate the duration based on a single group of observations. To do that we use the current group values
2014-06-10 12:27:01 +00:00
/* If doing progressive read, use current */
GST_LOG ("Using current group");
lastpcr = current->group->pcr_offset + current->pending[current->last].pcr;
lastoffset = current->first_offset + current->pending[current->last].offset;
}
GST_DEBUG ("lastpcr:%" GST_TIME_FORMAT " lastoffset:%" G_GUINT64_FORMAT
" refoffset:%" G_GUINT64_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (lastpcr)), lastoffset,
packetizer->refoffset);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Convert byte difference into time difference (and transformed from 27MHz to 1GHz) */
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
res =
PCRTIME_TO_GSTTIME (gst_util_uint64_scale (offset - packetizer->refoffset,
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
lastpcr, lastoffset));
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
GST_DEBUG ("Returning timestamp %" GST_TIME_FORMAT " for offset %"
G_GUINT64_FORMAT, GST_TIME_ARGS (res), offset);
return res;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Input : local PTS (in GHz units)
* Return : Stream time (in GHz units) */
tsdemux: Don't check SCTE events for being too far from the PCR Otherwise it happens that SCTE events can only be scheduled up to 15 seconds since the last seen PCR, which is a useless restriction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2021>
2022-03-24 17:55:48 +00:00
static GstClockTime
mpegts_packetizer_pts_to_ts_internal (MpegTSPacketizer2 * packetizer,
GstClockTime pts, guint16 pcr_pid, gboolean check_diff)
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
{
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
GstClockTime res = GST_CLOCK_TIME_NONE;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
MpegTSPCR *pcrtable;
PACKETIZER_GROUP_LOCK (packetizer);
pcrtable = get_pcr_table (packetizer, pcr_pid);
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
tsdemux: handle pcr_pid == 0x1fff Streams without PCR make senses in HLS, where the playlist timestamps can be used to seek or calculate the duration. https://bugzilla.gnome.org/show_bug.cgi?id=608148
2016-05-31 11:09:43 +00:00
if (!GST_CLOCK_TIME_IS_VALID (pcrtable->base_time) && pcr_pid == 0x1fff &&
GST_CLOCK_TIME_IS_VALID (packetizer->last_in_time)) {
pcrtable->base_time = packetizer->last_in_time;
pcrtable->base_pcrtime = pts;
}
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
/* Use clock skew if present */
if (packetizer->calculate_skew
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
&& GST_CLOCK_TIME_IS_VALID (pcrtable->base_time)) {
mpegtspacketizer: live: handle pcr/dts discrepancies some more When wrapover/reset occur, we end up with a small window of time where the PTS/DTS will still be using the previous/next time-range. In order not to return bogus values, return GST_CLOCK_TIME_NONE if the PTS/DTS value to convert differs by more than 15s against the last seen PCR https://bugzilla.gnome.org/show_bug.cgi?id=674536
2014-06-13 09:46:19 +00:00
GST_DEBUG ("pts %" GST_TIME_FORMAT " base_pcrtime:%" GST_TIME_FORMAT
" base_time:%" GST_TIME_FORMAT " pcroffset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (pts),
GST_TIME_ARGS (pcrtable->base_pcrtime),
GST_TIME_ARGS (pcrtable->base_time),
GST_TIME_ARGS (pcrtable->pcroffset));
tsdemux: Handle "negative" timestamps This is only enabled in push time mode. Furthermore it's only enabled for now if PCR is to be ignored. The problem is dealing with streams where the initial PTS/DTS observation might be greater than following ones (from other PID for example). Before this patch, this would result in sending buffers without any timestamp which would cause a wide variety of issues. Instead, pad segment and buffer timestamps with an extra value (packetizer->extra_shift, default to 2s), to ensure that we can get valid timestamps on outgoing buffers (even if that means they are before the segment start). Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
2021-09-05 09:57:18 +00:00
res = pts + pcrtable->pcroffset + packetizer->extra_shift;
mpegtspacketizer: live: handle pcr/dts discrepancies some more When wrapover/reset occur, we end up with a small window of time where the PTS/DTS will still be using the previous/next time-range. In order not to return bogus values, return GST_CLOCK_TIME_NONE if the PTS/DTS value to convert differs by more than 15s against the last seen PCR https://bugzilla.gnome.org/show_bug.cgi?id=674536
2014-06-13 09:46:19 +00:00
/* Don't return anything if we differ too much against last seen PCR */
tsdemux: Don't check SCTE events for being too far from the PCR Otherwise it happens that SCTE events can only be scheduled up to 15 seconds since the last seen PCR, which is a useless restriction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2021>
2022-03-24 17:55:48 +00:00
if (G_UNLIKELY (check_diff && pcr_pid != 0x1fff &&
ABSDIFF (res, pcrtable->last_pcrtime) > 15 * GST_SECOND)) {
mpegtspacketizer: live: handle pcr/dts discrepancies some more When wrapover/reset occur, we end up with a small window of time where the PTS/DTS will still be using the previous/next time-range. In order not to return bogus values, return GST_CLOCK_TIME_NONE if the PTS/DTS value to convert differs by more than 15s against the last seen PCR https://bugzilla.gnome.org/show_bug.cgi?id=674536
2014-06-13 09:46:19 +00:00
res = GST_CLOCK_TIME_NONE;
tsdemux: Don't check SCTE events for being too far from the PCR Otherwise it happens that SCTE events can only be scheduled up to 15 seconds since the last seen PCR, which is a useless restriction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2021>
2022-03-24 17:55:48 +00:00
} else {
mpegtspacketizer: avoid timestamp overflows Cause timing to break in the pipeline that can lead to a stall https://bugzilla.gnome.org/show_bug.cgi?id=733837
2014-07-29 05:11:54 +00:00
GstClockTime tmp = pcrtable->base_time + pcrtable->skew;
tsdemux: Handle PTS->TS at wraparound This has been a FIXME for ages. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
2021-09-05 09:53:05 +00:00
if (tmp + res >= pcrtable->base_pcrtime) {
mpegtspacketizer: avoid timestamp overflows Cause timing to break in the pipeline that can lead to a stall https://bugzilla.gnome.org/show_bug.cgi?id=733837
2014-07-29 05:11:54 +00:00
res += tmp - pcrtable->base_pcrtime;
tsdemux: Don't check SCTE events for being too far from the PCR Otherwise it happens that SCTE events can only be scheduled up to 15 seconds since the last seen PCR, which is a useless restriction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2021>
2022-03-24 17:55:48 +00:00
} else if (!check_diff || ABSDIFF (tmp + res + PCR_GST_MAX_VALUE,
tsdemux: Handle PTS->TS at wraparound This has been a FIXME for ages. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
2021-09-05 09:53:05 +00:00
pcrtable->base_pcrtime) < PCR_GST_MAX_VALUE / 2) {
/* Handle wrapover */
res += tmp + PCR_GST_MAX_VALUE - pcrtable->base_pcrtime;
} else {
/* Fallback for values that differ way too much */
mpegtspacketizer: avoid timestamp overflows Cause timing to break in the pipeline that can lead to a stall https://bugzilla.gnome.org/show_bug.cgi?id=733837
2014-07-29 05:11:54 +00:00
res = GST_CLOCK_TIME_NONE;
tsdemux: Handle PTS->TS at wraparound This has been a FIXME for ages. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
2021-09-05 09:53:05 +00:00
}
mpegtspacketizer: avoid timestamp overflows Cause timing to break in the pipeline that can lead to a stall https://bugzilla.gnome.org/show_bug.cgi?id=733837
2014-07-29 05:11:54 +00:00
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
} else if (packetizer->calculate_offset && pcrtable->groups) {
gint64 refpcr = G_MAXINT64, refpcroffset;
PCROffsetGroup *group = pcrtable->current->group;
/* Generic calculation:
* Stream Time = PTS - first group PCR + group PCR_offset
*
* In case of wrapover:
* Stream Time = PTS + MAX_PCR - first group PCR + group PCR_offset
* (which we actually do by using first group PCR -= MAX_PCR in order
* to end up with the same calculation as for non-wrapover) */
if (group) {
/* If we have a current group the value is pretty much guaranteed */
GST_DEBUG ("Using current First PCR:%" GST_TIME_FORMAT " offset:%"
G_GUINT64_FORMAT " PCR_offset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->first_pcr)),
group->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->pcr_offset)));
refpcr = group->first_pcr;
refpcroffset = group->pcr_offset;
mpegtspacketizer: Handle early PTS conversion When handling the PTS/DTS conversion in new groups, there's a possibility that the PTS might be smaller than the first PCR value observed, due to re-ordering. When using the current group, only apply the wraparound correction when we are certain it is one (i.e. differs by more than a second) and not when it's just a small difference (like out-of-order PTS). https://bugzilla.gnome.org/show_bug.cgi?id=731088
2014-06-02 09:07:01 +00:00
if (pts < PCRTIME_TO_GSTTIME (refpcr)) {
/* Only apply wrapover if we're certain it is, and avoid
* returning bogus values if it's a PTS/DTS which is *just*
* before the start of the current group
*/
mpegtspacketizer: Fix wraparound detection issue Using 32bit unsigned values for corrected pcr/offset meant that we potentially ended up in bogus values Furthermore, refpcr - refpcroffset could end up being negative, which PCRTIME_TO_GSTTIME() can't handle (and returned a massive positive value)
2014-06-13 08:37:46 +00:00
if (PCRTIME_TO_GSTTIME (refpcr) - pts > GST_SECOND) {
pts += PCR_GST_MAX_VALUE;
} else
mpegtspacketizer: Handle early PTS conversion When handling the PTS/DTS conversion in new groups, there's a possibility that the PTS might be smaller than the first PCR value observed, due to re-ordering. When using the current group, only apply the wraparound correction when we are certain it is one (i.e. differs by more than a second) and not when it's just a small difference (like out-of-order PTS). https://bugzilla.gnome.org/show_bug.cgi?id=731088
2014-06-02 09:07:01 +00:00
refpcr = G_MAXINT64;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
} else {
GList *tmp;
/* Otherwise, find a suitable group */
GST_DEBUG ("Find group for current offset %" G_GUINT64_FORMAT,
packetizer->offset);
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
PCROffsetGroup *tgroup = tmp->data;
GST_DEBUG ("Trying First PCR:%" GST_TIME_FORMAT " offset:%"
G_GUINT64_FORMAT " PCR_offset:%" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->first_pcr)),
tgroup->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->pcr_offset)));
/* Gone too far ? */
if (tgroup->first_offset > packetizer->offset) {
/* If there isn't a pending reset, use that value */
if (group) {
GST_DEBUG ("PTS is %" GST_TIME_FORMAT " into group",
GST_TIME_ARGS (pts - PCRTIME_TO_GSTTIME (group->first_pcr)));
}
break;
}
group = tgroup;
/* In that group ? */
if (group->first_offset + group->values[group->last_value].offset >
packetizer->offset) {
GST_DEBUG ("PTS is %" GST_TIME_FORMAT " into group",
GST_TIME_ARGS (pts - PCRTIME_TO_GSTTIME (group->first_pcr)));
break;
}
}
if (group && !(group->flags & PCR_GROUP_FLAG_RESET)) {
GST_DEBUG ("Using group !");
refpcr = group->first_pcr;
refpcroffset = group->pcr_offset;
mpegtspacketizer: handle early PTS conversion when a group has been found In some cases, the PTS might be smaller than the first observed PCR value which causes element to apply wraparound leading to bogus timestamp. To solve this, we only apply it if the PTS-PCR difference is greater that 1 second to be sure that it's a real wraparound. Moreover, using unsigned 32 bits values to handle wrapover could end up with bogus value, so it use pts value to handle it. Also, convert pcr time to gst time before comparing it to pts. Since refpcr is expressed in PCR time base while pts is expressed in GStreamer time. https://bugzilla.gnome.org/show_bug.cgi?id=743259
2015-01-20 15:20:10 +00:00
if (pts < PCRTIME_TO_GSTTIME (refpcr)) {
if (PCRTIME_TO_GSTTIME (refpcr) - pts > GST_SECOND)
pts += PCR_GST_MAX_VALUE;
else
refpcr = G_MAXINT64;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
}
if (refpcr != G_MAXINT64)
mpegtspacketizer: Fix wraparound detection issue Using 32bit unsigned values for corrected pcr/offset meant that we potentially ended up in bogus values Furthermore, refpcr - refpcroffset could end up being negative, which PCRTIME_TO_GSTTIME() can't handle (and returned a massive positive value)
2014-06-13 08:37:46 +00:00
res =
pts - PCRTIME_TO_GSTTIME (refpcr) + PCRTIME_TO_GSTTIME (refpcroffset);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
else
GST_WARNING ("No groups, can't calculate timestamp");
mpegts: Only use timestamp-based PCR/PTS estimation when needed When dealing with non-time based push-mode streams, we need to revert to using the offset-based PCR/PTS estimation logic of packetizer. This solves uses cases such as: pushfile:// ! tsdemux src ! queue ! tsdemux https://bugzilla.gnome.org/show_bug.cgi?id=687178
2012-11-08 16:15:26 +00:00
} else
GST_WARNING ("Not enough information to calculate proper timestamp");
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
GST_DEBUG ("Returning timestamp %" GST_TIME_FORMAT " for pts %"
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
GST_TIME_FORMAT " pcr_pid:0x%04x", GST_TIME_ARGS (res),
GST_TIME_ARGS (pts), pcr_pid);
mpegtspacketizer: Handle rollover in offset calculations
2012-03-05 11:46:13 +00:00
return res;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
}
tsdemux: Don't check SCTE events for being too far from the PCR Otherwise it happens that SCTE events can only be scheduled up to 15 seconds since the last seen PCR, which is a useless restriction. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2021>
2022-03-24 17:55:48 +00:00
/* Input : local PTS (in GHz units)
* Return : Stream time (in GHz units) */
GstClockTime
mpegts_packetizer_pts_to_ts_unchecked (MpegTSPacketizer2 * packetizer,
GstClockTime pts, guint16 pcr_pid)
{
return mpegts_packetizer_pts_to_ts_internal (packetizer, pts, pcr_pid, FALSE);
}
/* Input : local PTS (in GHz units)
* Return : Stream time (in GHz units) */
GstClockTime
mpegts_packetizer_pts_to_ts (MpegTSPacketizer2 * packetizer,
GstClockTime pts, guint16 pcr_pid)
{
return mpegts_packetizer_pts_to_ts_internal (packetizer, pts, pcr_pid, TRUE);
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Stream time to offset */
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
guint64
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
mpegts_packetizer_ts_to_offset (MpegTSPacketizer2 * packetizer,
GstClockTime ts, guint16 pcr_pid)
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
{
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
MpegTSPCR *pcrtable;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
guint64 res;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
PCROffsetGroup *nextgroup = NULL, *prevgroup = NULL;
guint64 querypcr, firstpcr, lastpcr, firstoffset, lastoffset;
mpegtspacketizer: Improve ts_to_offset code * Search in current pending values first. For CBR streams we can very easily end up having just one initial observations and then nothing else (since the bitrate doesn't change). * Use one group whether we are in that group *OR* if there is only one group. * If the group to use isn't closed (points are being accumulated in the PCROffsetCurrent), use the latest data available for calculation * If in the unlikelyness that all of this *still* didn't produce more than one data point, just return the initial offset
2014-04-18 14:23:43 +00:00
PCROffsetCurrent *current;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GList *tmp;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
if (!packetizer->calculate_offset)
return -1;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
tsdemux: Calculate pcr/time/offset separately per program Avoids quite a few issues with multi-program streams
2012-06-26 16:59:32 +00:00
pcrtable = get_pcr_table (packetizer, pcr_pid);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
if (pcrtable->groups == NULL) {
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
return -1;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
}
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
querypcr = GSTTIME_TO_PCRTIME (ts);
GST_DEBUG ("Searching offset for ts %" GST_TIME_FORMAT, GST_TIME_ARGS (ts));
mpegtspacketizer: Improve ts_to_offset code * Search in current pending values first. For CBR streams we can very easily end up having just one initial observations and then nothing else (since the bitrate doesn't change). * Use one group whether we are in that group *OR* if there is only one group. * If the group to use isn't closed (points are being accumulated in the PCROffsetCurrent), use the latest data available for calculation * If in the unlikelyness that all of this *still* didn't produce more than one data point, just return the initial offset
2014-04-18 14:23:43 +00:00
/* First check if we're within the current pending group */
current = pcrtable->current;
if (current && current->group && (querypcr >= current->group->pcr_offset) &&
querypcr - current->group->pcr_offset <=
current->pending[current->last].pcr) {
GST_DEBUG ("pcr is in current group");
nextgroup = current->group;
goto calculate_points;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
/* Find the neighbouring groups */
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
nextgroup = (PCROffsetGroup *) tmp->data;
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Trying group PCR %" GST_TIME_FORMAT " (offset %"
G_GUINT64_FORMAT " pcr_offset %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (nextgroup->first_pcr)),
nextgroup->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (nextgroup->pcr_offset)));
/* Check if we've gone too far */
if (nextgroup->pcr_offset > querypcr) {
GST_DEBUG ("pcr is before that group");
break;
}
mpegtspacketizer: Fix ts_to_offset beyond last observed PCR The requested TS might be beyond the last observed PCR. In order to calculate a coherent offset, we need to use the last and previous-to-last groups. https://bugzilla.gnome.org/show_bug.cgi?id=721035
2013-12-29 15:00:01 +00:00
if (tmp->next == NULL) {
GST_DEBUG ("pcr is beyond last group");
break;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
prevgroup = nextgroup;
/* Maybe it's in this group */
if (nextgroup->values[nextgroup->last_value].pcr +
nextgroup->pcr_offset >= querypcr) {
GST_DEBUG ("pcr is in that group");
break;
}
}
mpegtspacketizer: Improve ts_to_offset code * Search in current pending values first. For CBR streams we can very easily end up having just one initial observations and then nothing else (since the bitrate doesn't change). * Use one group whether we are in that group *OR* if there is only one group. * If the group to use isn't closed (points are being accumulated in the PCROffsetCurrent), use the latest data available for calculation * If in the unlikelyness that all of this *still* didn't produce more than one data point, just return the initial offset
2014-04-18 14:23:43 +00:00
calculate_points:
GST_DEBUG ("nextgroup:%p, prevgroup:%p", nextgroup, prevgroup);
if (nextgroup == prevgroup || prevgroup == NULL) {
/* We use the current group to calculate position:
* * if the PCR is within this group
* * if there is only one group to use for calculation
*/
GST_DEBUG ("In group or after last one");
lastoffset = firstoffset = nextgroup->first_offset;
lastpcr = firstpcr = nextgroup->pcr_offset;
if (current && nextgroup == current->group) {
lastoffset += current->pending[current->last].offset;
lastpcr += current->pending[current->last].pcr;
} else {
lastoffset += nextgroup->values[nextgroup->last_value].offset;
lastpcr += nextgroup->values[nextgroup->last_value].pcr;
}
mpegtspacketizer: Remove dead code and simplify if statement CID 1204274
2014-04-22 10:56:54 +00:00
} else {
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Between group");
lastoffset = nextgroup->first_offset;
lastpcr = nextgroup->pcr_offset;
firstoffset =
prevgroup->values[prevgroup->last_value].offset +
prevgroup->first_offset;
firstpcr =
prevgroup->values[prevgroup->last_value].pcr + prevgroup->pcr_offset;
}
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Using prev PCR %" G_GUINT64_FORMAT " offset %" G_GUINT64_FORMAT,
firstpcr, firstoffset);
GST_DEBUG ("Using last PCR %" G_GUINT64_FORMAT " offset %" G_GUINT64_FORMAT,
lastpcr, lastoffset);
mpegtspacketizer: Improve ts_to_offset code * Search in current pending values first. For CBR streams we can very easily end up having just one initial observations and then nothing else (since the bitrate doesn't change). * Use one group whether we are in that group *OR* if there is only one group. * If the group to use isn't closed (points are being accumulated in the PCROffsetCurrent), use the latest data available for calculation * If in the unlikelyness that all of this *still* didn't produce more than one data point, just return the initial offset
2014-04-18 14:23:43 +00:00
res = firstoffset;
if (lastpcr != firstpcr)
res += gst_util_uint64_scale (querypcr - firstpcr,
lastoffset - firstoffset, lastpcr - firstpcr);
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
mpegtsdemux: Switch to MPEG-TS SI library * Only mpeg-ts section packetization remains. * Improve code to detect duplicated sections as early as possible * Add FIXME for various issues that need fixing (but are not regressions) https://bugzilla.gnome.org/show_bug.cgi?id=702724
2013-06-23 06:43:23 +00:00
GST_DEBUG ("Returning offset %" G_GUINT64_FORMAT " for ts %"
GST_TIME_FORMAT, res, GST_TIME_ARGS (ts));
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
return res;
}
void
mpegts_packetizer_set_reference_offset (MpegTSPacketizer2 * packetizer,
guint64 refoffset)
{
GST_DEBUG ("Setting reference offset to %" G_GUINT64_FORMAT, refoffset);
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
mpegtspacketizer: No longer use a private struct These are not public headers, it just adds complexity for no reason
2013-07-05 15:11:46 +00:00
packetizer->refoffset = refoffset;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Offset calculation Allows PCR<=>PTS<=>offset estimation/calculation Right now the calculation is very naive, but can be extended later on without disrupting the code in tsdemux/mpegtsbase
2012-03-01 16:56:34 +00:00
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
tsparse: Handle backward and discont timestamps better. Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
2014-10-29 11:58:37 +00:00
void
mpegts_packetizer_set_pcr_discont_threshold (MpegTSPacketizer2 * packetizer,
GstClockTime threshold)
{
PACKETIZER_GROUP_LOCK (packetizer);
packetizer->pcr_discont_threshold = threshold;
PACKETIZER_GROUP_UNLOCK (packetizer);
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
void
mpegts_packetizer_set_current_pcr_offset (MpegTSPacketizer2 * packetizer,
GstClockTime offset, guint16 pcr_pid)
{
guint64 pcr_offset;
gint64 delta;
MpegTSPCR *pcrtable;
PCROffsetGroup *group;
GList *tmp;
gboolean apply = FALSE;
/* fast path */
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_LOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
pcrtable = get_pcr_table (packetizer, pcr_pid);
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
if (pcrtable == NULL || pcrtable->current->group == NULL) {
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
return;
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
pcr_offset = GSTTIME_TO_PCRTIME (offset);
mpegtspacketizer: Use first group for handling reference pcr If _set_current_pcr_offset gets called after a flushing seek, we ended up using the current group for delta calculation ... whereas we should be using the first group to calculate shifts. Also add an early exit if there are no changes to apply
2014-06-11 07:38:00 +00:00
/* Pick delta from *first* group */
if (pcrtable->groups)
group = pcrtable->groups->data;
else
group = pcrtable->current->group;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Current group PCR %" GST_TIME_FORMAT " (offset %"
G_GUINT64_FORMAT " pcr_offset %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->first_pcr)),
group->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (group->pcr_offset)));
/* Remember the difference between previous initial pcr_offset and
* new initial pcr_offset */
delta = pcr_offset - group->pcr_offset;
mpegtspacketizer: Use first group for handling reference pcr If _set_current_pcr_offset gets called after a flushing seek, we ended up using the current group for delta calculation ... whereas we should be using the first group to calculate shifts. Also add an early exit if there are no changes to apply
2014-06-11 07:38:00 +00:00
if (delta == 0) {
GST_DEBUG ("No shift to apply");
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtspacketizer: Use first group for handling reference pcr If _set_current_pcr_offset gets called after a flushing seek, we ended up using the current group for delta calculation ... whereas we should be using the first group to calculate shifts. Also add an early exit if there are no changes to apply
2014-06-11 07:38:00 +00:00
return;
}
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Shifting groups by %" GST_TIME_FORMAT
" for new initial pcr_offset %" GST_TIME_FORMAT,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (delta)), GST_TIME_ARGS (offset));
for (tmp = pcrtable->groups; tmp; tmp = tmp->next) {
PCROffsetGroup *tgroup = (tmp->data);
if (tgroup == group)
apply = TRUE;
if (apply) {
tsdemux: Fix mpegts_packetizer_set_current_pcr_offset() When adjusting the PCR offset of groups, adjust the correct group entry from the list - not the current group repeatedly.
2014-03-25 10:40:11 +00:00
tgroup->pcr_offset += delta;
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
GST_DEBUG ("Update group PCR %" GST_TIME_FORMAT " (offset %"
G_GUINT64_FORMAT " pcr_offset %" GST_TIME_FORMAT,
tsdemux: Fix mpegts_packetizer_set_current_pcr_offset() When adjusting the PCR offset of groups, adjust the correct group entry from the list - not the current group repeatedly.
2014-03-25 10:40:11 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->first_pcr)),
tgroup->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->pcr_offset)));
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
} else
GST_DEBUG ("Not modifying group PCR %" GST_TIME_FORMAT " (offset %"
G_GUINT64_FORMAT " pcr_offset %" GST_TIME_FORMAT,
tsdemux: Fix mpegts_packetizer_set_current_pcr_offset() When adjusting the PCR offset of groups, adjust the correct group entry from the list - not the current group repeatedly.
2014-03-25 10:40:11 +00:00
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->first_pcr)),
tgroup->first_offset,
GST_TIME_ARGS (PCRTIME_TO_GSTTIME (tgroup->pcr_offset)));
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
tsdemux: Add locking around mpegtspacketiser groups. Otherwise occasionally DURATION queries can crash, if they happen at the wrong moment.
2014-07-03 11:39:19 +00:00
PACKETIZER_GROUP_UNLOCK (packetizer);
mpegtsdemux: New PCR<=>Offset estimation code This allows: * Better duration estimation * More accurate PCR location * Overall more accurate running-time location and calculation Location and values of PCR are recorded in groups (PCROffsetGroup) with notable PCR/Offset observations in them (when bitrate changed for example). PCR and offset are stored as 32bit values to reduce memory usage (they are differences against that group's first_{pcr|offset}. Those groups each contain a global PCR offset (pcr_offset) which indicates how far in the stream that group is. Whenever new PCR values are observed, we store them in a sliding window estimator (PCROffsetGroupCurrent). When a reset/wrapover/gap is detected, we close the current group with current values and start a new one (the pcr_offset of that new group is also calculated). When a notable change in bitrate is observed (+/- 10%), we record new values in the current group. This is a compromise between storing all PCR/offset observations and none, while at the same time providing better information for running-time<=>offset calculation in VBR streams. Whenever a new non-contiguous group is start (due to seeking for example) we re-evaluate the pcr_offset of each groups. This allows detecting as quickly as possible PCR wrapover/reset. When wanting to find the offset of a certain running-time, one can iterate the groups by looking at the pcr_offset (which in essence *is* the running-time of that group in the overall stream). Once a group (or neighbouring groups if the running-time is between two groups) is found, once can use the recorded values to find the most accurate offset. Right now this code is only used in pull-mode , but could also be activated later on for any seekable stream, like live timeshift with queue2. Future improvements: * some heuristics to "compress" the stored values in groups so as to keep the memory usage down while still keeping a decent amount of notable points. * After a seek compare expected and obtained PCR/Offset and if the difference is too big, re-calculate position with newly observed values and seek to that more accurate position. Note that this code will *not* provide keyframe-accurate seeking, but will allow a much more accurate PCR/running-time/offset location on any random stream. For past (observed) values it will be as accurate as can be. For future values it will be better than the current situation. Finally the more you seek, the more accurate your positioning will be.
2013-07-26 05:54:30 +00:00
}
Reference in a new issue Copy permalink