Add some utility functions for language tags and ISO-639
codes. These are useful for both GUIs and elements. The
iso-codes package is used for language name translations
if available.
API: gst_tag_get_language_codes()
API: gst_tag_get_language_name()
API: gst_tag_get_language_code()
API: gst_tag_get_language_code_iso_639_1()
API: gst_tag_get_language_code_iso_639_2B()
API: gst_tag_get_language_code_iso_639_2T()
Add a new video event to mark the start or end of a still-frame
sequence, and a parser function to identify and extract info from
such events.
API: gst_video_event_new_still_frame()
API: gst_video_event_parse_still_frame()
Fixes: #601942
This completes the deprecated GTK API fix in commits 81a0a986 and
79adfa54 - unlike gtk_signal_connect and co, g_signal_connect and
co take a gpointer, not a GtkObject.
the uninstalled wrapper would create a LD_LIBRARY_PATH with system-wide
path before the local ones... resulting in the example applications picking
up the system-wide libraries and not the (potentially modified) uninstalled
libraries
Rhythmbox uses cdda:// URIs of the form cdda://track#device, which
worked before the fix for bug #321532.
Also adds a check for negative track numbers and some unit tests for URI
parsing.
Fixes bug #595454.
Revert previous 'fix' for bug #588717 and fix it properly, whilst
maintaining the streamheader field on the output caps. Also make
sure we don't leak header buffers we couldn't push when downstream
is unlinked. Add unit test for the presence of the streamheader
field on the output caps and for the issue from bug #588717.
There are flac-in-ogg files without the usual flac packet framing
and these files just have a 4-byte fLaC ID packet as first packet.
We need to recognise the type just from these four bytes if we
want oggdemux to recognise these streams correctly.
Keep the pipeline paused when we detect download buffering. The user has to
manually start the pipeline for now because we can't estimate when the buffering
will finish or when we have underrun.
This tests seeking on an adder that has a normal and a live source connected.
Wheter the current behavior is the desired one needs to be discussed still
(see #586033)
Be even less restrictive in what we accept for .srt timestamps when
typefinding and parsing subrip subtitles and add a unit test for
the 'new' format. Fixes#585197.