I don't understand why these lines were added, they don't make sense to
me now and both David and I agree that removing them moves closer to
related logic being correct, therefore, they're being removed.
I've tested a few progressive, interlaced and telecine clips and they
all behave properly timestamp-wise and visually after these changes.
Handle G_MAXINT in the framerates better. If we cannot double or divide the
framerate, clamp to the smallest/largest possible value we can express instead
of failing.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=683861
Fix deinterlace unit test. Need to set right field on output caps.
Also remove right field (not old 0.10 "interlaced" boolean field)
from caps in unit test before comparing old and new.
Remove some bogus code I added during porting that would error out
on missing or variable framerates in input caps. Handle this like
we do in 0.10
Fixes test_mode_disabled_passthrough unit test check.
RFF only occurs on progressive frames in telecine sequences. For
deinterlace, we don't want these repeated fields as we will simply be
pushing the progressive frame and then moving on.
However, we need to consider RFF in order to correctly identify patterns
and adjust the timestamps.
The logic now works better if we filter orphans, then progressive, then
telecine interlaced fields which need to be woven and fall through to
interlace. Telecine interlaced fields will be regularly deinterlaced if
there is no pattern lock for us to be sure that we have a telecine
pattern.
Telecine sequences that aren't 24fps progressive with RFF flags can't
really be tested until fieldanalysis is ported.
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.
We use -DG_DISABLE_ASSERT for the pre-releases, which makes these
warnings pop up in cases that were previously covered by g_assert_not_reached()
and the like:
tvtime/greedyh.c:801:14: warning: 'scanline' may be used uninitialized in this function
matroska-mux.c:501:19: warning: 'context' may be used uninitialized in this function
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the needed Android.mk files.
Androgenizer can be found here: http://git.collabora.co.uk/?p=user/derek/androgenizer.git
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
Old code was difficult to understand exactly how the neighboring
scan lines are calculated, and it appeared that some were off by
+2 or -2, depending on the field flag. Fixes#639321.
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.
