Add comments regarding which LINE()s point to which data in the
temporary buffer and a large comment explaining how the buffer
is processed. This will hopefully be useful to someone, as the
code is not obvious. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Instead of passing a single element of GstBayer2RGB structure into the
gst_bayer2rgb_split_and_upsample_horiz(), pass the entire pointer and
let the funciton pick out whatever it needs out of the structure. This
is a preparatory patch. No functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Pass all three parameters used by the LINE() macro to the LINE() macro
and unroll the code for readability. Add more comments regarding which
of these LINE()s point to which data in the temporary buffer to make
the code less confusing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The j variable is used as an iterator further down in this code, but
here it can be just inlined in the macro parameters to make the code
easier to read. This is done in preparation for further changes. No
functional change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The bayer2rgb process implemented doesn't support in-place tranform.
This element doesn't implement a "transform_ip" vmethod of
GstBaseTransform it will revert to using the "tranform" vmethod.
It's misleading to set it to TRUE, here. Change this to FALSE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add support for conversion to 10/12/14/16 bit bayer pattern.
The implementation is rather simplistic, just take the ARGB
input, generate 16-bit data out of it instead of 8-bit, shift
them as required by the output bitness, and apply endian swap.
Example usage:
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
filesink location=/tmp/bayer12.raw
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
The proxy callback for the notify::last-message was emiting the signal
again on the child, which caused an infinit loop. We could swap the child
and the user data to signal to the bin instead, but it was found that proxying
this signal was not very useful. Typical use case it to set silent=0 and use
deep-notify feature. Proxying that signal just duplicate that output which
isn't very useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4766>
adjust log level from GST_ERROR to GST_WARNING when h264 caps have
codec_data but no avc format or have no codec data or stream-format.
Because theses are not real errors, it is easy to mislead if print error
logs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4675>
We should behave similarly to video parsers so we can use:
- accept-template as we can also accept caps with missing fields.
- accept-intersect to do quick check with the pad template caps as it is
enough. Users should have figured the appropriate full caps on a
previous caps query
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4341>
The framerate should only be replaced (and corrected for alternating field)
when it is parsed from the bitstream. Otherwise, the upstream framerate
from caps should be trusted and assumed correct.
Related to gst-plugins-bad!2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4259>
There may be garbage or some bits before a SOI comes in some problematic
mjpeg streams. For example, some network error may cause the EOI marker
of the previous frame lost, and when the new frame's SOI comes, we still
use the state of the last frame, which will generate errors.
For this kind of frames without EOI, if that frame already has some data
(the SOS segment is detected), we still push it as a frame with CORRUPTED
flag set. But if not, we just discard all the data before the new SOI.
Co-Authored-By: Víctor Jáquez <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4039>
It's only malformed data in APP when its length is less than 6 chars,
because it should have at least an id string. Otherwise, if the id string
is not handled, no warning is raised, only a debug message noticing it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3943>
When the QoS stats are reset (e.g. changing the source) the counters for
dropped + rendered frames are reset to zero which result in negative values
for their difference. This results in max-fps getting pegged at an extremely
high value.
```
fpsdisplaysink.c:373:display_current_fps:<fpsdisplaysink0> Updated max-fps to 36840705952231460864.000000
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3989>
If we know there's only one stream we care about and we
don't have to synchronise audio and video, or send RRs,
we might just as well not hook up all the RTCP bits and
use fewer threads and sockets and simplify the pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3531>
No matter if they're allocated via GSlice or malloc(). The allocator is
completely irrelevant, all local tags need to be in the primer so they
can be handled.
This didn't have any effect in practice because all local tags that
appear in the muxer are allocated via GSlice. Only from the demuxer they
might be allocated via malloc().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3699>
If a discontinuity is detected in push mode, we need to clear the cached section
observations since they might have potentially changed.
This was only done properly when operating with TIME segments (dvb, udp,
adaptive demuxers, ...) but not with BYTE segments (such as with custom app/fd
sources).
We still don't want to flush out the PCR observations, since this might be
needed for seeking in push-based BYTE sources.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1650
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3584>
This wasn't really done, and is needed in order to detect potential section
changes for sections that have got identical information (such as when switching
between streams that have the same PAT/PMT pid and subtable information).
Other checks exist in tsbase to detect if the "new" PAT/PMT really is an update or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3530>
An end packet is only produced once for the last subtitle, so multiple
GAP events between subtitles would result only in a single end packet
and nothing else otherwise. This would potentially starve downstream
then, so instead forward the GAP events in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3534>
This reverts commit fcad4cc646.
This was wrong is so many ways.
* The memcmp was badly used (it should use == 0 to check the data is identical,
and not != 0)
* There was no boundary checks on the present stream section_data when passing
it to memcmp.
* The return value should have been TRUE (i.e. we have done all checks, none of
them failed, therefore the section has been seen before)
* stream->section_data would *always* be NULL if the section had already been
processed
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1559
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3421>
