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.
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.
Ensure that nothing is in any of the streaming thread functions
anymore when going from PAUSED to READY. While the parent's state change
function has deactivated all pads, there is nothing preventing
downstream from activating our srcpad again and calling the getrange()
function. Although we're in READY!
https://bugzilla.gnome.org/show_bug.cgi?id=775687
The flags and field order weren't properly initialized in the
gst_video_info_init().
Furthermore in gst_video_info_from_caps() we might set unitiliazed
values previously, this only sets them if valid.
Optimize LE<->BE conversion by adding a dedicated fast path instead of
using the generic converter. Implement transform_ip function in order to do the
endian swap in place.
This saves buffer allocation for the intermediate format, can be done in place
and also performs the conversion in one step instead of unpack-convert-pack.
For all bit widths the naive algorithm is implemented, which provides the best
performance when compiled with -O3. ORC was considered but eventually removed
as it requires a dedicated function for in-place conversion (due to the
"restrict" parameters).
A more complex algorithm for the 24-bit conversion with unrolled loop and
32-bit processing is implemented in the #if 0 section. It performs better if
compiled with -O2. With -O3 however the naive algorithm performs better.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
It is not needed to store a pointer to every single chain element to free it.
Instead walk the channel list backwards and free the chain elements one by one.
Rename GstAudioConverter->chain_pack to chain_end.
https://bugzilla.gnome.org/show_bug.cgi?id=773073
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
When gst_rtp_buffer_add_extension_onebyte_header() is used over a
GstRtpBuffer that only contains a memory for the whole packet,
ensure_buffers function crashes at the next point:
mem = gst_memory_copy (rtp->map[i].memory, offset, rtp->size[i]);
when i==2 because the payload is not mapped.
In addition the offset is calculated subtracting in the wrong direction.
https://bugzilla.gnome.org/show_bug.cgi?id=774959
For example mmap can fail with EACCES if the the fd has been open
with read only mode. And mapping the memory might be the only way
to check that. So no need to print out an error.
Ex: ioctl(dev, DRM_IOCTL_PRIME_HANDLE_TO_FD, flags & ~DRM_RDWR)
https://bugzilla.gnome.org/show_bug.cgi?id=765600
This class was made subclassable, though for future growth of the code,
it's better if we have some room for add class members. Using the small
padding since this is unlikely.
For drop-frame timecodes, the nsec_since_daily_jam doesn't necessarily
directly correspond to this many hours/minutes/seconds/frames. We have
to get the frame count as per frames_since_daily_jam and then convert.
https://bugzilla.gnome.org/show_bug.cgi?id=774585
Rename function parameter and make sure the name in the
declaration matches the name in the implementation, to
avoid g-i warnings. Also add Since markers for gtk-doc.
gstappsink.c:1248: Warning: GstApp: gst_app_sink_set_buffer_list_support:
unknown parameter 'buffer_list' in documentation comment, should be 'drop'
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
They especially don't make sense for encoders to answer
based on upstream values - although perhaps later
we could make it do TIME->BYTES conversion on the source
pad based on bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
