If there are 3 or more known atoms in a row, it's likely that this is
actually MOV/MP4 even if we don't find any other known atoms. If 5 or
more are found then this is most certainly MOV/MP4 and we can return.
Also if a moov and mdat atom is found, this is definitely a MOV/MP4 file
and can be used as such, independent of anything else following the
mdat.
Fixes typefinding of various MOV files that have no `ftyp` atom but
otherwise a valid file structure followed by some garbage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1013>
Include the Program Stream Map packet type 0xBC in the
set of packets we treat as PES. This fixes typefinding
on MPEG-PS streams with PSM, where the PSM would previously
be considered a loss-of-sync and cause the typefind
to require more data.
The string "\"OTIO_SCHEMA\":" is 14 characters and not 15. Checking for
15 characters would also check for the final '\0', which does not exist
in any otio file as the string is the key of a JSON map.
memcmp() returns 0 (aka FALSE) on match and a difference otherwise.
Previously the typefinder was matching on anything but otio files that
happened to have some curly braces in the beginning of the file.
Fixes a false positive with a MOV file.
By suggesting possible detection too early, it's possible that
the wrong format is detected. Hold off making suggestions until one
of the following conditions is met:
* Probability > GST_TYPE_FIND_LIKELY
* At least MPEG_MIN_PROBE_LENGTH bytes have been examined
* EOS, in which case the best guess wins
Fixes#628
Both versions are basically the same, but version 2.0 also allows
60000/1001 as framerate and allows to specify the field and line number
for each payload.
Put the major version into the caps so that elements can limit via caps
negotiation which versions they can support.
(yes, this has never worked since it was introduced, don't worry)
If we want to actually detect layer/channels/samplerate changes,
it would be better to:
* not reset the various prev_* variables at every iteration.
* and actually store the values when they change
CID #206079
CID #206080
CID #206081
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
HLS files can have arbitrary extra tags in them, and
those can be quite long lines. We need to search
further than 256 bytes sometimes just to get past the
first few lines of the file. Make the limit 4KB,
which matches a typical input block size and should
hopefully cover every crazy input.
https://bugzilla.gnome.org/show_bug.cgi?id=780559
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.
