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
