It is possible for subtitle files to have a string length less than 30.
WebVTT for example may contain only the 'WEBVTT' string in the file
without any cues.
As an example in hls streams, since WEBVTT files can be segmented
like video/audio, some subtitle segments may only contain just the
header string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/708>
If the last WebVTT cue does not have an empty line after it, or if it
does not end with a newline at all, it does not get pushed out and it
won't be displayed.
gst_sub_parse_sink_event() already handles the issue for other subtitle
formats, enable handling it for GST_SUB_PARSE_FORMAT_VTT too.
While at it also add a test for this case.
With playbin the last subtitle chunk would not get displayed
if the last chunk was missing a newline at the end. This is
because streamsynchronizer will hold back the EOS event until
the audio and video streams are finished too, so subparse
would never forcefully push out the last chunk until the very
end when it is too late.
We get a STREAM_GROUP_DONE event from streamsynchronizer however,
so handle that like EOS and force out any remaining text then.
https://bugzilla.gnome.org/show_bug.cgi?id=771853
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.
When a discont buffer is processed, the state is re-initialized, which
nullifies the allowed_tags.
The problem is when a subrip string with tags is processed and allowed_tags is
NULL. The function subrip_unescape_formatting() calls g_strjoinv with a
str_array as NULL, leading to a GLib-CRITICAL.
This patch removes the allowed_tags resetting, in parser_state_init(), but
move it into gst_sub_parse_format_autodetect().
https://bugzilla.gnome.org/show_bug.cgi?id=768525
gstsubparse.c: In function ‘parse_subrip’:
gstsubparse.c:988:7: error: ignoring return value of ‘strtol’, declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
https://bugzilla.gnome.org/show_bug.cgi?id=765042
Don't require a cue identifier preceding the time range line
when parsing WebVTT. We could also store the CueID, but it's
not using anywhere, so just ignore it for now.
Insert extra checks for the validity of the incoming
data when parsing subrip/webvtt content and debug log
output for invalid content.
Should fix Coverity warnings.
WebVTT is a new subtitle format for HTML5 video. In this first
version of the parser the cue settings are parsed but only stored in
the internal parser state structure. Later on these settings could be
part of the GstBuffer metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=629764
In gst_sub_parse_dispose() parser_type will be UNKNOWN,
so these deinit calls were never executed. And we should
clean up the parser state in the downwards state change
anyway.
To celebrate 2013.gnome.asia, updated sami parser for gstreamer 1.x. :D
Remove conditional block for check libxml usage and
implement a simple html markup parser for the sami
parser.
https://bugzilla.gnome.org/show_bug.cgi?id=693056
Do not use the buffer start offset when it is invalid, otherwise a
discontinuity is detected on the next buffer, and the subtitle parser
reset and some subtitle lines are not shown.
Also remove unused next_offset field.
https://bugzilla.gnome.org/show_bug.cgi?id=693981
The codec data blob we get from matroskademux with the SSA/ASS
init section is supposed to be valid UTF-8. If it's not, just
continue with the bits that are valid UTF-8 instead of erroring
out. We don't actually parse the init section yet anyway..
https://bugzilla.gnome.org/show_bug.cgi?id=607630
