Commit bd27a1f30b added a few error handling
memory management checks. These check srccaps to see if it needs to be
unreferenced before returning, in the case of invalid_caps this goto jump
always happens before srccaps is set, so it will always be NULL in this
error label.
CID #1352035
If the following conditions are met:
1) upstream and downstream caps are compatible
2) upstream is interlaced
3) downstream doesn't support progressive mode
then deinterlace will just do passthrough instead of failing to link.
This is done with the following scenario in mind:
videotestsrc ! "video/x-raw,interlace-mode=interleaved" ! deinterlace
name=dein_src ! tee name=t ! queue ! deinterlace name=dein_file ! filesink t. !
queue ! deinterlace name=dein_desktop ! autovideosink
In this case, dein_src will do the deinterlacing. However,
videotestsrc ! "video/x-raw,interlace-mode=interleaved" ! deinterlace
name=dein_src ! tee name=t ! queue ! deinterlace name=dein_file ! filesink t. !
queue ! deinterlace name=dein_desktop ! autovideosink t. ! queue !
"video/x-raw,interlace-mode=interleaved" ! fakesink
In this case, caps auto-negotiation will make dein_file and dein_desktop do
the deinterlacing, while dein_src will be passthrough.
https://bugzilla.gnome.org/show_bug.cgi?id=760995
In this mode we will passthrough all progressive caps but interlaced caps must be
caps where we actually support deinterlacing.
This is the only difference between auto and auto-strict, auto would
passthrough all unsupported interlaced caps.
https://bugzilla.gnome.org/show_bug.cgi?id=720388
Previously the result of the CAPS query and ACCEPT_CAPS depended on what kind
of caps were last set, and e.g. if we last had interlaced caps or not. That's
just broken.
Also previously the handling of non-sysmem caps features was rather random and
unusuable.
Now the behaviour is the following, depending on the mode property:
1) mode=disabled
Completely do passthrough of everything
2) mode=interlaced
Only accept formats we can actually deinterlace, and accept interlaced
and progressive content and always run the deinterlacer and output
progressive content
3) mode=auto (i.e. playbin)
Accept all progressive formats as passthrough, accept all formats that we
can deinterlace ourselves (which we do then), but also accept everything
else for which we then just passthrough. In auto mode, deinterlacing is best
effort: If we can, we deinterlace, if we can't we just output interlaced
content.
https://bugzilla.gnome.org/show_bug.cgi?id=720388https://bugzilla.gnome.org/show_bug.cgi?id=760553
Implement accept-caps handler to avoid doing a full caps query
downstream to handle it.
This commit implements accept-caps as a simplification of the _getcaps
function, so it exposes the same limitations that getcaps would.
For example, not accepting renegotiation to caps with capsfeatures when
it was last configured to a caps that it has to deinterlace.
In some cases the currently set GstVideoInfo is not interlaced, but
upstream caps are interlaced and the info is passed in the filter,
we should take that info into account and make sure that we do not
consider that case as a "pass through" case.
https://bugzilla.gnome.org/show_bug.cgi?id=741407
gstdeinterlace.c: In function 'gst_deinterlace_output_frame':
gstdeinterlace.c:1537:57: error: 'pattern.length' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This actually is always initialized before it is used there, but
let's just silence gcc here.
The code handles a -1 pattern index, and it seems plausible
that a pattern might be found later, so it seems best to not
send an element error here.
Coverity 1139766
This only affects behaviour in telecine cases with pattern locking
enabled. The default case should be untouched.
This works with the output from fieldanalysis at least, but the field
order looks swapped for telecine mixed buffers with the
David_slides_Schleef clip.
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
