In some scenarios the fakevideosink shouldn't advertize the overlay-composition
meta for instance, so that overlay elements perform subtitles blending
themselves.
According to the specification, the adaptation field length must be 183 if
there is no payload data and < 183 if the packet contains an adaptation
field and payload data.
Unfortunately some payloaders always set the flag for payload data, even if
the adaptation field length is 183.
Don't return with an error in this case. Clear the payload data flag
instead and parse the adaptation field as usual. This avoids visual
artefacts for such streams.
For interlaced video:
* set the interlace mode in the src caps
* double the height from SPS in the caps.
* set field latency, instead of frame latency.
Fix#778
Add new property to signalling that there is no incoming data
from peer. This can be useful if users want to stop the streaming
when the connection is alive but no packet is arriving.
Both 2 and 4 are supported version of AAC ADTS format stream.
So we need to set correct version to help negotiation
especially for non-autopluggable pipeline.
Some mpeg-ts (HLS, DVB, ...) streams out there have completely broken
PCR streams on which we can't reliably recover correct timestamps.
For those, provide a property that will ignore the program PCR stream
(by faking that it's not present (0x1fff)).
Initially the case "only codec_data is different" was addressed in
https://bugzilla.gnome.org/show_bug.cgi?id=705333 in order for
unusual bitstreams to be handled. That's the case where sps and pps
are placed in bitstream. When sps/pps are signalled only via caps
by upstream, however, the updated codec_data is mandatory for decoder
and therefore we shouldn't ignore them.
According to following two specs, add support for AC4 in tsdemux.
1. ETSI TS 103 190-2 V1.2.1 (2018-02) : Annex D (normative): AC-4 in MPEG-2 transport streams
2. ETSI EN 300 468 V1.16.1 (2019-08) : Annex D (normative):Service information implementation of AC-3, EnhancedAC-3, and AC-4 audio in DVB systems
- Display caps of the pad we actually tried to link.
- Use the template caps as the filter is likely to not have any caps set
yet.
- Log pad name as well.
The approach is quite simple and doesn't take all use cases into account,
it only implements support when we are using the internal timecode we
create ourself.
Also the way we compute the sought frame count is naive, but it works
for simple cases.
Filter operates on raw data so don't allow decodebin to produce
encoded data if one is defined.
My use case here is keeping the video stream untouched but apply a filter
on the audio one, while keeping the same audio format.
In case the application has to deal with fussy servers. User agent
sniffing is so last decade.
Adds a property to set the Flash version on both the sink and the src.
The default stays the same (IIRC, Flash plugin for Linux from 2009).
The former uses a thread-safe way of getting statistics from the
connection without having to protect the fields with a lock.
The latter produces a zeroed statistics structure for use when no
connection exists.
Apply outgoing sizes only after writing the chunk to the peer. This is
important particularly for the set chunk size and allows exposing it
without threading issues.
Move output chunking from gst_rtmp_connection_queue_message into
gst_rtmp_connection_start_write, which effectively moves it from the
streaming thread into the loop thread.
This allows us to handle the outgoing chunk-size message (which is
generated by changing the future chunk-size property) properly, which
could come from any other thread.
Serializes an RTMP message into a series of chunks, all in one buffer.
Similar to what gst_rtmp_connection_queue_message does to serialize
into a GByteArray.
Similar to gst_rtmp_output_stream_write_all_bytes_async, but takes a
GstBuffer instead of a GBytes. It can also return the number of bytes
written, which might be lower in case of an error.
OBJECT_LOCK is used to protect property access only. self->lock is
used to access the RtmpConnection, mostly between the streaming thread
and the loop thread.
To avoid deadlocks involving these two locks, we obey a lock order:
If both self->lock and OBJECT_LOCK are needed, self->lock must be locked
first. Clarify this.
