Commit graph

23 commits

Author SHA1 Message Date
Thiago Santos
4b0ce7dc30 qtdemux: use GstFlowCombiner
Removes the common code to combining flow returns to let it be
handled by core gstutils' GstFlowCombiner

https://bugzilla.gnome.org/show_bug.cgi?id=709224
2014-05-26 15:30:12 -03:00
Thiago Santos
52fc078310 qtdemux: remove elst_offset variables
They are not used anymore
2014-01-15 15:33:45 -03:00
Thiago Santos
90a5565229 qtdemux: do not ignore empty segments
Make sure empty segments are used and pushed with a gap event
to represent its data (or lack of it)

Each QtSegment is mapped into a GstSegment with the corresponding
media range. For empty QtSegments a gap event is pushed instead
of GstBuffers and it advances to the next QtSegment.

To make this work with seeks, need to keep track of the starting
'base' to make sure it remains consistently increasing when
pushing new segment events.
For example: if a seek makes qtdemux start from 5s, the first
segment will have a base=0. When the next segment is activated,
its base time will be QtSegment.time - qtdemux.segment_base so
that it doesn't include the first 5s that weren't played and
shouldn't be accounted on the running time

This purposedly will remove the fix made for
https://bugzilla.gnome.org/show_bug.cgi?id=700264, at this
point it was decided to respect the gaps, even if they cause
a delay on playback, because that's the way the file was crafted.

https://bugzilla.gnome.org/show_bug.cgi?id=345830
2014-01-15 15:33:45 -03:00
Thiago Santos
c1cd2f81f9 qtdemux: improve mss_mode/fragmented special handling
Make it clear what should be handled purely by mss mode:
1) Expose the streams on the first moof as there are no moov atoms
2) Properly cleanup streams on flushes

Add a note about the meaning of upstream_newsegment and mss_mode
for future reference.

Make all other special fragment handling shared for both dash
and mss streams.
2013-12-27 12:04:49 -03:00
Thiago Santos
1fd094d96b qtdemux: improve fragment-start tracking
Some buffers can have multiple moov atoms inside and the strategy
of using the gst_adapter_prev_pts timestamp to get the base timestamp
for the media of the fragment would fail as it would reuse the same
base timestamp for all moofs in the buffer instead of accumulating
the durations for all of them.

Heres a better explanation of the issue:
qtdemux receives a buffer where PTS(buf) = X
buf -> moofA | moofB | moofC

The problem was that PTS(buf) was used as the base timestamp for
all 3 moofs, causing all buffers to be X based. In this case we want
only moofA to be X based as it is what the PTS on buf means, and the
other moofB and moofC just use the accumulated timestamp from the
previous moofs durations.

To solve this, this patch uses gst_adapter_prev_pts distance
result, this allows qtdemux to calculate if it should use the
resulting pts or just accumulate the samples as it can identify
if the moofs belong to the same upstream buffer or not.

https://bugzilla.gnome.org/show_bug.cgi?id=719783
2013-12-04 10:36:38 -03:00
Thiago Santos
45c16599ff qtdemux: avoid re-reading the same moov and entering into loop
In the scenario of "mdat | moov (with fragmented artifacts)" qtdemux
could read the moov again after the mdat because it was considering the
media as a fragmented one.

To avoid this loop this patch makes it store
the last processed moov_offset to avoid parsing it again.
And it also checks if there are any samples to play before
resturning to the mdat, so that it knows there is new data to be played.

https://bugzilla.gnome.org/show_bug.cgi?id=691570
2013-11-29 17:28:48 -03:00
Thiago Santos
0e78ffc9d6 qtdemux: When using a buffered mdat, store all received data for later use
In push mode, when qtdemux can't use a seek to skip the mdat buffer it has
to buffer it for later use.

The issue is that after parsing the next moov/moof, there might be some
trailing bytes from the next atom in the file. This data was being discarded
along with the already parsed moov/moof and playback would fail to continue
after the contents of this moov/moof are played.

This is particularly bad on fragmented files that have the mdat before the
corresponding moof. So you'd get:

mdat|moof|mdat|moof ...

When a moof was received, it usually came with some extra bytes that would
belong to the next mdat (because upstream doesn't care about atoms alignment).
So those bytes were being discarded and playback would fail.

This patch makes qtdemux store those extra bytes to reuse them later after the
mdat is emptied.

https://bugzilla.gnome.org/show_bug.cgi?id=710623
2013-11-07 11:22:03 -03:00
Thiago Santos
33cf8b679d qtdemux: preserve stop of segment when doing seeks in push mode
When handling seeks in push mode, qtdemux converts the seek to bytes
and pushes upstream. It needs to keep track of the seek and the
subsequent segment to be able to map them back to the requested
seek time and properly preserve the segment stop of the seek.

This is done by using the start offset in bytes of the seek,
that should be the same of the segment from upstream. And this
is also backwards compatible with what qtdemux already was using.

https://bugzilla.gnome.org/show_bug.cgi?id=707530
2013-09-10 16:42:36 -03:00
Sebastian Dröge
1a0278ed64 qtdemux: Add support for group-id in the stream-start event 2013-07-22 15:30:13 +02:00
Matej Knopp
ca32442f86 qtdemux: offset samples according to edit list
https://bugzilla.gnome.org/show_bug.cgi?id=700264
2013-07-15 09:59:23 +02:00
Matej Knopp
3111161e8a qtdemux: unselect instead of ignoring disabled track, detect chapter track
https://bugzilla.gnome.org/show_bug.cgi?id=704007
2013-07-12 11:45:33 +02:00
Thiago Santos
4d073beeee qtdemux: some code cleanup for mss handling code
* Explicitly init variables for fragmented formats at init
* Do not use GstClockTime type if the variable isn't a timestamp
* Fix a style/readability issue at an if block
* Group 2 mss mode conditional blocks together to improve readability

Conflicts:
	gst/isomp4/qtdemux.c
2013-05-07 19:29:17 -03:00
Louis-Francis Ratté-Boulianne
d499b461da qtdemux: Remove old pads when exposing streams and other general fixes.
Conflicts:
	gst/isomp4/qtdemux.c
2013-05-07 19:18:03 -03:00
Thiago Santos
a3c19eeea1 qtdemux: handle mss streams
smoothstreaming streams should be handled as a special kind of
fragmented isomedia. In MSS the fragments will not contain a
'moov' atom with the media descriptions, this has to be extracted
from the caps.

Additionally, there should be another demuxer upstream that is likely
going to be the one to answer/act on queries and events, so qtdemux has
to forward those upstream.
2013-05-07 19:18:03 -03:00
Tim-Philipp Müller
230cf41cc9 Fix FSF address
https://bugzilla.gnome.org/show_bug.cgi?id=687520
2012-11-04 00:07:18 +00:00
Michael Smith
3a3a7c38aa qtdemux: allow more streams. Bump this constant to 32, which should be
enough for real-world files.
2012-10-12 14:38:33 -07:00
Arnaud Vrac
f0db4a8213 qtdemux: fix parsing in push mode when moov atom is at the end
When playing an mp4 file with the MOOV atom at the end of the file, playback
fails with the error message "no 'moov' atom within the first 10 MB". This is
due to a mistake in the upstream_size typing, making the seek to the end of
file never happening.

https://bugzilla.gnome.org/show_bug.cgi?id=684972
2012-09-27 22:20:19 +01:00
Tim-Philipp Müller
aeb69c188b qtdemux: update for GstIndex removal 2011-12-30 17:23:43 +00:00
Wim Taymans
33f18b8ea4 Merge branch 'master' into 0.11
Conflicts:
	gst/audioparsers/gstamrparse.c
	gst/isomp4/qtdemux.c
2011-09-06 16:06:25 +02:00
Mark Nauwelaerts
e15d29ffe4 qtdemux: push mode; perform some extra checks prior to upstream seeking 2011-08-30 14:24:04 +02:00
Mark Nauwelaerts
f886681367 isomp4: port to 0.11 2011-06-29 12:46:20 +02:00
Arun Raghavan
f89caeff5c qtdemux: guess bitrate if only one stream's bitrate is unknown
If the bitrates for all but one audio/video streams are known, and the
total stream size and duration can be determined, this calculates the
unkown bitrate as (stream size / duration) - (sum of known bitrates).
While this is not guaranteed to be very accurate, it should be good
enough for most purposes.

For example, this is useful for H.263 + AAC streams where no 'btrt' atom
is available for the video portion.

https://bugzilla.gnome.org/show_bug.cgi?id=619548
2011-05-16 13:29:56 +02:00
Tim-Philipp Müller
c25bf5dc34 quicktime: rename plugin to isomp4
https://bugzilla.gnome.org/show_bug.cgi?id=648004
2011-04-30 17:58:02 +01:00
Renamed from gst/quicktime/qtdemux.h (Browse further)