2011-02-16 16:57:42 +00:00
|
|
|
/*
|
2012-02-15 14:06:57 +00:00
|
|
|
* mpegtspacketizer.c -
|
2011-02-16 16:57:42 +00:00
|
|
|
* Copyright (C) 2007, 2008 Alessandro Decina, Zaheer Merali
|
2012-02-15 14:06:57 +00:00
|
|
|
*
|
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
|
2012-11-03 20:38:00 +00:00
|
|
|
* Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
|
|
|
|
|
* Boston, MA 02110-1301, USA.
|
2011-02-16 16:57:42 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <string.h>
|
2013-06-23 06:43:23 +00:00
|
|
|
#include <stdlib.h>
|
2012-02-16 12:54:24 +00:00
|
|
|
|
2012-02-23 17:46:09 +00:00
|
|
|
/* Skew calculation pameters */
|
|
|
|
|
#define MAX_TIME (2 * GST_SECOND)
|
2012-02-16 12:54:24 +00:00
|
|
|
|
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))
|
2012-03-05 11:46:13 +00:00
|
|
|
#define PTS_DTS_MAX_VALUE (((guint64)1) << 33)
|
|
|
|
|
|
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))
|
|
|
|
|
|
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))
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
static void mpegts_packetizer_dispose (GObject * object);
|
|
|
|
|
static void mpegts_packetizer_finalize (GObject * object);
|
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);
|
2012-06-26 16:59:32 +00:00
|
|
|
static void record_pcr (MpegTSPacketizer2 * packetizer, MpegTSPCR * pcrtable,
|
|
|
|
|
guint64 pcr, guint64 offset);
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
#define CONTINUITY_UNSET 255
|
|
|
|
|
#define VERSION_NUMBER_UNSET 255
|
|
|
|
|
#define TABLE_ID_UNSET 0xFF
|
2012-02-15 14:06:57 +00:00
|
|
|
#define PACKET_SYNC_BYTE 0x47
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
static inline MpegTSPCR *
|
2012-06-26 16:59:32 +00:00
|
|
|
get_pcr_table (MpegTSPacketizer2 * packetizer, guint16 pid)
|
|
|
|
|
{
|
|
|
|
|
MpegTSPCR *res;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
res = packetizer->observations[packetizer->pcrtablelut[pid]];
|
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 */
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->observations[packetizer->lastobsid] = res;
|
2012-06-26 16:59:32 +00:00
|
|
|
/* Update the pcrtablelut */
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->pcrtablelut[pid] = packetizer->lastobsid;
|
2012-06-26 16:59:32 +00:00
|
|
|
/* And increment the last know slot */
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->lastobsid++;
|
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;
|
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
|
|
|
|
|
|
|
|
res->current = g_slice_new0 (PCROffsetCurrent);
|
2012-06-26 16:59:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-17 23:19:36 +00:00
|
|
|
static void
|
|
|
|
|
pcr_offset_group_free (PCROffsetGroup * group)
|
|
|
|
|
{
|
|
|
|
|
g_free (group->values);
|
|
|
|
|
g_slice_free (PCROffsetGroup, group);
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-11 11:45:03 +00:00
|
|
|
static void
|
|
|
|
|
flush_observations (MpegTSPacketizer2 * packetizer)
|
|
|
|
|
{
|
|
|
|
|
gint i;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
for (i = 0; i < packetizer->lastobsid; i++) {
|
2014-01-17 23:19:36 +00:00
|
|
|
g_list_free_full (packetizer->observations[i]->groups,
|
|
|
|
|
(GDestroyNotify) pcr_offset_group_free);
|
2014-01-14 00:19:12 +00:00
|
|
|
if (packetizer->observations[i]->current)
|
|
|
|
|
g_slice_free (PCROffsetCurrent, packetizer->observations[i]->current);
|
2013-07-05 15:11:46 +00:00
|
|
|
g_free (packetizer->observations[i]);
|
|
|
|
|
packetizer->observations[i] = NULL;
|
2012-11-11 11:45:03 +00:00
|
|
|
}
|
2013-07-05 15:11:46 +00:00
|
|
|
memset (packetizer->pcrtablelut, 0xff, 0x2000);
|
|
|
|
|
packetizer->lastobsid = 0;
|
2012-11-11 11:45:03 +00:00
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-23 13:12:58 +00:00
|
|
|
static inline MpegTSPacketizerStreamSubtable *
|
|
|
|
|
find_subtable (GSList * subtables, guint8 table_id, guint16 subtable_extension)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2013-06-23 13:12:58 +00:00
|
|
|
GSList *tmp;
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
/* FIXME: Make this an array ! */
|
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;
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2015-04-27 13:44:28 +00:00
|
|
|
return NULL;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-19 18:39:54 +00:00
|
|
|
static gboolean
|
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,
|
|
|
|
|
guint8 last_section_number)
|
2013-06-19 18:39:54 +00:00
|
|
|
{
|
2013-06-23 06:43:23 +00:00
|
|
|
MpegTSPacketizerStreamSubtable *subtable;
|
2013-06-19 18:39:54 +00:00
|
|
|
|
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) {
|
2014-03-29 09:19:52 +00:00
|
|
|
GST_DEBUG ("Haven't seen subtable");
|
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 */
|
|
|
|
|
return MPEGTS_BIT_IS_SET (subtable->seen_section, section_number);
|
2013-06-19 18:39:54 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
static MpegTSPacketizerStreamSubtable *
|
|
|
|
|
mpegts_packetizer_stream_subtable_new (guint8 table_id,
|
2013-06-23 06:43:23 +00:00
|
|
|
guint16 subtable_extension, guint8 last_section_number)
|
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;
|
2013-06-23 06:43:23 +00:00
|
|
|
subtable->last_section_number = last_section_number;
|
2011-02-16 16:57:42 +00:00
|
|
|
return subtable;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static MpegTSPacketizerStream *
|
2013-06-23 06:43:23 +00:00
|
|
|
mpegts_packetizer_stream_new (guint16 pid)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
|
|
|
|
MpegTSPacketizerStream *stream;
|
|
|
|
|
|
|
|
|
|
stream = (MpegTSPacketizerStream *) g_new0 (MpegTSPacketizerStream, 1);
|
|
|
|
|
stream->continuity_counter = CONTINUITY_UNSET;
|
|
|
|
|
stream->subtables = NULL;
|
2013-06-23 06:43:23 +00:00
|
|
|
stream->table_id = TABLE_ID_UNSET;
|
|
|
|
|
stream->pid = pid;
|
2011-02-16 16:57:42 +00:00
|
|
|
return stream;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2012-05-21 15:48:54 +00:00
|
|
|
mpegts_packetizer_clear_section (MpegTSPacketizerStream * stream)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2012-05-21 15:48:54 +00:00
|
|
|
stream->continuity_counter = CONTINUITY_UNSET;
|
|
|
|
|
stream->section_length = 0;
|
|
|
|
|
stream->section_offset = 0;
|
2013-06-23 06:43:23 +00:00
|
|
|
stream->table_id = TABLE_ID_UNSET;
|
2015-11-17 23:23:17 +00:00
|
|
|
g_free (stream->section_data);
|
2013-06-23 06:43:23 +00:00
|
|
|
stream->section_data = NULL;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-19 18:39:54 +00:00
|
|
|
static void
|
|
|
|
|
mpegts_packetizer_stream_subtable_free (MpegTSPacketizerStreamSubtable *
|
|
|
|
|
subtable)
|
|
|
|
|
{
|
|
|
|
|
g_free (subtable);
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
static void
|
2012-05-21 15:48:54 +00:00
|
|
|
mpegts_packetizer_stream_free (MpegTSPacketizerStream * stream)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2012-05-21 15:48:54 +00:00
|
|
|
mpegts_packetizer_clear_section (stream);
|
2013-06-19 18:39:54 +00:00
|
|
|
g_slist_foreach (stream->subtables,
|
|
|
|
|
(GFunc) mpegts_packetizer_stream_subtable_free, NULL);
|
2012-05-21 15:48:54 +00:00
|
|
|
g_slist_free (stream->subtables);
|
|
|
|
|
g_free (stream);
|
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)
|
|
|
|
|
{
|
2014-07-03 11:39:19 +00:00
|
|
|
g_mutex_init (&packetizer->group_lock);
|
|
|
|
|
|
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);
|
2013-07-07 08:25:27 +00:00
|
|
|
packetizer->packet_size = 0;
|
2012-02-23 17:46:09 +00:00
|
|
|
packetizer->calculate_skew = FALSE;
|
2012-03-01 16:56:34 +00:00
|
|
|
packetizer->calculate_offset = FALSE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_data = NULL;
|
|
|
|
|
packetizer->map_size = 0;
|
|
|
|
|
packetizer->map_offset = 0;
|
|
|
|
|
packetizer->need_sync = FALSE;
|
2012-06-05 07:44:45 +00:00
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
memset (packetizer->pcrtablelut, 0xff, 0x2000);
|
|
|
|
|
memset (packetizer->observations, 0x0, sizeof (packetizer->observations));
|
|
|
|
|
packetizer->lastobsid = 0;
|
2012-06-26 16:59:32 +00:00
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->nb_seen_offsets = 0;
|
|
|
|
|
packetizer->refoffset = -1;
|
|
|
|
|
packetizer->last_in_time = GST_CLOCK_TIME_NONE;
|
2014-10-29 11:58:37 +00:00
|
|
|
packetizer->pcr_discont_threshold = GST_SECOND;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
mpegts_packetizer_dispose (GObject * object)
|
|
|
|
|
{
|
|
|
|
|
MpegTSPacketizer2 *packetizer = GST_MPEGTS_PACKETIZER (object);
|
|
|
|
|
|
|
|
|
|
if (!packetizer->disposed) {
|
2013-07-07 08:25:27 +00:00
|
|
|
if (packetizer->packet_size)
|
|
|
|
|
packetizer->packet_size = 0;
|
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);
|
2014-09-10 08:58:03 +00:00
|
|
|
g_mutex_clear (&packetizer->group_lock);
|
2011-02-16 16:57:42 +00:00
|
|
|
packetizer->disposed = TRUE;
|
|
|
|
|
packetizer->offset = 0;
|
|
|
|
|
packetizer->empty = TRUE;
|
2012-06-29 14:14:02 +00:00
|
|
|
|
2012-11-11 11:45:03 +00:00
|
|
|
flush_observations (packetizer);
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-01 16:53:41 +00:00
|
|
|
static inline guint64
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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++;
|
|
|
|
|
|
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) {
|
2011-02-16 16:57:42 +00:00
|
|
|
/* no payload, adaptation field of 183 bytes */
|
2013-10-11 08:32:52 +00:00
|
|
|
if (length > 183) {
|
2015-04-17 13:32:56 +00:00
|
|
|
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d > 183",
|
2013-10-11 08:32:52 +00:00
|
|
|
packet->pid, packet->scram_afc_cc & 0x30, length);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
if (length != 183) {
|
2015-04-17 13:32:56 +00:00
|
|
|
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d != 183",
|
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);
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
} else if (length > 182) {
|
2015-04-17 13:32:56 +00:00
|
|
|
GST_WARNING ("PID 0x%04x afc == 0x%02x and length %d > 182",
|
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;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (packet->data + length > packet->data_end) {
|
2015-04-17 13:32:56 +00:00
|
|
|
GST_DEBUG
|
|
|
|
|
("PID 0x%04x afc length %d overflows the buffer current %d max %d",
|
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++;
|
|
|
|
|
|
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>" : "");
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
/* PCR */
|
|
|
|
|
if (afcflags & MPEGTS_AFC_PCR_FLAG) {
|
2012-06-26 16:59:32 +00:00
|
|
|
MpegTSPCR *pcrtable = NULL;
|
2011-02-23 14:21:22 +00:00
|
|
|
packet->pcr = mpegts_packetizer_compute_pcr (data);
|
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);
|
|
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_LOCK (packetizer);
|
2013-07-07 08:25:27 +00:00
|
|
|
if (packetizer->calculate_skew
|
2013-07-05 15:11:46 +00:00
|
|
|
&& GST_CLOCK_TIME_IS_VALID (packetizer->last_in_time)) {
|
2012-06-26 16:59:32 +00:00
|
|
|
pcrtable = get_pcr_table (packetizer, packet->pid);
|
2014-10-29 11:58:37 +00:00
|
|
|
calculate_skew (packetizer, pcrtable, packet->pcr,
|
|
|
|
|
packetizer->last_in_time);
|
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);
|
|
|
|
|
}
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
2013-07-26 05:53:06 +00:00
|
|
|
#ifndef GST_DISABLE_GST_DEBUG
|
2011-02-16 16:57:42 +00:00
|
|
|
/* OPCR */
|
|
|
|
|
if (afcflags & MPEGTS_AFC_OPCR_FLAG) {
|
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;
|
2012-03-01 16:56:34 +00:00
|
|
|
GST_DEBUG ("opcr %" G_GUINT64_FORMAT " (%" GST_TIME_FORMAT ")",
|
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;
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
2013-07-26 05:53:06 +00:00
|
|
|
#endif
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-18 08:13:19 +00:00
|
|
|
static MpegTSPacketizerPacketReturn
|
2011-02-16 16:57:42 +00:00
|
|
|
mpegts_packetizer_parse_packet (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
MpegTSPacketizerPacket * packet)
|
|
|
|
|
{
|
|
|
|
|
guint8 *data;
|
2013-06-23 13:26:14 +00:00
|
|
|
guint8 tmp;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
data = packet->data_start;
|
2013-06-23 13:26:14 +00:00
|
|
|
data += 1;
|
|
|
|
|
tmp = *data;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2012-05-18 08:13:19 +00:00
|
|
|
/* transport_error_indicator 1 */
|
2013-06-23 13:26:14 +00:00
|
|
|
if (G_UNLIKELY (tmp & 0x80))
|
2012-05-18 08:13:19 +00:00
|
|
|
return PACKET_BAD;
|
|
|
|
|
|
|
|
|
|
/* payload_unit_start_indicator 1 */
|
2013-06-23 13:26:14 +00:00
|
|
|
packet->payload_unit_start_indicator = tmp & 0x40;
|
2012-05-18 08:13:19 +00:00
|
|
|
|
|
|
|
|
/* transport_priority 1 */
|
|
|
|
|
/* PID 13 */
|
2011-02-16 16:57:42 +00:00
|
|
|
packet->pid = GST_READ_UINT16_BE (data) & 0x1FFF;
|
|
|
|
|
data += 2;
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
packet->scram_afc_cc = tmp = *data++;
|
2012-05-18 08:13:19 +00:00
|
|
|
/* transport_scrambling_control 2 */
|
2013-06-23 13:26:14 +00:00
|
|
|
if (G_UNLIKELY (tmp & 0xc0))
|
2012-05-18 08:13:19 +00:00
|
|
|
return PACKET_BAD;
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
packet->data = data;
|
|
|
|
|
|
2014-06-04 11:31:21 +00:00
|
|
|
packet->afc_flags = 0;
|
|
|
|
|
packet->pcr = G_MAXUINT64;
|
|
|
|
|
|
|
|
|
|
if (FLAGS_HAS_AFC (tmp)) {
|
2011-02-16 16:57:42 +00:00
|
|
|
if (!mpegts_packetizer_parse_adaptation_field_control (packetizer, packet))
|
|
|
|
|
return FALSE;
|
2014-06-04 11:31:21 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
if (FLAGS_HAS_PAYLOAD (tmp))
|
2011-02-16 16:57:42 +00:00
|
|
|
packet->payload = packet->data;
|
|
|
|
|
else
|
|
|
|
|
packet->payload = NULL;
|
|
|
|
|
|
2012-05-18 08:13:19 +00:00
|
|
|
return PACKET_OK;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2014-06-25 12:50:05 +00:00
|
|
|
static GstMpegtsSection *
|
2011-02-16 16:57:42 +00:00
|
|
|
mpegts_packetizer_parse_section_header (MpegTSPacketizer2 * packetizer,
|
2013-06-23 06:43:23 +00:00
|
|
|
MpegTSPacketizerStream * stream)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
|
|
|
|
MpegTSPacketizerStreamSubtable *subtable;
|
2014-06-25 12:50:05 +00:00
|
|
|
GstMpegtsSection *res;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 13:12:58 +00:00
|
|
|
subtable =
|
2013-06-23 06:43:23 +00:00
|
|
|
find_subtable (stream->subtables, stream->table_id,
|
|
|
|
|
stream->subtable_extension);
|
2013-06-23 13:12:58 +00:00
|
|
|
if (subtable) {
|
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);
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
} else {
|
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;
|
2013-06-19 18:39:54 +00:00
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
stream->subtables = g_slist_prepend (stream->subtables, subtable);
|
|
|
|
|
}
|
|
|
|
|
|
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,
|
2013-07-07 06:29:37 +00:00
|
|
|
stream->section_length);
|
2013-06-23 06:43:23 +00:00
|
|
|
stream->section_data = NULL;
|
2013-07-07 06:29:37 +00:00
|
|
|
mpegts_packetizer_clear_section (stream);
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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;
|
|
|
|
|
}
|
2012-06-03 08:58:20 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
return res;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
void
|
|
|
|
|
mpegts_packetizer_clear (MpegTSPacketizer2 * packetizer)
|
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;
|
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
|
|
|
|
2016-03-03 14:31:01 +00:00
|
|
|
packetizer->packet_size = 0;
|
2013-07-07 08:25:27 +00:00
|
|
|
|
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 *));
|
|
|
|
|
}
|
2013-06-05 09:20:49 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
gst_adapter_clear (packetizer->adapter);
|
|
|
|
|
packetizer->offset = 0;
|
|
|
|
|
packetizer->empty = TRUE;
|
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;
|
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
|
|
|
|
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 */
|
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;
|
|
|
|
|
}
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
2013-06-05 09:20:49 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
void
|
|
|
|
|
mpegts_packetizer_flush (MpegTSPacketizer2 * packetizer, gboolean hard)
|
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;
|
2016-05-31 11:09:43 +00:00
|
|
|
MpegTSPCR *pcrtable;
|
2013-06-23 06:43:23 +00:00
|
|
|
GST_DEBUG ("Flushing");
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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]);
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
}
|
2013-06-23 06:43:23 +00:00
|
|
|
gst_adapter_clear (packetizer->adapter);
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
packetizer->offset = 0;
|
|
|
|
|
packetizer->empty = TRUE;
|
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;
|
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
|
|
|
|
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 */
|
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;
|
|
|
|
|
}
|
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
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
if (hard) {
|
|
|
|
|
/* For pull mode seeks in tsdemux the observation must be preserved */
|
|
|
|
|
flush_observations (packetizer);
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
void
|
|
|
|
|
mpegts_packetizer_remove_stream (MpegTSPacketizer2 * packetizer, gint16 pid)
|
|
|
|
|
{
|
|
|
|
|
MpegTSPacketizerStream *stream = packetizer->streams[pid];
|
|
|
|
|
if (stream) {
|
2015-04-17 13:32:56 +00:00
|
|
|
GST_INFO ("Removing stream for PID 0x%04x", pid);
|
2013-06-23 06:43:23 +00:00
|
|
|
mpegts_packetizer_stream_free (stream);
|
|
|
|
|
packetizer->streams[pid] = NULL;
|
2013-06-05 10:49:09 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
MpegTSPacketizer2 *
|
|
|
|
|
mpegts_packetizer_new (void)
|
2012-06-03 08:56:28 +00:00
|
|
|
{
|
2013-06-23 06:43:23 +00:00
|
|
|
MpegTSPacketizer2 *packetizer;
|
2012-06-03 08:56:28 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
packetizer =
|
|
|
|
|
GST_MPEGTS_PACKETIZER (g_object_new (GST_TYPE_MPEGTS_PACKETIZER, NULL));
|
2012-06-03 08:56:28 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
return packetizer;
|
2012-06-03 08:56:28 +00:00
|
|
|
}
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
void
|
|
|
|
|
mpegts_packetizer_push (MpegTSPacketizer2 * packetizer, GstBuffer * buffer)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2013-06-23 06:43:23 +00:00
|
|
|
if (G_UNLIKELY (packetizer->empty)) {
|
|
|
|
|
packetizer->empty = FALSE;
|
|
|
|
|
packetizer->offset = GST_BUFFER_OFFSET (buffer);
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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);
|
|
|
|
|
/* If buffer timestamp is valid, store it */
|
|
|
|
|
if (GST_CLOCK_TIME_IS_VALID (GST_BUFFER_TIMESTAMP (buffer)))
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->last_in_time = GST_BUFFER_TIMESTAMP (buffer);
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_data = NULL;
|
|
|
|
|
packetizer->map_size = 0;
|
|
|
|
|
packetizer->map_offset = 0;
|
2013-09-16 09:46:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
mpegts_packetizer_map (MpegTSPacketizer2 * packetizer, gsize size)
|
|
|
|
|
{
|
|
|
|
|
gsize available;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
if (packetizer->map_size - packetizer->map_offset >= size)
|
2013-09-16 09:46:27 +00:00
|
|
|
return TRUE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
|
2013-09-16 09:46:27 +00:00
|
|
|
|
|
|
|
|
available = gst_adapter_available (packetizer->adapter);
|
|
|
|
|
if (available < size)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_data =
|
|
|
|
|
(guint8 *) gst_adapter_map (packetizer->adapter, available);
|
|
|
|
|
if (!packetizer->map_data)
|
2013-09-16 09:46:27 +00:00
|
|
|
return FALSE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_size = available;
|
|
|
|
|
packetizer->map_offset = 0;
|
2013-09-16 09:46:27 +00:00
|
|
|
|
|
|
|
|
GST_LOG ("mapped %" G_GSIZE_FORMAT " bytes from adapter", available);
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
static gboolean
|
|
|
|
|
mpegts_try_discover_packet_size (MpegTSPacketizer2 * packetizer)
|
|
|
|
|
{
|
2013-09-16 09:46:27 +00:00
|
|
|
guint8 *data;
|
|
|
|
|
gsize size, i, j;
|
|
|
|
|
|
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
|
|
|
|
|
};
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
if (!mpegts_packetizer_map (packetizer, 4 * MPEGTS_MAX_PACKETSIZE))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
size = packetizer->map_size - packetizer->map_offset;
|
|
|
|
|
data = packetizer->map_data + packetizer->map_offset;
|
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;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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;
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
|
|
|
|
}
|
2013-09-16 09:46:27 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
out:
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_offset += i;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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);
|
2013-07-05 15:11:46 +00:00
|
|
|
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
|
2013-09-16 09:46:27 +00:00
|
|
|
return FALSE;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
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 &&
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_offset >= 4)
|
|
|
|
|
packetizer->map_offset -= 4;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
return TRUE;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
static gboolean
|
|
|
|
|
mpegts_packetizer_sync (MpegTSPacketizer2 * packetizer)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2013-10-23 15:58:49 +00:00
|
|
|
gboolean found = FALSE;
|
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;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
size = packetizer->map_size - packetizer->map_offset;
|
|
|
|
|
data = packetizer->map_data + packetizer->map_offset;
|
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;
|
|
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
2013-09-16 09:46:27 +00:00
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->map_offset += i - sync_offset;
|
2013-09-16 09:46:27 +00:00
|
|
|
|
|
|
|
|
if (!found)
|
2013-07-05 15:11:46 +00:00
|
|
|
mpegts_packetizer_flush_bytes (packetizer, packetizer->map_offset);
|
2013-09-16 09:46:27 +00:00
|
|
|
|
|
|
|
|
return found;
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
MpegTSPacketizerPacketReturn
|
|
|
|
|
mpegts_packetizer_next_packet (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
MpegTSPacketizerPacket * packet)
|
|
|
|
|
{
|
2013-09-16 09:46:27 +00:00
|
|
|
guint8 *packet_data;
|
2013-07-07 08:25:27 +00:00
|
|
|
guint packet_size;
|
2013-09-16 09:46:27 +00:00
|
|
|
gsize sync_offset;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-07-07 08:25:27 +00:00
|
|
|
packet_size = packetizer->packet_size;
|
|
|
|
|
if (G_UNLIKELY (!packet_size)) {
|
2013-06-23 06:43:23 +00:00
|
|
|
if (!mpegts_try_discover_packet_size (packetizer))
|
|
|
|
|
return PACKET_NEED_MORE;
|
2013-07-07 08:25:27 +00:00
|
|
|
packet_size = packetizer->packet_size;
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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) {
|
2013-07-05 15:11:46 +00:00
|
|
|
if (packetizer->need_sync) {
|
2013-09-16 09:46:27 +00:00
|
|
|
if (!mpegts_packetizer_sync (packetizer))
|
|
|
|
|
return PACKET_NEED_MORE;
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->need_sync = FALSE;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
if (!mpegts_packetizer_map (packetizer, packet_size))
|
|
|
|
|
return PACKET_NEED_MORE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
packet_data = &packetizer->map_data[packetizer->map_offset + sync_offset];
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
/* Check sync byte */
|
2013-09-16 09:46:27 +00:00
|
|
|
if (G_UNLIKELY (*packet_data != PACKET_SYNC_BYTE)) {
|
|
|
|
|
GST_DEBUG ("lost sync");
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->need_sync = TRUE;
|
2013-09-16 09:46:27 +00:00
|
|
|
} else {
|
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 */
|
2013-09-16 09:46:27 +00:00
|
|
|
packet->data_start = packet_data;
|
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);
|
2013-07-07 08:25:27 +00:00
|
|
|
packetizer->offset += packet_size;
|
2013-05-27 20:22:32 +00:00
|
|
|
GST_MEMDUMP ("data_start", packet->data_start, 16);
|
2012-05-21 15:48:54 +00:00
|
|
|
|
2013-09-16 09:46:27 +00:00
|
|
|
return mpegts_packetizer_parse_packet (packetizer, packet);
|
2012-06-05 07:44:45 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-01 16:53:41 +00:00
|
|
|
MpegTSPacketizerPacketReturn
|
|
|
|
|
mpegts_packetizer_process_next_packet (MpegTSPacketizer2 * packetizer)
|
|
|
|
|
{
|
|
|
|
|
MpegTSPacketizerPacket packet;
|
2012-04-02 13:25:46 +00:00
|
|
|
MpegTSPacketizerPacketReturn ret;
|
2012-03-01 16:53:41 +00:00
|
|
|
|
2012-04-02 13:25:46 +00:00
|
|
|
ret = mpegts_packetizer_next_packet (packetizer, &packet);
|
2013-09-16 09:46:27 +00:00
|
|
|
if (ret != PACKET_NEED_MORE)
|
|
|
|
|
mpegts_packetizer_clear_packet (packetizer, &packet);
|
|
|
|
|
|
2012-04-02 13:25:46 +00:00
|
|
|
return ret;
|
2012-03-01 16:53:41 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-16 16:57:42 +00:00
|
|
|
void
|
|
|
|
|
mpegts_packetizer_clear_packet (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
MpegTSPacketizerPacket * packet)
|
|
|
|
|
{
|
2013-07-07 08:25:27 +00:00
|
|
|
guint8 packet_size = packetizer->packet_size;
|
2012-07-24 18:39:41 +00:00
|
|
|
|
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);
|
2013-09-16 09:46:27 +00:00
|
|
|
}
|
|
|
|
|
}
|
2012-07-24 18:39:41 +00:00
|
|
|
|
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;
|
2012-06-05 07:44:45 +00:00
|
|
|
}
|
2013-09-16 09:46:27 +00:00
|
|
|
return gst_adapter_available (packetizer->adapter) >= packetizer->packet_size;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
*
|
2014-06-25 12:50:05 +00:00
|
|
|
* The section should be a new GstMpegtsSection:
|
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
|
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.
|
2013-06-23 06:43:23 +00:00
|
|
|
* */
|
2014-06-25 12:50:05 +00:00
|
|
|
GstMpegtsSection *
|
2011-02-16 16:57:42 +00:00
|
|
|
mpegts_packetizer_push_section (MpegTSPacketizer2 * packetizer,
|
2013-07-07 06:29:37 +00:00
|
|
|
MpegTSPacketizerPacket * packet, GList ** remaining)
|
2011-02-16 16:57:42 +00:00
|
|
|
{
|
2014-06-25 12:50:05 +00:00
|
|
|
GstMpegtsSection *section;
|
|
|
|
|
GstMpegtsSection *res = NULL;
|
2011-02-16 16:57:42 +00:00
|
|
|
MpegTSPacketizerStream *stream;
|
2013-06-23 06:43:23 +00:00
|
|
|
gboolean long_packet;
|
2013-07-07 06:29:37 +00:00
|
|
|
guint8 pointer = 0, table_id;
|
2013-06-23 06:43:23 +00:00
|
|
|
guint16 subtable_extension = 0;
|
2013-07-07 06:29:37 +00:00
|
|
|
gsize to_read;
|
2011-02-16 16:57:42 +00:00
|
|
|
guint section_length;
|
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 */
|
2012-05-21 15:48:54 +00:00
|
|
|
guint8 *data, *data_start;
|
2013-06-23 06:43:23 +00:00
|
|
|
guint8 packet_cc;
|
2013-07-07 06:29:37 +00:00
|
|
|
GList *others = NULL;
|
|
|
|
|
guint8 version_number, section_number, last_section_number;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
data = packet->data;
|
2013-06-23 06:43:23 +00:00
|
|
|
packet_cc = FLAGS_CONTINUITY_COUNTER (packet->scram_afc_cc);
|
|
|
|
|
|
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)
|
|
|
|
|
*
|
|
|
|
|
**/
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-06-23 13:26:14 +00:00
|
|
|
if (packet->payload_unit_start_indicator) {
|
2011-02-16 16:57:42 +00:00
|
|
|
pointer = *data++;
|
2013-07-07 06:29:37 +00:00
|
|
|
/* If the pointer is zero, we're guaranteed to be able to handle it */
|
|
|
|
|
if (pointer == 0) {
|
|
|
|
|
GST_LOG
|
|
|
|
|
("PID 0x%04x PUSI and pointer == 0, skipping straight to section_start parsing",
|
|
|
|
|
packet->pid);
|
2015-11-12 15:35:12 +00:00
|
|
|
mpegts_packetizer_clear_section (stream);
|
2013-07-07 06:29:37 +00:00
|
|
|
goto section_start;
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
2013-07-07 06:29:37 +00:00
|
|
|
}
|
2011-02-16 16:57:42 +00:00
|
|
|
|
2013-07-07 06:29:37 +00:00
|
|
|
if (stream->continuity_counter == CONTINUITY_UNSET ||
|
|
|
|
|
(stream->continuity_counter + 1) % 16 != packet_cc) {
|
|
|
|
|
if (stream->continuity_counter != CONTINUITY_UNSET)
|
|
|
|
|
GST_WARNING ("PID 0x%04x section discontinuity (%d vs %d)", packet->pid,
|
|
|
|
|
stream->continuity_counter, packet_cc);
|
|
|
|
|
mpegts_packetizer_clear_section (stream);
|
|
|
|
|
/* 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 */
|
2011-02-16 16:57:42 +00:00
|
|
|
data += pointer;
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
2012-05-21 15:48:54 +00:00
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-08 06:44:43 +00:00
|
|
|
/* FIXME : We need at least 8 bytes with current algorithm :(
|
|
|
|
|
* We might end up losing sections that start across two packets (srsl...) */
|
|
|
|
|
if (data > packet->data_end - 8 || *data == 0xff) {
|
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:%"
|
2014-11-24 12:28:42 +00:00
|
|
|
G_GSIZE_FORMAT ")", stream->pid, (gsize) (packet->data_end - data));
|
2013-07-07 06:29:37 +00:00
|
|
|
|
|
|
|
|
section_start:
|
|
|
|
|
GST_MEMDUMP ("section_start", data, packet->data_end - data);
|
|
|
|
|
data_start = data;
|
|
|
|
|
/* Beginning of a new section */
|
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 */
|
2013-07-07 06:29:37 +00:00
|
|
|
if (!long_packet) {
|
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 */
|
|
|
|
|
if (section_length < packet->data_end - data) {
|
2013-07-07 06:29:37 +00:00
|
|
|
if ((section =
|
|
|
|
|
gst_mpegts_section_new (packet->pid, g_memdup (data,
|
|
|
|
|
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;
|
2013-06-23 06:43:23 +00:00
|
|
|
}
|
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 */
|
2012-02-27 12:45:29 +00:00
|
|
|
goto out;
|
|
|
|
|
}
|
2013-06-23 06:43:23 +00:00
|
|
|
/* We don't have enough bytes to do short section shortcut */
|
2011-02-16 16:57:42 +00:00
|
|
|
}
|
|
|
|
|
|
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++;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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;
|
2013-06-23 06:43:23 +00:00
|
|
|
|
2013-07-07 06:29:37 +00:00
|
|
|
if (long_packet) {
|
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;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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 */
|
2013-09-15 11:39:16 +00:00
|
|
|
if (G_UNLIKELY (!(*data & 0x01))) {
|
2011-02-16 16:57:42 +00:00
|
|
|
GST_DEBUG
|
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++;
|
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
|
|
|
|
|
*/
|
|
|
|
|
if (seen_section_before (stream, table_id, subtable_extension,
|
|
|
|
|
version_number, section_number, last_section_number)) {
|
2013-06-23 06:43:23 +00:00
|
|
|
GST_DEBUG
|
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",
|
2013-06-23 06:43:23 +00:00
|
|
|
packet->pid, table_id, subtable_extension, version_number,
|
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)
|
2013-06-23 06:43:23 +00:00
|
|
|
goto out;
|
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;
|
|
|
|
|
}
|
2012-05-21 15:48:54 +00:00
|
|
|
|
|
|
|
|
|
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;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
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;
|
2013-06-23 06:43:23 +00:00
|
|
|
|
2013-07-07 06:29:37 +00:00
|
|
|
/* Finally, accumulate and check if we parsed enough */
|
|
|
|
|
goto accumulate_data;
|
2011-02-16 16:57:42 +00:00
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
packet->data = data;
|
2013-07-07 06:29:37 +00:00
|
|
|
*remaining = others;
|
2012-05-21 15:48:54 +00:00
|
|
|
|
2013-06-23 06:43:23 +00:00
|
|
|
GST_DEBUG ("result: %p", res);
|
2012-05-21 15:48:54 +00:00
|
|
|
|
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");
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
static void
|
2012-06-26 16:59:32 +00:00
|
|
|
mpegts_packetizer_resync (MpegTSPCR * pcr, GstClockTime time,
|
2012-02-23 17:46:09 +00:00
|
|
|
GstClockTime gstpcrtime, gboolean reset_skew)
|
|
|
|
|
{
|
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;
|
2012-02-23 17:46:09 +00:00
|
|
|
if (reset_skew) {
|
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;
|
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:
|
|
|
|
|
*
|
|
|
|
|
* J = N + n
|
|
|
|
|
*
|
2014-06-04 11:31:21 +00:00
|
|
|
* D : a constant network delay.
|
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
|
|
|
|
|
*
|
|
|
|
|
* We see that the network delay is irrelevant here as we can elliminate D:
|
|
|
|
|
*
|
|
|
|
|
* 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
|
2014-10-29 11:58:37 +00:00
|
|
|
calculate_skew (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
MpegTSPCR * pcr, guint64 pcrtime, GstClockTime time)
|
2012-02-23 17:46:09 +00:00
|
|
|
{
|
|
|
|
|
guint64 send_diff, recv_diff;
|
|
|
|
|
gint64 delta;
|
|
|
|
|
gint64 old;
|
|
|
|
|
gint pos, i;
|
|
|
|
|
GstClockTime gstpcrtime, out_time;
|
2013-06-05 13:51:58 +00:00
|
|
|
#ifndef GST_DISABLE_GST_DEBUG
|
2012-02-23 17:46:09 +00:00
|
|
|
guint64 slope;
|
2013-06-05 13:51:58 +00:00
|
|
|
#endif
|
2012-02-23 17:46:09 +00:00
|
|
|
|
2012-07-19 11:35:51 +00:00
|
|
|
gstpcrtime = PCRTIME_TO_GSTTIME (pcrtime) + pcr->pcroffset;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
/* first time, lock on to time and gstpcrtime */
|
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;
|
2012-02-23 17:46:09 +00:00
|
|
|
GST_DEBUG ("Taking new base time %" GST_TIME_FORMAT, GST_TIME_ARGS (time));
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2012-02-23 17:46:09 +00:00
|
|
|
GST_DEBUG ("Taking new base pcrtime %" GST_TIME_FORMAT,
|
|
|
|
|
GST_TIME_ARGS (gstpcrtime));
|
|
|
|
|
}
|
|
|
|
|
|
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) {
|
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 */
|
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 {
|
2014-10-29 11:58:37 +00:00
|
|
|
/* Small jumps backward, assume some arrival jitter and skip it */
|
2012-07-19 11:35:51 +00:00
|
|
|
send_diff = 0;
|
2014-10-29 11:58:37 +00:00
|
|
|
|
|
|
|
|
if (pcr->last_pcrtime - gstpcrtime < GST_SECOND) {
|
|
|
|
|
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;
|
|
|
|
|
}
|
2012-07-19 11:35:51 +00:00
|
|
|
}
|
|
|
|
|
} else
|
2012-06-26 16:59:32 +00:00
|
|
|
send_diff = gstpcrtime - pcr->base_pcrtime;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
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,
|
2012-02-24 16:47:38 +00:00
|
|
|
GST_TIME_ARGS (gstpcrtime), GST_TIME_ARGS (time),
|
2012-06-26 16:59:32 +00:00
|
|
|
GST_TIME_ARGS (pcr->base_pcrtime), GST_TIME_ARGS (send_diff));
|
2012-02-23 17:46:09 +00:00
|
|
|
|
2012-05-20 11:27:29 +00:00
|
|
|
/* keep track of the last extended pcrtime */
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->last_pcrtime = gstpcrtime;
|
2012-05-20 11:27:29 +00:00
|
|
|
|
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)
|
2012-06-26 16:59:32 +00:00
|
|
|
|| !GST_CLOCK_TIME_IS_VALID (pcr->base_time))
|
2012-02-23 17:46:09 +00:00
|
|
|
goto no_skew;
|
|
|
|
|
|
|
|
|
|
/* elapsed time at receiver, includes the jitter */
|
2012-06-26 16:59:32 +00:00
|
|
|
recv_diff = time - pcr->base_time;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
2012-03-01 16:53:41 +00:00
|
|
|
/* Ignore packets received at 100% the same time (i.e. from the same input buffer) */
|
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)))
|
2012-03-01 16:53:41 +00:00
|
|
|
goto no_skew;
|
|
|
|
|
|
2012-02-23 17:46:09 +00:00
|
|
|
/* measure the diff */
|
|
|
|
|
delta = ((gint64) recv_diff) - ((gint64) send_diff);
|
|
|
|
|
|
2013-06-05 13:51:58 +00:00
|
|
|
#ifndef GST_DISABLE_GST_DEBUG
|
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;
|
2013-06-05 13:51:58 +00:00
|
|
|
#endif
|
2012-02-23 17:46:09 +00:00
|
|
|
|
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);
|
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. */
|
2014-10-29 11:58:37 +00:00
|
|
|
if (ABS (delta - pcr->skew) > packetizer->pcr_discont_threshold) {
|
2012-02-23 17:46:09 +00:00
|
|
|
GST_WARNING ("delta - skew: %" GST_TIME_FORMAT " too big, reset skew",
|
2012-06-26 16:59:32 +00:00
|
|
|
GST_TIME_ARGS (delta - pcr->skew));
|
|
|
|
|
mpegts_packetizer_resync (pcr, time, gstpcrtime, TRUE);
|
2012-02-23 17:46:09 +00:00
|
|
|
send_diff = 0;
|
|
|
|
|
delta = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
pos = pcr->window_pos;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
if (G_UNLIKELY (pcr->window_filling)) {
|
2012-02-23 17:46:09 +00:00
|
|
|
/* we are filling the window */
|
|
|
|
|
GST_DEBUG ("filling %d, delta %" G_GINT64_FORMAT, pos, delta);
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->window[pos++] = delta;
|
2012-02-23 17:46:09 +00:00
|
|
|
/* calc the min delta we observed */
|
2012-06-26 16:59:32 +00:00
|
|
|
if (G_UNLIKELY (pos == 1 || delta < pcr->window_min))
|
|
|
|
|
pcr->window_min = delta;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
if (G_UNLIKELY (send_diff >= MAX_TIME || pos >= MAX_WINDOW)) {
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->window_size = pos;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
/* window filled */
|
2012-06-26 16:59:32 +00:00
|
|
|
GST_DEBUG ("min %" G_GINT64_FORMAT, pcr->window_min);
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
/* the skew is now the min */
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->skew = pcr->window_min;
|
|
|
|
|
pcr->window_filling = FALSE;
|
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. */
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->skew =
|
|
|
|
|
(perc * pcr->window_min + ((10000 - perc) * pcr->skew)) / 10000;
|
|
|
|
|
pcr->window_size = pos + 1;
|
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 */
|
2012-06-26 16:59:32 +00:00
|
|
|
old = pcr->window[pos];
|
|
|
|
|
pcr->window[pos++] = delta;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
if (G_UNLIKELY (delta <= pcr->window_min)) {
|
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 */
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->window_min = delta;
|
|
|
|
|
} else if (G_UNLIKELY (old == pcr->window_min)) {
|
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 */
|
2012-06-26 16:59:32 +00:00
|
|
|
for (i = 0; i < pcr->window_size; i++) {
|
2012-02-23 17:46:09 +00:00
|
|
|
/* we found another value equal to the old min, we can stop searching now */
|
2012-06-26 16:59:32 +00:00
|
|
|
if (pcr->window[i] == old) {
|
2012-02-23 17:46:09 +00:00
|
|
|
min = old;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-06-26 16:59:32 +00:00
|
|
|
if (pcr->window[i] < min)
|
|
|
|
|
min = pcr->window[i];
|
2012-02-23 17:46:09 +00:00
|
|
|
}
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->window_min = min;
|
2012-02-23 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
/* average the min values */
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->skew = (pcr->window_min + (124 * pcr->skew)) / 125;
|
2013-06-23 06:43:23 +00:00
|
|
|
GST_DEBUG ("delta %" G_GINT64_FORMAT ", new min: %" G_GINT64_FORMAT,
|
|
|
|
|
delta, pcr->window_min);
|
2012-02-23 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
/* wrap around in the window */
|
2012-06-26 16:59:32 +00:00
|
|
|
if (G_UNLIKELY (pos >= pcr->window_size))
|
2012-02-23 17:46:09 +00:00
|
|
|
pos = 0;
|
|
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->window_pos = pos;
|
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 .*/
|
2012-06-26 16:59:32 +00:00
|
|
|
if (pcr->base_time != -1) {
|
|
|
|
|
out_time = pcr->base_time + send_diff;
|
2012-02-23 17:46:09 +00:00
|
|
|
/* skew can be negative and we don't want to make invalid timestamps */
|
2012-06-26 16:59:32 +00:00
|
|
|
if (pcr->skew < 0 && out_time < -pcr->skew) {
|
2012-02-23 17:46:09 +00:00
|
|
|
out_time = 0;
|
|
|
|
|
} else {
|
2012-06-26 16:59:32 +00:00
|
|
|
out_time += pcr->skew;
|
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 */
|
2012-06-26 16:59:32 +00:00
|
|
|
if (G_LIKELY (pcr->prev_out_time != -1 && pcr->prev_send_diff != -1)) {
|
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 */
|
2012-06-26 16:59:32 +00:00
|
|
|
(send_diff > pcr->prev_send_diff
|
|
|
|
|
&& out_time < pcr->prev_out_time) ||
|
2012-02-23 17:46:09 +00:00
|
|
|
/* if the server timestamps went backwards and the out_time forwards */
|
2012-06-26 16:59:32 +00:00
|
|
|
(send_diff < pcr->prev_send_diff
|
|
|
|
|
&& out_time > pcr->prev_out_time) ||
|
2012-02-23 17:46:09 +00:00
|
|
|
/* if the server timestamps did not change */
|
2012-06-26 16:59:32 +00:00
|
|
|
send_diff == pcr->prev_send_diff)) {
|
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 */
|
2012-02-24 16:47:38 +00:00
|
|
|
out_time = time;
|
2012-02-23 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
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;
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
GST_DEBUG ("skew %" G_GINT64_FORMAT ", out %" GST_TIME_FORMAT,
|
2012-06-26 16:59:32 +00:00
|
|
|
pcr->skew, GST_TIME_ARGS (out_time));
|
2012-02-23 17:46:09 +00:00
|
|
|
|
|
|
|
|
return out_time;
|
|
|
|
|
}
|
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)
|
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;
|
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 */
|
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...
|
|
|
|
|
*
|
|
|
|
|
* We will use the corrected/asolute PCR values to calculate
|
|
|
|
|
* 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);
|
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,
|
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);
|
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,
|
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;
|
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;
|
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)
|
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 *group = g_slice_new0 (PCROffsetGroup);
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
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)
|
|
|
|
|
{
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
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)));
|
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;
|
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;
|
|
|
|
|
|
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.
|
|
|
|
|
*
|
|
|
|
|
* 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)));
|
2014-08-05 09:45:55 +00:00
|
|
|
GST_DEBUG ("Last PCR: +%" GST_TIME_FORMAT " offset: +%" G_GUINT64_FORMAT,
|
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);
|
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)),
|
2014-06-10 12:27:53 +00:00
|
|
|
current->pending[current->last].offset);
|
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 */
|
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);
|
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;
|
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 */
|
2012-03-01 16:56:34 +00:00
|
|
|
GstClockTime
|
2013-06-23 06:43:23 +00:00
|
|
|
mpegts_packetizer_offset_to_ts (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
guint64 offset, guint16 pid)
|
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;
|
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;
|
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);
|
2012-03-01 16:56:34 +00:00
|
|
|
|
|
|
|
|
if (G_UNLIKELY (!packetizer->calculate_offset))
|
|
|
|
|
return GST_CLOCK_TIME_NONE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
if (G_UNLIKELY (packetizer->refoffset == -1))
|
2012-03-01 16:56:34 +00:00
|
|
|
return GST_CLOCK_TIME_NONE;
|
|
|
|
|
|
2013-07-05 15:11:46 +00:00
|
|
|
if (G_UNLIKELY (offset < packetizer->refoffset))
|
2012-03-01 16:56:34 +00:00
|
|
|
return GST_CLOCK_TIME_NONE;
|
|
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_LOCK (packetizer);
|
|
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
pcrtable = get_pcr_table (packetizer, pid);
|
|
|
|
|
|
2014-06-10 12:27:01 +00:00
|
|
|
if (g_list_length (pcrtable->groups) < 1) {
|
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");
|
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
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
2014-06-10 12:27:01 +00:00
|
|
|
if (G_UNLIKELY (last->flags & PCR_GROUP_FLAG_ESTIMATED))
|
|
|
|
|
_reevaluate_group_pcr_offset (pcrtable, last);
|
2013-04-15 23:01:29 +00:00
|
|
|
|
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;
|
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;
|
|
|
|
|
}
|
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) */
|
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));
|
2014-07-03 11:39:19 +00:00
|
|
|
|
|
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
|
|
|
|
|
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) */
|
2012-03-01 16:56:34 +00:00
|
|
|
GstClockTime
|
2013-06-23 06:43:23 +00:00
|
|
|
mpegts_packetizer_pts_to_ts (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
GstClockTime pts, guint16 pcr_pid)
|
2012-03-01 16:56:34 +00:00
|
|
|
{
|
2012-03-05 11:46:13 +00:00
|
|
|
GstClockTime res = GST_CLOCK_TIME_NONE;
|
2014-07-03 11:39:19 +00:00
|
|
|
MpegTSPCR *pcrtable;
|
|
|
|
|
|
|
|
|
|
PACKETIZER_GROUP_LOCK (packetizer);
|
|
|
|
|
pcrtable = get_pcr_table (packetizer, pcr_pid);
|
2012-03-05 11:46:13 +00:00
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-01 16:56:34 +00:00
|
|
|
/* Use clock skew if present */
|
|
|
|
|
if (packetizer->calculate_skew
|
2012-06-26 16:59:32 +00:00
|
|
|
&& GST_CLOCK_TIME_IS_VALID (pcrtable->base_time)) {
|
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));
|
|
|
|
|
res = pts + pcrtable->pcroffset;
|
|
|
|
|
|
|
|
|
|
/* Don't return anything if we differ too much against last seen PCR */
|
|
|
|
|
/* FIXME : Ideally we want to figure out whether we have a wraparound or
|
|
|
|
|
* a reset so we can provide actual values.
|
|
|
|
|
* That being said, this will only happen for the small interval of time
|
|
|
|
|
* where PTS/DTS are wrapping just before we see the first reset/wrap PCR
|
|
|
|
|
*/
|
2016-05-31 11:09:43 +00:00
|
|
|
if (G_UNLIKELY (pcr_pid != 0x1fff &&
|
|
|
|
|
ABSDIFF (res, pcrtable->last_pcrtime) > 15 * GST_SECOND))
|
2014-06-13 09:46:19 +00:00
|
|
|
res = GST_CLOCK_TIME_NONE;
|
2014-07-29 05:11:54 +00:00
|
|
|
else {
|
|
|
|
|
GstClockTime tmp = pcrtable->base_time + pcrtable->skew;
|
|
|
|
|
if (tmp + res > pcrtable->base_pcrtime)
|
|
|
|
|
res += tmp - pcrtable->base_pcrtime;
|
|
|
|
|
else
|
|
|
|
|
res = 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
|
|
|
} 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;
|
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
|
|
|
|
|
*/
|
2014-06-13 08:37:46 +00:00
|
|
|
if (PCRTIME_TO_GSTTIME (refpcr) - pts > GST_SECOND) {
|
|
|
|
|
pts += PCR_GST_MAX_VALUE;
|
|
|
|
|
} else
|
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;
|
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)
|
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");
|
2012-11-08 16:15:26 +00:00
|
|
|
} else
|
|
|
|
|
GST_WARNING ("Not enough information to calculate proper timestamp");
|
2012-03-01 16:56:34 +00:00
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
|
|
|
|
|
2012-03-05 11:46:13 +00:00
|
|
|
GST_DEBUG ("Returning timestamp %" GST_TIME_FORMAT " for pts %"
|
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);
|
2012-03-05 11:46:13 +00:00
|
|
|
return res;
|
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
|
|
|
/* Stream time to offset */
|
2012-03-01 16:56:34 +00:00
|
|
|
guint64
|
2013-06-23 06:43:23 +00:00
|
|
|
mpegts_packetizer_ts_to_offset (MpegTSPacketizer2 * packetizer,
|
|
|
|
|
GstClockTime ts, guint16 pcr_pid)
|
2012-03-01 16:56:34 +00:00
|
|
|
{
|
2012-06-26 16:59:32 +00:00
|
|
|
MpegTSPCR *pcrtable;
|
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;
|
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;
|
2012-03-01 16:56:34 +00:00
|
|
|
|
2012-06-26 16:59:32 +00:00
|
|
|
if (!packetizer->calculate_offset)
|
|
|
|
|
return -1;
|
|
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_LOCK (packetizer);
|
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
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
if (pcrtable->groups == NULL) {
|
|
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
2012-03-01 16:56:34 +00:00
|
|
|
return -1;
|
2014-07-03 11:39:19 +00:00
|
|
|
}
|
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));
|
|
|
|
|
|
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;
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
|
2014-04-18 14:23:43 +00:00
|
|
|
res = firstoffset;
|
|
|
|
|
if (lastpcr != firstpcr)
|
|
|
|
|
res += gst_util_uint64_scale (querypcr - firstpcr,
|
|
|
|
|
lastoffset - firstoffset, lastpcr - firstpcr);
|
2012-03-01 16:56:34 +00:00
|
|
|
|
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));
|
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);
|
|
|
|
|
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_LOCK (packetizer);
|
2013-07-05 15:11:46 +00:00
|
|
|
packetizer->refoffset = refoffset;
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
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
|
|
|
|
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 */
|
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);
|
|
|
|
|
|
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;
|
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);
|
|
|
|
|
|
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;
|
2014-06-11 07:38:00 +00:00
|
|
|
if (delta == 0) {
|
|
|
|
|
GST_DEBUG ("No shift to apply");
|
2014-07-03 11:39:19 +00:00
|
|
|
PACKETIZER_GROUP_UNLOCK (packetizer);
|
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) {
|
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,
|
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,
|
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
|
|
|
}
|
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
|
|
|
}
|
