The update_receiver_stats() function is called also when sending packets
in rtp_source_send_rtp(), and sending packets may happen using a buffer
list rather than individual buffers.
So update the stats using the actual number of packets sent.
NOTE: this is fine for the receive path too (rtp_process_send_rtp)
because the receive path does not support buffer lists and
pinfo->packets would always be equal to 1 in this case.
The tests create a buffer list and then use the chain_list callback to
verify that the correct packets have been pushed.
Move the creation and validation code next to each other so that the
reader can more easily understand what is going on.
While at it add some comments to introduce the two related functions.
Make it possible to differentiate between the position in the list and
the packet index in the global structures in check_packet, in some
future case the list may change, in case some element removes a buffer
from the list, and the two indices may not coincide.
Port the rtpbin_buffer_list test to GStreamer 1.0 and re-enable it.
Some other changes include:
- the check on the caps has been moved from the buffer level to the
pad level;
- remove underscore prefix from static functions names, this is not
idiomatic in C and rarely used in the other tests;
- the unused header_buffer variable has been removed;
- check_group() has been renamed to check_packet() because in
GStreamer 1.0 there is no concept of "group" anymore, the comments
have also been updated to reflect this.
Tests might take a bit longer, esp. when run under valgrind
and/or they're running on the CI with other things going on,
so let's just bump the timeout to something higher and let
the test runner time us out if needed.
On other OSes, it's not possible to have qmake or the qt5 pkg-config
files and not have moc, and `moc` will not be in `PATH`, so this only
causes problems.
The FLAC specification states that the data is processed in blocks, regardless of the number of channels. Thus, The latency can be calculated using the blocksize and rate. For example a 1 second block sampled at 44.1KHz has a blocksize of 44100
This is needed for the case you don't know in advance all the sessions
you will be using, but would like to place all the related AUX element
in the same GstBin. As per current implementation, each time an sender
AUX bin is requested and returned, RTPBin will walk the src pads and
create sessions for these pads.
In the current implementation, if a src pad already have a sessions, it
returns an error and stops. As a side effect, if an AUX bin is reused in
a following AUX bin request, it can only work if the pads are created on
the last request.
This change simply relax the restriction in order to keep walking, and
just ensure that all newly created pads have a sessions.
The V4L2 elements already set the delta unit buffer flag when dequeueing
the buffer, but gst_video_encoder_finish_frame overwrites it from the
passed codec frame's sync point flag. Set the flag correctly.
And check if argument is supported instead of just passing it blindly,
and make meson code slightly cleaner, centralising the argument setting
in one place.
Need to respect return of gst_video_guess_framerate() to ensure
non-zero denominator.
This patch is to fix below error with an abnormal (but has valid frame) file.
(gst-play-1.0:17940): GStreamer-CRITICAL **: passed '0' as denominator for `GstFraction'
This problem was found in Test. 2 of the YouTube 2018 EME
tests[1]. The code was accidentally not finding an mp4a's esds atom in
the sample description table when the stream was encrypted. It assumed
that if the stream is protected, then only an enca atom will be found
here. What happens with YouTube is they often provide protected
content with a few seconds of clear content, and then switch to the
encrypted stream.
The failure case here was an incorrect codec_data field being sent
into aacparse. The advertisement of stereo audio @ 44.1kHz for the
mp4a (unprotected) stream was incorrect. As usual, the esds contained
the real values here which were mono at 22050 Hz.
Here's what the MP4 tree looks like for these types of files,
demonstrating why the code was making a wrong assumption (or maybe
YouTube is being unusual),
[ftyp] size=8+16
...
[moov] size=8+1571
...
[trak] size=8+559
...
[stsd] size=12+234
entry-count = 2
[enca] size=8+147
channel_count = 2
sample_size = 16
sample_rate = 44100
[esds] size=12+27
...
...
[mp4a] size=8+67
channel_count = 2
sample_size = 16
sample_rate = 44100
[esds] size=12+27
...
In addition to fixing this, the checks for esds atoms in mp4a and mp4v
have been made symmetrical. While I haven't seen a test case for video
with the same problem, it seemed better to make the same checks. This
also fixes a crash reported from another user[2], they also noted the
asymmetry with mp4v and mp4a.
[1] https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test
[2] https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/398
This can happen in various error cases that could happen between the
creation of the element in question and the adding to the rtspsrc.
It causes an ugly critical warning right now but is otherwise harmless.
The imagefreeze element can be handy for benchmarking downstream
elements because it re-uses the same buffer memory and introduces less
overhead compared to always creating new frames with videotestsrc.
However it's not possible to make imagefreeze send EOS when using
gst-launch-1.0.
Add a num-buffers property to make it look more like a source in the
above scenario.
This fixes a critical warning if the last-sample property is enabled:
(gst-launch-1.0:391): GStreamer-CRITICAL **: 01:12:57.428: gst_object_unref: assertion 'object != NULL' failed
If the allocation query does not contain any allocation pools,
gst_query_parse_nth_allocation_pool will leave the local pool,
min, and max variables undefined, so check the array length first.
If pool is NULL, do not call gst_object_unref.
In commit 28e5f9098 (rtpbin: use PacketInfo for the sender, 2013-09-13)
the rtp_source_send_rtp signature changed but the documentation was not
adjusted to match the new one.
Update the documentation to match the function signature.
Some functions now accept a generic 'gpointer data' parameter because
they can work either on a single buffer or a buffer list.
However the comments were still referring to the old 'GstBuffer *buffer'
parameter, so update the comments to match the actual functions
signature.
