When not using the fieldanalysis element immediately upstream of deinterlace,
behaviour should remain unchanged. fieldanalysis will set the caps and flags on
the buffers such that they can be interpreted and acted upon to produce
progressive output.
There are two main modes of operation:
- Passive pattern locking
Passive pattern locking is a non-blocking, low-latency mode of operation that
is suitable for close-to-live usage. Initially a telecine stream will be
output as variable framerate with naïve timestamp adjustment. With each
incoming buffer, an attempt is made to lock onto a pattern. When a lock is
obtained, the src pad and output buffer caps will reflect the pattern and
timestamps will be accurately interpolated between pattern repeats. This
means that initially and at pattern transitions there will be short periods
of inaccurate timestamping.
- Active pattern locking
Active pattern locking is a blocking, high-latency mode of operation that is
targeted at use-cases where timestamp accuracy is paramount. Buffers will be
queued until enough are present to make a lock. When locked, timestamps will
be accurately interpolated between pattern repeats. Orphan fields can be
dropped or deinterlaced. If no lock can be obtained, a single field might be
pushed through to be deinterlaced.
Locking can also be disabled or 'auto' chooses between passive and active
locking modes depending on whether upstream is live.
... 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
