Many video filters failed to calculate or even just pass through pts
values for their output frames. Fix this, and also make the two
remaining filters that called vf_next_put_image() twice for the same
input frame (vf_softpulldown, vf_telecine) use vf_queue_frame() so
that e.g. framestepping properly sees both frames.
Changed filters: vf_bmovl, vf_detc, vf_divtc, vf_filmdint, vf_ivtc,
vf_lavc, vf_phase, vf_pullup, vf_softpulldown, vf_telecine, vf_tile,
vf_tinterlace.
Change 'struct vf_instance' pointer arguments to more standard style
as in the subject. Also some other minor formatting fixes.
Patch by Diego Biurrun.
Note that r30455 is wrong, that commit does not in fact change the
default behavior as claimed in the commit message. It only breaks
"-af-adv force=0", which was already pretty much useless though.
This avoids clashes with fcntl.h under certain circumstances.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30680 b3059339-0415-0410-9bf9-f77b7e298cf2
When using libass with a VO that has direct EOSD support the vf_ass
video filter is unnecessary and is not added automatically, but the
code that adds the filter when it is needed produced misleading output
messages in this case. The following two messages were printed at
MSGL_ERR level, making it look like an error condition:
Couldn't open video filter 'ass'.
ASS: cannot add video filter
Add a version of vf_open_plugin() called vf_open_plugin_noerr() that
does not itself print an error message if opening a vf fails and that
returns the exact status code returned by the vf open() function. Make
vf_ass return a different status code depending on whether there was
an actual error or if it determined a filter would be redundant. Use
the _noerr function in the code adding the filter to avoid the first
message and check the status code to avoid the second.
Add a property to select YUV colorspace. Currently implemented only in
vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and
SMPTE-240M (vdpau only).
The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA
card supports that; I don't know whether other xv implementations do.
Bind the colorspace switch to the 'c' key by default. 'c' is currently
used by vo_sdl for some fullscreen mode change thing, but at the moment
that does not conflict and if it will in the future then vo_sdl can
change.
VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
Add interfaces to allow VO drivers to add or remove frames from the
video stream and to alter timestamps. Currently this functionality
only works with in correct-pts mode. Use the new functionality in
vo_vdpau to properly support frame-adding deinterlace modes.
Frames added by the VDPAU deinterlacing code are now properly timed.
Before every second frame was always shown immediately (probably next
monitor refresh) after the previous one, even if you were watching
things in slow motion, and framestepping didn't stop at them at all.
When seeking the deinterlace algorithm is no longer fed a mix of
frames from old and new positions.
As a side effect of the changes a problem with resize events was also
fixed. Resizing calls video_to_output_surface() to render the frame at
the new resolution, but before this function also changed the list of
history frames, so resizing could give an image different from the
original one, and also corrupt next frames due to them seeing the
wrong history. Now the function has no such side effects. There are
more resize-related problems though that will be fixed in a later
commit.
The deint_mpi[] list of reserved frames is increased from 2 to 3
entries for reasons related to the above. Having 2 entries is enough
when you initially get a new frame in draw_image() because then you'll
have those two entries plus the new one for a total of 3 (the code
relied on the oldest mpi implicitly staying reserved for the duration
of the call even after usage count was decreased). However if you want
to be able to reproduce the rendering outside draw_image(), relying on
the explicitly reserved list only, then it needs to store 3 entries.
are numbered and have a "in use" flag which is necessary for proper
buffer management as e.g. H.264 direct-rendering needs and is already used
successfully for the -vo vdpau work-in-progress.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28550 b3059339-0415-0410-9bf9-f77b7e298cf2
When OSD contents change while paused, try to change the OSD drawn in
the currently visible frame. If such OSD updates are not supported
then advance by one frame and draw the OSD normally. Add some support
for OSD redrawing to vo xv.
The new xv code makes a copy of the original frame contents before
drawing the OSD if MPlayer is already paused when the frame is drawn.
If such a copy of the current frame exists then the frame contents can
be restored and a different OSD drawn on top of the same frame.
This commit creates the struct and passes it to some functions that
needs to access OSD state but does not yet move much data from globals
to it.
vf_expand accesses the OSD state for rendering purposes outside of the
normal OSD draw time. The way this currently works is suboptimal, but
I did not attempt to clean it up now. To keep things working the same
way vf_expand needs to know the address of the state object to be able
to access the data even in the functions that should normally not need
it. For that purpose this commit adds a VFCTRL to tell vf_expand the
address of the object.
No call was made using this prototype directly so this just fixes
compiler warnings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21179 b3059339-0415-0410-9bf9-f77b7e298cf2
(cehoyos [at] rainbow studorg tuwien ac at) with small modifications
by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@20989 b3059339-0415-0410-9bf9-f77b7e298cf2
This mode has the following differences:
- Video timing is correct for streams with B frames, at least with some
demuxers.
- Video filters can modify frame timestamps and insert new frames, and
removing frames is handled better than before.
- Some things are known to break, it's not usable as the default yet.
Things should work as before when the -correct-pts option is not used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18922 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
- do not uninitialize video encoder between files
- checks for image size & format change moved from mencoder.c to vfilters
by Oded Shimon <ods15@ods15.dyndns.org>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14879 b3059339-0415-0410-9bf9-f77b7e298cf2
frames that will be skipped, mencoded tells vf_softskip (if present)
that it should drop the next frame. this allows filters that need to
see every input frame (inverse telecine, denoise3d, ...) to see
skipped frames before they get dropped.
in principle, a smarter softskip filter could be written that would
buffer frames and choose to drop the one with least change, rather
than strictly dropping the next one.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12338 b3059339-0415-0410-9bf9-f77b7e298cf2
when the following filter/vo doesn't support slices. also use unified
vf->dmpi rather than having vf->priv->dmpi duplicated in every filter.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@10141 b3059339-0415-0410-9bf9-f77b7e298cf2
Syntax is we decided, so you can give the nomes or not with both
vop and vf. vf take precedence over vop.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9594 b3059339-0415-0410-9bf9-f77b7e298cf2
