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.
* Avoid repeating code everywhere, and instead provide all parsing
information in one go.
* Add BAT support
* Refine BAT/CAT identification (by adding PID checks)
* 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>
Fix calculation of the frame cropping rectangle, and more precisely
the actual cropped height. The frame_crop_top_offset subtraction
was not scaled up with SubHeightC.
Also clean-up variables to align more with (7-18) to (7-21).
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Assign the un-cropped width/height to sps->width/sps->height
during sps header parsing. Added new fields to SPS header structure
to provide the crop-rectangle dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=694068
During a live stream it is possible for dashdemux to lag behind on a
slow connection or to rush ahead of the connection os too fast.
For the first case it is necessary to jump some segments ahead to be able to
continue playback as old segments are usually deleted from the server.
For the later, dashdemux should wait a little before attempting another
download do give time to the server to produce a new segment
When using a template based segment list, do not try to
contruct a finite segment list for the limits of the available periods.
We might not know when the period ends (for live streams) and we can
always create the segment on demand when requested by dashdemux,
avoiding use of some memory and cpu when re-creating this list.
Replaces the 2 likely larger lists with more appropriate structures
to improve performance.
Replaces S nodes GList for a GQueue, this reduces latency to startup
because of traversing the list just append an element.
Replaces the processed media segments GList for a GPtrArray as it is
constantly acessed by index during playback.
Cancelled is a 'permanent' state of the uridownloader and is only
removed by a call to _reset. When a download fails we just want to
return NULL on the fetch function and leave the downloader ready
for another fetch, otherwise the user has to call _reset after
failed downloader, even when it didn't call _cancel.
Due to the variety of section types out there, we need to add
some checks when identifying section types.
We check here that the PID is also consistent with the table_id.
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
The size checks were wrong. The smallest size for a NIT is 16 bytes
(12 for the smallest content + 4 for crc) and the smallest size for
a inner stream loop is 6 bytes (without any descriptors).
Also remove FIXME that has already moved elsewhere
Add API to parse the Slice header. This also calculates the macroblock
position as specified in 6.3.16.
https://bugzilla.gnome.org/show_bug.cgi?id=664274
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
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>
Add new interface to MPEG-2 video parser that takes GstMpegVideoPacket
arguments instead of data, size, and offset. New functions are called
after gst_mpeg_video_packet_*() and provide the default implementation.
Older API is moved to the deprecated namespace and uses the new functions.
https://bugzilla.gnome.org/show_bug.cgi?id=692933
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
* Add a base page for the library
* Add pages for the base MPEG-TS section and descriptors
* Add pages for the known variants
* Add documentation on more fields/sections/types
* Remove some fixmes that were ... fixed
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
These are the values officially registered in the base specification
(H.222.0/13818-1). Later on we can add other enums for other variants
Note that the enum is not used in the structure fields (such as a pmt
stream stream_type field) since it can contain values from other
variants.
Duration from segment being unknown is a issue from the MPD and not
a programming issue, so the assert isn't useful here. Instead check
and return an error code so the caller can fallback to alternatives
When dashdemux selects its first fragment, it always selects the
first fragment listed in the manifest. For on-demand content,
this is the correct behaviour. However for live content, this
behaviour is undesirable because the first fragment listed in the
manifest might be some considerable time behind "now".
The commit uses the host's idea of UTC and tries to find the
oldest fragment that contains samples for this time of day.
https://bugzilla.gnome.org/show_bug.cgi?id=701509
