... since the TEARDOWN sequence might not have had a chance to even start,
but at least connections should be closed (synchronously) and state cleaned up.
See #632504.
Simplify the command handling; passing a command to thread means we really
want it to get the message, which means to always flush provided the command
can handle being interrupted. Command thread indicates whether command
allows interruption and ensure non-flushing connection as it subsequently
needs it.
In particular, this also makes the TEARDOWN sequence interruptable
and also prevents races where _loop_ could miss a command and would
continue receiving (or at least trying to).
See #632504.
With the async state changes, it is possible that we need to open the stream
before play and pause.
Also make sure we remember a previous open failure so that we don't keep trying
again.
Simplify the command handling, only continue looping when we have not received
another command or when the previous loop was successfull.
Avoid looping on a disconnected socket.
If the lock is not released before emitting a signal, it may cause a deadlock
if any other function in the element is called.
Also removed an unused timestamp parameter
https://bugzilla.gnome.org/show_bug.cgi?id=649617
Since the segment duration is given in terms of the
GST_MATROSKA_ID_TIMECODESCALE we should only convert it into
nanoseconds when we are sure that any scale specified in the file has
been read.
https://bugzilla.gnome.org/show_bug.cgi?id=650258
If the bitrates for all but one audio/video streams are known, and the
total stream size and duration can be determined, this calculates the
unkown bitrate as (stream size / duration) - (sum of known bitrates).
While this is not guaranteed to be very accurate, it should be good
enough for most purposes.
For example, this is useful for H.263 + AAC streams where no 'btrt' atom
is available for the video portion.
https://bugzilla.gnome.org/show_bug.cgi?id=619548
This parses the 'damr' atom if present, and exports the maximum bitrate
of the stream using the mode set field to determine the highest bitrate
frame type that might be present.
https://bugzilla.gnome.org/show_bug.cgi?id=620186
Since the segment duration is given in terms of the
GST_MATROSKA_ID_TIMECODESCALE we should only convert it into
nanoseconds when we are sure that any scale specified in the file has
been read.
https://bugzilla.gnome.org/show_bug.cgi?id=650258
Otherwise wavenc will fail if upstream decides to set equivalent caps or caps
with additional information later.
Thanks to Alexander Schremmer for finding this bug.
Highlights:
- amrparse, aacparse, ac3parse, flacparse, mpegaudioparse, dcaparse audio parsers (moved from -bad)
- muxers now mux based on running time
- ISO MP4 muxers: mp4mux/3gppmux/qtmux/mj2mux (moved from -bad)
- new matroskaparse element
- new v4l2radio element
- rtpsession: support RTCP Early Feedback (the AVPF profile)
- orc 0.4.14 or newer recommended
- many other fixes and improvements
A duration tag gets inserted only for streamable=false, so only
update/write the duration later if we actually inserted that tag,
otherwise we write garbage into other tags.
https://bugzilla.gnome.org/show_bug.cgi?id=649060
