Don't use GST_EVENT_TIMESTAMP to transfer any PTS
associated with a highlight event, instead store
it in the event structure directly, as
GstEvent::timestamp will disappear in GStreamer 2.0
https://bugzilla.gnome.org/show_bug.cgi?id=761477
This is a regression that was introduced by
commit 1803b3c185
" asfdemux: Add support for dvr-ms"
The problem is that some files/streams might contain stream definition
but there is no actual packets for those streams.
This was used to "define" streams with different bitrates for example.
The first_ts calculation resulted in never ever finding a valid first_ts
since some streams were empty, and therefore never "activating" itself.
Instead of that we first check if we are prerolled. And if we are we
unconditionally get the "first_ts"
The preroll check has been adapted to check whether streams of
each defined type (i.e. audio/video/sub) has been prerolled. This solves
the problem of having different streams of a particular type where only
one stream actually has data.
In the same vein as the previous commit, the end of the file might have been
cut and therefore contains bogus data.
If the object is too short, consider it as garbage and return a non-fatal
flow.
Regression introduced in 97294eb8bb
Some files have garbage at the end of the file, don't error out if we don't
find the index there.
Reverts back to previous behaviour (where corrupted/missing indexex were
not a fatal error).
Regression introduced in 97294eb8bb
... which is how it has always been until changed coincidentally in commit
9ee60482b2 which then prompted commit
dba14178ce to consider ACCURATE as well
to compensate for that in a lateral way
gstasfdemux.c: In function 'gst_asf_demux_parse_stream_object':
gstasfdemux.c:3001:39: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]
is_encrypted = ! !((flags & 0x8000) << 15);
~~~~~~~~~~~~~~~~~~^~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=779329
Otherwise we will happily index into the array at NULL if the requested
index is smaller than the number of languages that were previously
allocated.
https://bugzilla.gnome.org/show_bug.cgi?id=777937
realhash.c:295:11: error: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Werror,-Wconstant-conversion]
*buf1 = 128;
~ ^~~
https://bugzilla.gnome.org/show_bug.cgi?id=775112
An asf object can't realistically be bigger than 2**32 bytes.
If it reports a size bigger than that, consider it corrupt and properly
propagate the error back.
https://bugzilla.gnome.org/show_bug.cgi?id=775070
In some corrupted files, we could end up with no actual streams
being exposed.
In those cases, make sure we properly propagate the failure all
the way to the loop function. This avoids ending up in cases where
we are neither EOS'd nor ERROR'd out from a pipeline point of view.
https://bugzilla.gnome.org/show_bug.cgi?id=774846
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.
_stdint.h is generated by Autotools and we don't really need it. All
supported platforms now ship with stdint.h. The only stickler was MSVC,
and since Visual Studio 2015 it also ships stdint.h now.
Fix seeking when demuxer is in INDEX state. This happens when we
reached the end of the stream. It should still be possible to do
a flushing seek and seek back to any other position though. Instead
the demuxer would just go straight to EOS again instead of going
back to processing packets again from the new position.
https://bugzilla.gnome.org/show_bug.cgi?id=749066
