https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
Avoids some false positives leading to miss identification:
* Prevent picture start code emulation for the first 2 bytes read
* Add check for valid "picture coding type" and "PB-frames mode" combination
Additionally, change name on confusingly named TR var to what
it is, the layer's PTYPE.
https://bugzilla.gnome.org/show_bug.cgi?id=693263
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
