This likely breaks stuff. The good: all of the methods now create
field images aligned with input frames, without timestamp mangling.
The bad: this touches a lot of code, much of which is hairy and in
need of cleanup. However, at this point we can reasonably create a
PSNR-based test.
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.
Images might have framerate=0/1 in the caps, which caused an
assertion on deinterlace. I don't know of interlaced image formats
but deinterlace might be hardcoded on some generic pipelines and
it shouldn't assert.
The fix was to set field_duration to 0 if the input has a framerate
with a 0 numerator.
This patch also adds checks for this situation on the unit tests.
https://bugzilla.gnome.org/show_bug.cgi?id=641400
The previous default, greedyh, takes 4 times as long as MPEG-2
video decoding, and is unlikely fast enough on any current CPU
to play 1080i video in real-time. greedyl isn't much faster.
linear was chosen over vfir, since the quality advantage of vfir
is minimal compared to the occasional visual artifacts and slower
processing.
When handling newsegment, flush out the buffer history in the
existing segment, not the new one. Fixes playback in some DVD
cases.
Partially fixes#633294
In a number of cases it is necessary to flush the field history by
performing 'degraded' deinterlacing - that is, using the user-chosen
method for as many fields as possible, then using vfir for as long as
there are >= 2 fields remaining in the history, then using linear for
the last field.
This should avoid losing fields being kept for history for example at
EOS.
This may address part of #633294
Both history_count and fields_required count from 1. As per the while loop
condition that follows this code, to perform the deinterlacing method, we need
history_count >= fields_required fields in the history. Therefore if we have
history_count < fields_required (not fields_required + 1), we need more fields.
Previously "force deinterlacing" was the default, which is a not very
sensible default for the normal use case where deinterlace should act
in passthrough mode unless interlaced content is present.
The diff is a signed integer, not an unsigned one of course.
In modes other than GST_DEINTERLACE_ALL every frame has twice the
duration of the field duration.
