liveadder sometimes calculates the offsets incorrectly before adding. The
resulting errors can easily be heard when mixing silence with a sine.
I'm not sure what the exact conditions are to trigger this, but it definitively
happens when the buffers of two streams have a different duration and buffer
length and duration don't match exactly for one stream because of rounding
errors (e.g. duration=0:00:00.021333333)
I have to admit, I got lost in the math somewhere but it seems that not
rounding in gst_live_adder_length_from_duration() causes 1 sample overlaps in
consecutive buffers from the same stream.
When using gst_util_uint64_scale_int_round() instead of just truncating the
sine sound correctly again.
https://bugzilla.gnome.org/show_bug.cgi?id=708345
It is quite possible that we might get PTS/DTS before the first
PCR/Offset observation.
In order to end up with valid timestamp we wait until at least one
stream was able to get a proper running-time for any PTS/DTS.
Until then, we queue up the pending buffers to push out.
Once we see a first valid timestamp, we re-evaluate the amount of
running-time elapsed (based on returned inital running-time and amount
of data/DTS queued up) for any given stream.
Taking the biggest amount of elapsed time, we set that on the packetizer
as the initial offset and recalculate all pending buffers running-time
PTS/DTS.
Note: The buffer queueing system can also be used later on for the
dvb fast start proposal (where we queue up all stream packets before
seeing PAT/PMT and then push them once we know if they belong to the
chosen program).
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.
The previous code could enter an infinite loop because the adapter state
could get out of sync with its mapped data state after sync was lost.
The code was pretty confusing so it's been rewritten to be clearer.
The easiest way to reproduce the infinite loop is to use the breakmydata
element before tsdemux to trigger a resync.
https://bugzilla.gnome.org/show_bug.cgi?id=708161
When outputting in AVC3 stream format, the codec_data should not
contain any SPS or PPS, because they are embedded inside the stream.
In case of avc->bytestream h264parse will push the SPS and PPS from
codec_data downstream at the start of the stream, at intervals
controlled by "config-interval" and when there is a codec_data change.
In the case of avc3->bytstream h264parse detects that there is
already SPS/PPS in the stream and sets h264parse->push_codec to FALSE.
Therefore avc3->bytstream was already supported, except for the stream
type.
In the case of bystream->avc h264parse will generate codec_data caps
from the parsed SPS/PPS in the stream. However it does not remove these
SPS/PPS from the stream. bytestream->avc3 is the same as bytestream->avc
except that the codec_data must not have any SPS/PPS in it.
|--------------+-------------+-------------------|
|stream-format | SPS in-band | SPS in codec_data |
|--------------+-------------+-------------------|
| avc | maybe | always |
|--------------+-------------+-------------------|
| avc3 | always | never |
|--------------+-------------+-------------------|
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV box
(moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in the
first sample of every fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
The prog-map property of mpegtsmux only allows you to group pids together in a program.
The program number set in the PAT/PMT tables cannot be set explicitly.
This patch will set the program number according to the prog-map.
If a program id of 0 is given, the first vacant program number starting from 1 will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=697239
Some streams had wrong values for the stream_id_extension, make sure
we only remember the valid ones.
For streams with PES_extension_field_length == 0, assume there's nothing
else.
For streams that state they have a TREF extension but don't have enough
data to store it, just assume it was produced by a non-compliant muxer
and skip the remaining data.
Only store remaining data in stream_id_extension_data instead of storing
data we already parse.
The Sequence Header Data Structure STRUCT_C for Advanced Profile
has only a one valid field which is the profile indicator. Don't
use the reserved fields for fps update like Simple/Main profile.
https://bugzilla.gnome.org/show_bug.cgi?id=705667
The Sequence Header Data Structure STRUCT_A for advanced profile
may be eight consecutive zero bytes.Don't try to override the
width and height values in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=705667
AIFF chunk size does not include the chunk header size (8 bytes), so the
SSND data size is equal to the chunk size minus the SSND header size (8
bytes).
https://bugzilla.gnome.org/show_bug.cgi?id=705675
Updating caps results in downstream elements potentially reconfiguring themselves
(such as decoders). If we do this in the middle of keyframes, we would result
in those elements being reconfigured and handling garbage until the next keyframe.
Instead of this only send (potentially) new codec_data when we have *both* SPS and
PPS.
https://bugzilla.gnome.org/show_bug.cgi?id=705333
If ever we lose sync, we were just checking for the next 0x47 marker ...
which might actually happen within a mpeg-ts packet.
Instead check for 3 repeating 0x47 at the expected packet size interval,
which the same logic we use when we initially look for the packet size.
We were only resetting the first 512 values of the lookup table instead
of the whole 8192.
This resulted in any PCR PID over 0x0200 ... ending up taking the first PCR
table around :(
ATSC ac3 streams are always guaranteed to be AC3 if EAC3 descriptor
is not present
If stream registration id is 'AC-3' then it's also guaranteed to be AC3.
Finally if AC3 descriptor is present it's guaranteed to be AC3.
Only silences a warning, but still.
We know we will not overflow 64 bits, therefore just use direct
multiplication/division instead of the scale method (trims usage from
50 instruction calls to 2/3).
Helps with debugging issues. And also remove unused variable (opcr)
This will also allow us in the future to properly detect:
* random-access location (to enable keyframe observation and
potentially seeking
* discont location (to properly handle resets)
* splice location (to properly handle new stream changes)
If a buffer was entirely clipped out (ie, it's out of the segment
entirely), we'll end up with a NULL buffer, which we don't want
to process/dereference.
The new seek handling re-creates the segment time information once it
has enough information after a seek.
The problem was that we'd completely ignore the requested rate. So store
that and use it in the newly created segment.
https://bugzilla.gnome.org/show_bug.cgi?id=694369
Make videotestsrc ! interlace ! $anything work again. Problem
was that upstream filter caps were passed which contained
interlace-mode=progressive, which doesn't intersect too well
with interlace's source pad template caps, leading to
not-negotiated errors.
The program_number attribute was overloaded, trying to indicate both
the currently playing program, and the program requested via the
"program-number" property. The end result was that setting the
property didn't work (see #690934).
I added a new requested_program_number field rather than reviving the
current_program_number field because it seemed this would result in
fewer changes overall and be less confusing. It breaks symmetry with
the "program-number" property, but it retains parallels with the likes
of program->program_number.
Because gst_ts_demux_reset is called after the properties have been
parsed, requested_program_number is initialised in gst_ts_demux_init.
Whether this is exactly the right place, I don't know.
Setting the program-number property does not affect which program
is actually being demuxed.
Moving the initialization of the program_number from
gst_ts_demux_reset to gst_ts_demux_init seems to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=690934
* Avoids handling twice the same seek (can happen with playbin and files
with subtitles)
* Set the sequence number of the segment event to the sequence number of
the seek event that generated it (-1 for the initial one).
The seeking start time is approximated from the seek offset in bytes
using the accumulated PCR observations, so on a VBR stream there might
be a big difference between the actual PCR and the estimated one after
the seek. This might result in a long wait to skip all out of segments
packets.
Instead we just recalculate the new segment to start at the first PTS
after the seek, so that playback starts immediatly.
The caps should always represent what the user is supposed to see.
So if there is a sequence_display_extension associated with the
stream then use the display_horizontal_size/display_vertical_size
to update the src caps (if they are less than the values provided
by sequence header).
https://bugzilla.gnome.org/show_bug.cgi?id=704009
This is actually a workaround (we'll be skipping the upcoming section)
This will only happen for sections where the beginning is located within
the last 8 bytes of a packet (which is the minimum we need to properly
identify any section beginning).
Later we should figure out a way to store those bytes and mark that
some analysis needs to happen. The probability of this happening is
too low for me to care right now and do that fix. There is a good chance
that section will eventually be repeated and won't end up on such border.
* packet.origts is no longer used since the PCR refactoring done ages ago
* known_packet_size is a duplicate of packet_size != 0
* caps was never used outside of the packetizer
Restore the original h264parser behaviour to report cropped dimensions
in size caps.
https://bugzilla.gnome.org/show_bug.cgi?id=694068
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
We had two issues with the previous code:
1) We were badly handling PUSI-flagged packets. We were discarding the
initial data (if pointer != 0) whereas we should have been accumulating
it with the previous data (if there was a continuity of course).
=> First series of information loss
2) We were not checking whether there were more sections after the end
of one (i.e. when the following byte was not a stuff byte).
This fixes those two issues.
Fixes#677443https://bugzilla.gnome.org/show_bug.cgi?id=677443
Until now we simply ignored those streams (since we couldn't do anything
with it anyway). Now that we have the mpegts library and we offload the
section handling to the application side we can properly identify and
extract them.
By default it is disabled for tsparse and enabled for tsdemux, but there is
a property to change that.
This should open the way to properly handle all private section streams,
including:
* DSM-CC
* MHEG
* Carousel data
* Metadata streams (though I haven't seen any of those in the wild)
* ... And all other specs/protocols making use of those
Partially fixes#560631
Migrate the code to use the new parser API based on GstMpegVideoPacket.
Also try to optimize gst_mpegv_parse_process_config() by using more of
GstMpegVideoPacket and determining the extension_start_code_identifier
prior to calling the parser function for that extension packet.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Since we now send all sections to the packetizer, we no longer need to do
anymore in-depth checks for the validity of a section.
The choice boils down to:
1) Is it from a known PES pid ? If so pass it on (which might be just pushing
downstream in the case of tsparse, or accumulating PES data for tsdemux)
2) Is it from a known SI pid ? If so pass it to the section packetizer
We still have some other stream types which haven't been ported, but
we will do so once we have defined the enums in the mpegts library.
Also add some FIXMEs regarding items discovered during analysis
* Only mpeg-ts section packetization remains.
* Improve code to detect duplicated sections as early as possible
* Add FIXME for various issues that need fixing (but are not regressions)
https://bugzilla.gnome.org/show_bug.cgi?id=702724
We use add_stream(stream_type:-1) to ensure a programs' PCR Stream is
also taken into account. For most programs this will re-use an
existing ES stream.
So only warn that we are re-adding a stream if it was already present
AND it is not to ensure the PCR stream is taken into account.
Only create subtables when needed. It was previously creating one every
single time ... to check if one was present.
And speed up code to detect whether a subtable was already present or not.
Overall makes section pushing 2 times faster.
In some cases (NIT on highly-populated DVB-C operator for example), there
will be more than one section emitted for the same subtable and version
number.
In order not to lose those updates for the same version number, we checked
against the CRC of the previous section we parsed.
The problem is that, while it made sure we didn't lose any information, it
also meant that if the same section came back (same version, same CRC) later
on we would re-process it, re-parse it and re-emit it.
This version improves on that by keeping a list of previously observed CRC
for identical PID/subtable/version-number and will only process sections if
they really were never seen in the past (as opposed to just before).
On a 30s clip, this brings down the number of NIT section parsing from 4541
down to 663.
https://bugzilla.gnome.org/show_bug.cgi?id=614479
First send stream-start, then caps, then segment.
The segment we push is from upstream in push-mode. If we work in pull-mode
then we initialize the base segment to BYTES.
https://bugzilla.gnome.org/show_bug.cgi?id=702422
Sync byte scan is incorrect for M2TS streams because the timestamp 4
bytes were not included in the flush size. This can result in an
infinite loop.
Rework the scan code to be clearer and work in all cases.
By adding the video-source-filter during construction time, rather then
patching it in later (*), we can greatly reduce the amount of caps involved
in negotation, speeding up pipeline creation.
I wrote this while working on speeding up the startup of cheese. My cheese
has been modified to add a capsfilter, filtering for only the configured
resolution, with that cheese patch + this patch, the pipeline creation time
goes from aprox 1.1 seconds to aprox 350ms. This is with a Logitech 9000
pro camera, which supports lots of different resolutions at many different
framerates per resolution, causing a caps "explosion" if not filtered.
*) Note the code for this is left in, as it is still necessary if the
video-source-filter is changed between a stop + re-start.
https://bugzilla.gnome.org/show_bug.cgi?id=701953
check_and_replace_src() was setting self->app_vid_src to NULL, which
means that an app setting the video-source property, and then starting,
stopping and re-starting the pipeline (ie to make changes to the
video-source-filter property) would after the restart no longer have
a video-source.
This patch fixes this by making gst_camerabin_setup_default_element return a
ref to the passed in user_element, rather then returning the user_element as
is, so that that ref can be passed on to the bin, and the app_vid_src ref
stays valid.
https://bugzilla.gnome.org/show_bug.cgi?id=701915
Current fallback to lost_sync seems to impede a delay to restore
sync. Let the parser parse and skip the private stream.
Here it contains the digital camera brand (in 2010 bytes)
and is repeated twice.
https://bugzilla.gnome.org/show_bug.cgi?id=697283
descriptors are stored as a GValueArray of GString. The downside is
that there is no way to "pass" ownership of a GValue to a GValueArray
which previously resulted in expensive copy/free of the (already expensive)
GString.
Here we estimate first the size of the GValueArray, then create it,
then directly use the GValue of that array.
Speeds up total SI parsing by ~30%
