summaryrefslogtreecommitdiff
path: root/gst/mpegtsdemux
Commit message (Collapse)AuthorAgeFilesLines
* tsdemux: fix latency handling againTim-Philipp Müller2015-08-241-2/+1
| | | | | | | | | | | | The tsdemux latency should always be added to the minimum latency (which is always a valid clock time value). The "cleanup" in commit a1f709c2 made it so that it would not be added if upstream reported 0 as minimum latency (as e.g. udpsrc would). This broke playback of live mpeg-ts streaming in some cases, leading to playback stutter due to a too-small configured latency for the pipeline. https://bugzilla.gnome.org/show_bug.cgi?id=751508
* mpegtsdemux: Fix illogical comparisionEdward Hervey2015-08-161-1/+1
| | | | | | | A variable can't be two values at once. We want to stop if it's not the actual ts *AND* not the other ts CID #1316475
* mpegtsbase: remove redundant checkLuis de Bethencourt2015-07-291-3/+1
| | | | | No need to check if done is True since break will already terminate the for loop.
* mpegtsbase: Fix previous commitEdward Hervey2015-07-091-1/+8
| | | | | | We only want to do a hard reset of the observations if we're working with TIME segments in push mode. For BYTE segment we want to keep the observations (in order to do seeks in push-mode).
* mpegtsbase: Flush more on DISCONT buffers in push modeEdward Hervey2015-07-091-1/+1
| | | | | | | | | | | When in push mode, we want to discard all previous observations from the mpegtspacketizer when we get a DISCONT buffer. This avoids trying to calculate bogus timestamps (estimating them using old PCR observations). We only do a hard reset in push-mode. In pull-mode we still need the observations (in order to seek properly)
* tsdemux: remove unnecessary checkTim-Philipp Müller2015-07-081-1/+1
| | | | | | This is not public API, use g_assert() instead of g_return_if_fail(), so that it's compiled out in releases. It's only called from our code, with &foo.
* tsdemux: add support for KLV metadata streamsTim-Philipp Müller2015-07-082-1/+8
| | | | | | There's no timestamps for these streams though, we might want to make some up based on the last/next video PTS or so.
* tsdemux: Segment start should match first PTSNicolas Dufresne2015-06-121-27/+27
| | | | | | | | The segment should start at first PTS, and the vairable name lower_pts state so correctly. Though we where using the first DTS instead. This could lead to small desynchronization of video stream. https://bugzilla.gnome.org/show_bug.cgi?id=740575
* tsdemux: correct fix for dead codeLuis de Bethencourt2015-06-081-1/+1
| | | | | | | Rename template to caps to keep the original intention of the code after commit b4c9aa1c CID #1304674
* Revert "tsdemux: remove dead code"Luis de Bethencourt2015-06-081-0/+2
| | | | This reverts commit 0635acfec041b1c664bc0770839b1a576e3598b1.
* tsdemux: remove dead codeLuis de Bethencourt2015-06-081-2/+0
| | | | | | | After commit b4c9aa1c308f88bf4e1f69ab0156ed9f99815e8e template will always be NULL. The if conditional will always be FALSE, so removing it. CID #1304674
* tsdemux: remove ignored assignmentLuis de Bethencourt2015-06-051-1/+0
| | | | Function goes to done before the value set in start_offset is ever used.
* tsdemux: refactor pad creationThiago Santos2015-06-041-63/+53
| | | | Avoid repeating the same pad creation code everywhere
* mpegtsbase: do not access variable after unrefThiago Santos2015-06-021-1/+2
| | | | Data might not exist anymore
* tsdemux: enable Chinese AVS video streamAurélien Zanelli2015-06-021-0/+8
| | | | | | | | | Chinese broadcaster encapsulate AVS video codec into MPEG2-TS. They use the stream_id 0x42 to identify AVS video streams. It should be noted that this id is currently within the ISO reserved range, hence it's utilisation is unofficial. https://bugzilla.gnome.org/show_bug.cgi?id=727731
* tsdemux: fix buffer timestamp not being in stream timeVincent Penquerc'h2015-05-151-2/+2
| | | | | | | | Timestamps should start at the segment start, rather than 0, so we need to not subtract the first timestamp. This makes the sink correctly account for running time when switching PMTs where a stream starts not quite at zero, causing timing offsets that can become noticeable and causing dropped frames after a few times.
* tsdemux: accumulate previous segment base timeVincent Penquerc'h2015-05-151-1/+2
|
* tsdemux: fix refcounting when applying a new PMTVincent Penquerc'h2015-05-151-0/+1
| | | | | | | | | | | | A new program object is created to replace an existing one in the programs hash table, so its refcount needs to match. With the default of 0 refcount on creation, the next PAT change will cause that refcount to be both incremented and decremented (assuming the new PAT references that stream too), which will cause the program to be destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=748412
* tsdemux: fix taglist leakGuillaume Desmottes2015-04-281-0/+5
| | | | | | | | | | If the stream which is about to be removed still has a ref on a tag list we should drop it. Fix a leak which was occasionally happening with the validate.file.playback.change_state_intensive.tron_en_ge_aac_h264_ts scenario. https://bugzilla.gnome.org/show_bug.cgi?id=748576
* mpegtspacketizer: fix find_subtable() return valueJimmy Ohn2015-04-281-1/+1
| | | | | | | find_subtable() returns a pointer, so return NULL and not FALSE when nothing is found. https://bugzilla.gnome.org/show_bug.cgi?id=748527
* Rename property enums from ARG_ to PROP_Luis de Bethencourt2015-04-271-1/+1
| | | | Property enum items should be named PROP_ for consistency and readability.
* Remove obsolete Android build cruftTim-Philipp Müller2015-04-261-14/+0
| | | | This is not needed any longer.
* tsdemux: clean assignment typoLuis de Bethencourt2015-04-201-1/+1
| | | | | | | | No need to set the value twice. https://bugzilla.gnome.org/show_bug.cgi?id=745102 CID #295122
* tsdemux: remove dead codeLuis de Bethencourt2015-04-201-2/+0
| | | | | | position of GstSegment is an unsigned int64, it can never be below zero. CID #1295123
* mpegtsbase: Remove unused latency query codeOlivier Crête2015-04-171-26/+0
| | | | | The behavior changes based on the type of segment, not on the liveness of the source.
* tsdemux: Cleanup latency query handlingOlivier Crête2015-04-171-5/+8
| | | | | The minimum latency is always 0 or more. And we should requery upstream as it may have changed.
* mpegtspacketizer: Unify debug statementsEdward Hervey2015-04-171-5/+6
| | | | Use 0x%04x for PIDs
* tsdemux: Unify duration querying codeEdward Hervey2015-04-171-16/+31
| | | | | | And properly use it in the SEEKING query. Fixes seeking with gst-play
* tsdemux: fix segment position tracking for the general caseVincent Penquerc'h2015-04-161-1/+5
| | | | | | | Different streams can have different PTS/DTS bases, and some streams may not even have DTS. https://bugzilla.gnome.org/show_bug.cgi?id=745102
* tsdemux: handle seeks with no target (ie, keep current position)Vincent Penquerc'h2015-04-092-14/+33
| | | | | | | | | Such seeks are used to change playback rate and we do not want to alter the position in that case, so we bypass the flush/seek logic, and set things up so a new segment is scheduled to be regenerated. https://bugzilla.gnome.org/show_bug.cgi?id=735100
* tsparse: fix timestamps not updating after a PMT changeVincent Penquerc'h2015-04-092-3/+18
| | | | | | | The PCRs stay locked onto the same PID as before the change, but the relevant PID has no reason to be the same after it. https://bugzilla.gnome.org/show_bug.cgi?id=745102
* tsdemux: send new segment when a stream is addedVincent Penquerc'h2015-04-091-1/+2
| | | | | | | | This will happen when the PMT changes, replacing streams with new ones. In that case, we need to accumulate the running time from the previous chain in the segment base. https://bugzilla.gnome.org/show_bug.cgi?id=745102
* tsdemux: keep track of current positionVincent Penquerc'h2015-04-091-0/+5
| | | | | | This allows seeking to correctly set the base on the segment. https://bugzilla.gnome.org/show_bug.cgi?id=745102
* tsdemux: Fix segment and segment event handling during seekingThiago Santos2015-02-132-10/+9
| | | | | | | | | | Always update the segment and not only for accurate seeking and always send a new segment event after seeks. For non-accurate force a reset of our segment info to start from where our seek led us as we don't need to be accurate https://bugzilla.gnome.org/show_bug.cgi?id=743363
* tsdemux: remove update segment logicThiago Santos2015-02-032-51/+7
| | | | This is not needed in 1.x series anymore
* tsdemux: don't mark streams as needing a new segment on flushAurélien Zanelli2015-02-031-10/+14
| | | | | | | | | The flush is called on discont and we shouldn't output a new segment each time a discont happens. So this commit remove the mark for a new segment when flushing streams by propagating the 'hard' flag passed on the flusing from the base class. https://bugzilla.gnome.org/show_bug.cgi?id=743363
* mpegtsbase: scan more bytes to find initial PCRsSudip Jain2014-12-131-1/+1
| | | | | | Fixes playback of Samsung-Colorful-Variety-1080i.ts. https://bugzilla.gnome.org/show_bug.cgi?id=729768
* mpegtbase: Improve last PCR detectionEdward Hervey2014-12-011-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | When dealing with random-access content (such as files), we initially search for the last PCR in order to figure out duration and to handle other position estimation such as those used in seeking. Previously, the code looking for that last PCR would search in the last 640kB of the file going forward, and stop at the first PCR encountered. The problem with that was two-fold: * It wouldn't really be the last PCR (it would be the first one within those last 640kB. In case of VBR files, this would put off duration and seek code slightly. * It would fail on files with bitrates higher than 52Mbit/s (not common) Instead this patch modifies that code by: * Scanning over the last 2048kB (allows to cope with streams up to 160Mbit/s) * Starts by the end of the file, going over chunks of 300 MPEG-TS packets * Doesn't stop at the first PCR detected in a chunk, but instead records all of them, and only stop searching if there was "at least" one PCR within that chunk This should improve duration reporting and seeking operations on VBR files https://bugzilla.gnome.org/show_bug.cgi?id=708532
* tsdemux: Only activate warning for real streamsEdward Hervey2014-12-011-2/+2
| | | | | streams with stream_type 0xff are PCR-only streams, it's normal not to have a pad for them.
* mpegtspacketizer: Fix format string compiler warningRamprakash Jelari2014-11-241-1/+1
|
* mpegtsbase: do not remove programs on EOSMatthieu Bouron2014-10-301-13/+0
| | | | | | | | | | | As a consequence, tsdemux won't remove its pads anymore on EOS. Fixes the case when mpegtsbase is not able to process new packets after EOS as the corresponding pids aren't known anymore because the programs were removed and the pes/psi were kept, preventing the PAT to be parsed again. https://bugzilla.gnome.org/show_bug.cgi?id=738695
* tsparse: Handle backward and discont timestamps better.Jan Schmidt2014-10-293-19/+49
| | | | | | | | | | Assume that small backward PCR jumps are just from upstream packet mis-ordering and don't reset timestamp tracking state - assuming that things will be OK again shortly. Make the threshold for detecting discont between sequential buffers configurable and match the smoothing-latency setting on tsparse to better cope with data bursts.
* tsparse: Implement timestamp/retimestamping of output buffersJan Schmidt2014-10-294-63/+353
| | | | | | | | | | | | When the set-timestamps property is set, use PCRs on the provided (or autodetected) pcr-pid to apply (or replace) timestamps on the output buffers, using piece-wise linear interpolation. This allows tsparse to be used to stream an arbitrary mpeg-ts file, or to smooth jittery reception timestamps from a network stream. The reported latency is increased to match the smoothing latency if necessary.
* tsdemux: send initial GAP event on sparse streams for faster startup with ↵Tim-Philipp Müller2014-10-201-0/+19
| | | | | | | | | | | | | | playbin Signal sparse streams properly in stream-start event and force sending of pending sticky events which have been stored on the pad already and which otherwise would only be sent on the first buffer or serialized event (which means very late in case of subtitle streams). Playsink in playbin waits for stream-start or another serialized event, and if we don't do this it will wait for the multiqueue to run full before starting playback, which might take a couple of seconds. https://bugzilla.gnome.org/show_bug.cgi?id=734040
* tsdemux: GAP detectionEdward Hervey2014-10-203-41/+151
| | | | | | | | | | All pads of a stream are now added at the beginning. In order to cope with streams that don't get any data (forever or for a long time) we detect gaps and push out GAP events when needed. Cleanups and commenting by Jan Schmidt <jan@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=734040
* tsdemux: do not discard on discont if PES startJesper Larsen2014-09-291-1/+2
| | | | | | | | If a discontinuity in the stream is detected, data is discarded until a new PES starts. If the first packet after the discontinuity is also the start of a PES, there is no reason to discard the packets. https://bugzilla.gnome.org/show_bug.cgi?id=737569
* tsdemux: fix trivial coding style issueAurélien Zanelli2014-09-121-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=736531
* tsdemux: fix overflow of packet_length field of PESHeaderAurélien Zanelli2014-09-121-1/+1
| | | | | | | | | | | packet_length is defined as a guint16 in the PESHeader structure. This definition match the specification. But since we add 6 bytes to the packet_length value (length of start_code + stream_id + packet_length), we can overflow the guint16 when the value in the PES header is greater than 65529. So use a guint32 instead of a guint16 to avoid overflow. https://bugzilla.gnome.org/show_bug.cgi?id=736490
* tsdemux: clear mutex resources in disposeJesper Larsen2014-09-101-0/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=736390
* tsdemux: remove pads when resetting the elementThiago Santos2014-08-191-9/+13
| | | | | | | Otherwise the pads will be there if it is restarted and the stream can be a completely different one. https://bugzilla.gnome.org/show_bug.cgi?id=734394
View Lorry Controller Status