When we see prefix NALs before a Subset SPS has been spotted,
it might just be because the stream was truncated at the
start, so don't count those as either 'bad' or 'good' packets.
Embedded systems often have limited charset conversion
functionality, so don't rely on g_convert() (i.e. iconv)
for UTF-16 to UTF-8 conversions, we can easily enough do
that ourselves by converting to native endianness and
then using GLib's helper functions.
It was already checked in an early out, and as it's only
incremented for at most the size of the passed buffer, it
can only become NULL in an address wraparound.
While there, don't cast away const on a pointer.
Coverity 1139845
The typefinder returns LIKELY for as little as one possible
sync and no bad sync (not even taking into account how much
data was looked at for that). It's generally just not fit
for purpose, so should just not return anything like LIKELY
at all ever, even more so since it only recognises one out
of ten H263 files, and likes to mis-detect mp3s as H263.
https://bugzilla.gnome.org/show_bug.cgi?id=700770https://bugzilla.gnome.org/show_bug.cgi?id=725644
This commit adds detection of the "dash" and "avc3" compatible brands
in qt_type_find.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
Remove dodgy code that detects mp3 with as little as
a valid frame sync at the beginning. This was only used
in some unit tests in -good where there were only a few
bytes after the id3 tag. We now require at least two
frame headers.
Fixes mis-dection of text files with UTF-16 LE BOM as mp3.
https://bugzilla.gnome.org/show_bug.cgi?id=681368
With the current test, we get into problems when we try to typefind
a MPEG stream from a small amount of data, which can happen when
we get data pushed from a HTTP source. We thus make a second test
to give higher probability if all the potential headers were either
pack or pes headers (ie, no potential header was unrecognized).
This fixes an issue with a MPEG1/MP2 stream being properly discovered
as video/mpeg from a file, but as audio/mpeg from souphttpsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=703256
Checks if the received XML is a smoothstreaming manifest
in both UTF8 and UTF16 formats. The check is made for a
SmoothStreamingMedia top level element.
Conflicts:
gst/typefind/gsttypefindfunctions.c
Ensure the detection of svc and mvc as a part of h264 stream.
Once the typefinder detect a subset_sequence_parameter_set(ssps),
then each nal unit with type 14 or 20 should be detected as a
part of h264 stream thereafter.
https://bugzilla.gnome.org/show_bug.cgi?id=694346
Make AAC LOAS typefinding a bit more reliable; don't report
a LIKELY probability already after just two sync points, but
scan for a few more consecutive frames and determine probability
based on how many we found. Fixes mis-detection of wavpack file.
https://bugzilla.gnome.org/show_bug.cgi?id=687674
Check for second block sync and return different
probabilities depending on what we found (trumping
the AAC loas typefinder's LIKELY probability after
finding a second frame sync in this particular case).
https://bugzilla.gnome.org/show_bug.cgi?id=687674
They're hardly used, and probably more confusing than anything
else, and it's not clear that anyone would really need to be
able to tell them apart at the media type level.
Only return LIKELY probability if we've seen an SPS, PPS and an
IDR slice nal, i.e. try harder to avoid false positives such
as with certain VC-1 files.
https://bugzilla.gnome.org/show_bug.cgi?id=668565
We added the utf typefinder because the mp3 typefinder was a tad
overzealous when it came to typefinding things as mp3, and replaced
it with even more overzealous utf16/32 typefinders.
Fixes unit test.
fix build errors:
gsttypefindfunctions.c:248:25: error: 'low' may be used uninitialized in this function [-Werror=uninitialized]
gsttypefindfunctions.c:239:24: error: 'high' may be used uninitialized in this function [-Werror=uninitialized]
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
Note that there is already a AMF detection for a different
magic, I'm not sure if that's a different format with the
same initials or not. AMF is used for a few different formats
(including video), so...
This fixes playbin2 playing Asylum modules.
https://bugzilla.gnome.org/show_bug.cgi?id=658514
Similar meaning same layer, same bitrate, and same number of channels
This fixes misdetection of (some MP3 files that have zero padding
between the ID3 tag and the MP3 stream) as H.264 video.
https://bugzilla.gnome.org/show_bug.cgi?id=656018
The length check isn't sufficient, an source might
report the correct length, but then still fail to
read the requested number of bytes for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=652642
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the
needed Android.mk files.
Androgenizer can be found here:
http://git.collabora.co.uk/?p=user/derek/androgenizer.git
We should keep playlist/m3u8 available for normal m3u8 playlists,
which we we'll likely support some day. Also, we probably don't
want this handled like other playlists, so application/* seems
more appropriate in this case, even if it's really just a playlist.
