Commit graph

298 commits

Author SHA1 Message Date
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
a82f3418fd qtdemux: drain the adapter before pushing EOS
In a fragmented scenario, qtdemux is operating in push mode
and it gets a fragmented buffer. While processing its data
downstream gets unlinked (or a input-selector changes its
active pad and returns not-linked). Qtdemux stops processing
this fragment and returns not-linked upstream, leaving the
remaining data in its adapter.

When it gets an EOS it should make sure that all the data it
had received is pushed before pushing EOS.
2013-12-27 12:00:27 -03:00
Sebastian Dröge
371482a90c qtdemux: Fix calcuation of descriptor length
https://bugzilla.gnome.org/show_bug.cgi?id=720813
2013-12-23 15:09:49 +01: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
079dde49ed qtdemux: Use the timestamp of the moof as the base fragment start
In SmoothStreaming fragmented scenario, the timestamps are calculated
starting from the fragment buffer timestamp. When there is a not-linked
return from downstream, qtdemux will return upstream and will keep the
non-pushed data into its adapter.

On a new fragment buffer pushed to qtdemux, the new buffer timestamp
would overwrite the previous one that should be used on the still
to be pushed buffers. Because of this, this patch will also
update the fragment_start timestamp from the adapter last pts
to make sure the moof and timestamps are in sync and will result
in correct timestamps for all fragments.
2013-11-29 17:28:48 -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
fcc78aa3bd qtdemux: do not free streams if they were not created locally
When parsing a trak only free streams on failures if those streams
were created locally. They could have been created from a previous
fragment, in this case we they have valid info from the other fragment.
Including pads.

https://bugzilla.gnome.org/show_bug.cgi?id=691570
2013-11-29 17:28:48 -03:00
Tim-Philipp Müller
4278ab18ff qtdemux: fix compilation with gst debuging disabled
qtdemux.c:9452:1: error: label at end of compound statement
2013-11-29 09:21:52 +00:00
Jan Schmidt
b3b89dfec1 qtdemux: Add HydrogenAudio ReplayGain tags
Identical to the itunes (tm) version, but labelled with
org.hydrogenaudio.replaygain as the producer.
2013-11-28 22:36:44 +11:00
Jan Schmidt
fdfc6a2a86 qtdemux: Discard 2 byte subpicture packets
As for text subtitles and as suggested in #712643, throw
away the 2 byte terminator packets that some encoders insert.

This will make things better when remuxing and causes generation
of gap events.
2013-11-25 12:24:22 +11:00
Thibault Saunier
a45d470236 qtdemux: Use GstVideoInfo helper to create caps for raw video
This way we do not miss mandatory fields in caps.
At the same time use the gst_pb_utils_get_codec_description
helper to get codec description.

https://bugzilla.gnome.org/show_bug.cgi?id=712335
2013-11-22 18:52:54 -03:00
Tim-Philipp Müller
d9c2914c90 g_memmove() is deprecated
Just use plain memmove(), g_memmove() is deprecated in
recent GLib versions.

https://bugzilla.gnome.org/show_bug.cgi?id=712811
2013-11-21 15:30:34 +00:00
Jan Schmidt
81e2c8130a isomp4: Handle mp4s subpicture streams better.
Clean up the handling of mp4s streams. Use the generic esds
descriptor function to extract the palette, instead of hard coding
a wrong magic offset.

Add some more size safety checks when parsing ES descriptors, and
replace magic numbers with the descriptive constants that are already
defined.

Enhance dump output for stsd atoms.

Streams from both bug 712643 and historic bug 568278 now both work
correctly.

Fixes: #712643
2013-11-21 02:28:27 +11:00
Jan Schmidt
217d2d8deb qtdemux: Sort fourcc declarations and remove duplicates 2013-11-20 22:08:25 +11:00
Jan Schmidt
b6f581eecc qtdemux: Merge all the fourcc headers into one
Remove qtdemux_fourcc.h and ftypcc.h and put it all in fourcc.h
2013-11-20 21:48:03 +11:00
Thiago Santos
cfdadd4114 qtdemux: remove math operation from loop
The elst_offset doesn't change inside the loop, so compute it
outside
2013-11-14 18:15:20 -03:00
Stefan Sauer
1a4e7338d9 qtmux: fix playback regression
In ae1150e85c flipping a condition misaligned the
else branch, where for there condition that was change there is none.
Fixes #712303
2013-11-14 20:56:36 +01:00
Thiago Santos
33ebda8ecf qtdemux: handle fragmented files with mdat before moofs
Assume a file with atoms in the following order: moov, mdat, moof,
mdat, moof ...

The first moov usually doesn't contain any sample entries atoms (or
they are all set to 0 length), because the real samples are signaled
at the moofs. In push mode, qtdemux parses the moov and then finds the mdat,
but then it has 0 entries and assumes it is EOS.

This patch makes it continue parsing in case it is a fragmented file so that
it might find the moofs and play the media.

https://bugzilla.gnome.org/show_bug.cgi?id=710623
2013-11-07 11:22:04 -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
2eec7909aa qtdemux: check if the end_time is defined before using it
Avoids sending EOS too soon because of overflow. Can happen on
fragmented mp4 playback.
2013-10-25 11:30:36 -03:00
Thiago Santos
673301ef48 qtdemux: use correct unref function
Events aren't GstObjects, but GstMiniObjects
2013-10-23 13:38:56 -03:00
Stefan Sauer
ae1150e85c qtdemux: rename chunks_are_chunks to chunks_are_samples and flip the logic
As the variable name suggests, sometimes chunks are chunks. Rename the variable
to tell what they are when they are not chunks.
2013-10-15 09:53:30 +02:00
Stefan Sauer
6789ba1ece qtdemux: fix typos and add more logging for unhandled parts 2013-10-15 09:53:30 +02:00
Sebastian Dröge
21947f9d13 qtdemux: Add support for the mp2v fourcc for MPEG-2 video
https://bugzilla.gnome.org/show_bug.cgi?id=709270
2013-10-03 11:59:25 +02:00
Sreerenj Balachandran
e779b6587b qtdemux: Add HEVC support
https://bugzilla.gnome.org/show_bug.cgi?id=709093
2013-10-02 11:54:24 +02:00
Hans Månsson
041946423a mp4mux: Do not require framerate in peer video caps
Remove the framerate restriction on the caps.

Reference: https://bugzilla.gnome.org/show_bug.cgi?id=708864
2013-09-28 13:02:11 +02:00
Sebastian Dröge
4a91a93d4e qtmux: Don't error out if downstream is not seekable for non-fragmented variants
Doing so would be a regression over 1.0 and breaks the unit test.
However the result will be most likely unusable, so let's post
a warning message on the bus.
2013-09-25 13:25:34 +02:00
Thiago Santos
dc02d91c14 qtdemux: add code to parse creation time earlier than 1970
Use g_date_time seconds manipulation to allow to cover the quicktime
spec for creation_time. It uses seconds since 1904.

Both paths could be done using the generic approach of seconds since
1904 with GDateTime handling, but the first path using seconds from
1970 should be more commonly found and avoids a few objects creation and
ref/unref, so keep it there for performance.

Additionally, the code for handling seconds since 1970 changed from >
to >= because having 0 seconds since 1970 is also a valid case for that
path to handle.

https://bugzilla.gnome.org/show_bug.cgi?id=707975
2013-09-24 15:16:54 -07:00
Andoni Morales Alastruey
cfefdaebb6 qtmux: handle issues correctly when downstream is not seekable
The streamable property only make sense for fragmented formats.
For regular MP4, when downstream is not seekable we can't rewrite
the headers, so qtmux can only work with fast-start=TRUE, where
the headers are written finishing the file.
For fragmented MP4, when streamable is not seekable and the streamable
property is FALSE, we must enforce streamable=TRUE warning the user
about this change

https://bugzilla.gnome.org/show_bug.cgi?id=707242
2013-09-20 10:09:48 +02:00
Andoni Morales Alastruey
9ae5082204 qtmux: make "streamable" TRUE as default
The most common use case for fragmented MP4 (Dash and Smooth Streaming)
is producing streamable content (even for VOD). streamable=FALSE would only
be used to generate fragmented MP4 with and index of MOOF's that could
be reproduced without a playlist/manifest
https://bugzilla.gnome.org/show_bug.cgi?id=707242
2013-09-20 10:09:48 +02:00
Andoni Morales Alastruey
5732684e18 qtmux: deprecate the streamable property for non-fragmented MP4
The streamable property only makes sense for fragmented MP4.
https://bugzilla.gnome.org/show_bug.cgi?id=707242
2013-09-20 10:09:48 +02:00
Matej Knopp
b2982bb749 qtmux: remove MAX_TOLERATED_LATENESS
https://bugzilla.gnome.org/show_bug.cgi?id=707411
2013-09-16 11:11:12 -03:00
Matej Knopp
b363832c2c qtmux: set first_ts to DTS for streams that have DTS
https://bugzilla.gnome.org/show_bug.cgi?id=707340
2013-09-16 12:14:00 +02:00
Matej Knopp
39f7e52266 qtmux: make sure duration is a valid number for last buffer
https://bugzilla.gnome.org/show_bug.cgi?id=707340
2013-09-16 12:14:00 +02:00
Matej Knopp
4e3c13c87c qtmux: use segment.start or last buffer end time in case of missing DTS
https://bugzilla.gnome.org/show_bug.cgi?id=707340
2013-09-16 12:14:00 +02:00
Matej Knopp
85728c04c4 Revert qtmux: Use buffer PTS if DTS is not set"
This reverts commit f72c3cf71fde622067f41f31a53978ba4c94469d.

https://bugzilla.gnome.org/show_bug.cgi?id=707340
2013-09-16 12:13:54 +02:00
Thiago Santos
566b0dce40 qtdemux: only update stop position if seek requests it
Check for GST_SEEK_TYPE_NONE for stop poistion and only update
the stop time if it is requested. Otherwise just maintain whatever
was stored at the segment

https://bugzilla.gnome.org/show_bug.cgi?id=707530
2013-09-13 09:21:12 -03:00
Thiago Santos
be0eeae491 qtdemux: track streams that are EOS on push mode to finish earlier
When the segment has a defined stop position, qtdemux should check
when streams reach this position and mark those as EOS. When all
streams are EOS it will return GST_FLOW_EOS to upstream to allow
the pipeline to finish instead of continuously consume buffers
from upstream that are not useful for the segment.

https://bugzilla.gnome.org/show_bug.cgi?id=707530
2013-09-10 16:43:17 -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
Alex Ashley
a965185dee qtdemux: Add support for the avc3 sample entry format of the AVC file format
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 (i.e. the first sample in
each mdat box).  The principal reason for avc3 is to make it easier
for client implementations, because it removes the requirement to
insert the SPS+PPS in to the decoder pipeline every time there is a
representation change.

This commit adds support for the "avc3" atom, which is almost identical
to the "avc1" atom, except it does not contain any SPS or PPS data.

https://bugzilla.gnome.org/show_bug.cgi?id=702004
2013-09-04 13:33:22 +02:00
Tim-Philipp Müller
1dfc1f2686 Don't use setlocale in plugins()
Only apps should call setlocale(), not libraries.
2013-09-01 21:18:38 +01:00
Thiago Santos
9549289a18 qtdemux: push buffers after segment stop until reaching a keyframe
This should make decoders able to precisely push buffers until the stop
time in case they need the next keyframe to do it.

Also, according to gst_segment_clip, it should only push a buffer that
the starting ts is strictly smaller than the segment stop, so we change
the min < comparison for <=
2013-08-28 12:58:56 -03:00
Chris Bass
3e9dea3f8c qtdemux: check denominator isn't zero before scaling duration.
When gst_qtdemux_configure_stream sets fps_d, check that n_samples is
non-zero before using it as a denominator to scale the stream duration.

https://bugzilla.gnome.org/show_bug.cgi?id=706076
2013-08-16 10:14:30 +02:00
Matej Knopp
2269ac8f28 qtdemux: elst should offset samples instead of buffers
The current approach where buffers are offset is not ideal, as during seek
and loop current time is compared to sample times.

https://bugzilla.gnome.org/show_bug.cgi?id=700264
2013-08-12 13:48:04 +02:00
Thibault Saunier
38946bd9f4 qtdemux: Fix compilation 2013-08-06 15:31:38 +02:00
Thibault Saunier
593a31f2b4 qtdemux: Raw buffer DTS should always be CLOCK_TIME_NONE 2013-08-06 15:17:44 +02:00
Edward Hervey
4f4f6432cc qtmux: Use buffer PTS if DTS is not set
Avoids ending up with completely bogus scaled duration/pts when new
buffers have invalid DTS.
2013-08-04 17:15:38 +02:00
Sebastian Dröge
2e35b36aab gst: Don't swap start/stop for negative rates in the SEGMENT query 2013-07-29 12:12:41 +02:00
Matej Knopp
47ed79fb1c qtdemux: Check for data size when parsing h264 codec data from strf atom 2013-07-29 11:53:07 +02:00
Matej Knopp
2dcdfe07f7 qtdemux: Support H264 fourcc
https://bugzilla.gnome.org/show_bug.cgi?id=704996
2013-07-29 09:11:39 +02:00