Initialize min and max _get_property() to gets rid of these
compiler warnings:
gstappsrc.c:741:7: error: 'max' may be used uninitialized in this function
g_value_set_int64 (value, max);
^
gstappsrc.c:733:7: error: 'min' may be used uninitialized in this function
g_value_set_int64 (value, min);
^
Which happens because gcc doesn't know that GST_IS_APP_SRC will never
fail here.
https://bugzilla.gnome.org/show_bug.cgi?id=752052
This way special characters such as '@' can be used in
usernames or passwords, e.g.
rtsp://view:%40dm%4An@<IP-ADDR>/media/camera1
will now parse username and password into:
User: view
Pass: @dm:n
https://bugzilla.gnome.org/show_bug.cgi?id=758389
When parsing NUL-terminated strings, do not include the terminating
NUL byte(s). Depending on the encoding used, either g_utf8_validate()
failed due to this, or worse the call to g_utf16_to_utf8() would
return 0 items read on an empty string, causing it to fail parsing
certain frames.
https://bugzilla.gnome.org/show_bug.cgi?id=770355
encoding-profile.c: In function ‘get_profile_format_from_possible_factory_name’:
encoding-profile.c:1532:6: error: ‘fact’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (fact)
^
encoding-profile.c: In function ‘profile_from_string’:
encoding-profile.c:1720:6: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (profile)
^
cc1: all warnings being treated as errors
Instead of enforcing the user to know and understand caps to describe
the encoding format, let him use element factory names directly.
This also makes it possible to ensure that a specific encodore/muxer
is used instead of letting the ranking system do it.
It is now possible to describe an encoding format simply specifying:
matroskamux:x264enc:vobisenc
Factor out functions in the parsing, cleaning up the whole thing.
Update documentation.
We used to only care about the name of the files even if the name
is defined in the encoding target serialized file.
That commit also allows user to define several names for a single
target file (using a ';' between the names) which allows us to have
a target for youtube that is called 'youtube;yt' or a target for
'ogg;ogv;oga' file extension.
Make sure ticks start with an accumulator value of 0 by incrementing it
after filling in samples instead of before and by resetting the accumulator
every time a tick begins. This prevents it from being discontinuous at the
beginning of the tick.
https://bugzilla.gnome.org/show_bug.cgi?id=774050
When plugging and then exposing a parser, don't fail
if it fails to send sticky events. The most likely
reason is that things were flushed due to the app
immediately doing a seek, but we can't detect flushing
separately to other error conditions without a
gst_pad_send_event_full() core function that returns
a GstFlowReturn.
In some case we might have EncodingProfile that will be defined
in a way that, for example if a Preset is not present, another
profile for that stream should be used.
A test is added showing the feature.
https://bugzilla.gnome.org/show_bug.cgi?id=776188
We checked this already earlier, so this is dead code.
Leave an assert in place for consistency with the other
branch and in case the rest of the code changes.
CID 1397350.
The caps put into the stream topology by decodebin are the caps at the
moment the pads are exposed on it. This is usually before decoders
received any buffers.
In discoverer we however wait for pre-roll, which ensures that each
decoder handled buffers already. At this point, there might be more
information known about the caps already that we could make use of.
One example here is extra information stored in the SEI of H264, like
the multiview-mode. This will be known if there is a SEI before the
first keyframe, but decodebin won't put this into the topology as it
only waits for the initial caps of h264parse (which come directly after
SPS/PPS).
With this change, the multiview-mode is in the caps reported by
discoverer in many cases.
There are cases when there is no demuxer involved that could do the
buffering, e.g. HLS with raw MP3 or AAC. In this case we want to place
the buffering multiqueue after the parser.
Before this change, we've considered the first element after the
adaptive streaming demuxer as a parser. This is not always true, e.g.
id3demux. Instead we now wait until we actually have a parser (or
decoder).
Fixes playback on such HLS streams.
To make the structs usable in bindings, and fix
gstrtspmessage.c:1188: Warning: GstRtsp:
gst_rtsp_message_parse_auth_credentials: return value: Invalid
non-constant return of bare structure or union; register as
boxed type or (skip)
https://bugzilla.gnome.org/show_bug.cgi?id=774416
Pass the frame data and size explicitly to
id3v2_add_id3v2_frame_blob_to_taglist() and add a
comment that it's being deliberately / manually
passed the full ID3v2 frame including header.
