colorspace input supported for now. Autocropping is also not implemented.
Example usage: mplayer -vo zr2 -vf zrmjpeg foo.avi.
vf_zrmjpeg and vo_zr2 should obsolete vo_zr and libvo/jpeg_enc.c in the future.
Problem is that it needs some paramters of the zoran card (max resolution), for
now the user needs to tell vf_zrmjpeg those parameters (which is stupid,
because zrmjpeg should be able to query vo_zr2 for that information....) The
filter currently uses code which is also present in libvo/jpeg_enc.c, in the
future the (then enhanced) ffmpeg mjpeg encoder should/will be used.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11663 b3059339-0415-0410-9bf9-f77b7e298cf2
duplicating lines. ilpack will no longer significantly harm
progressive content, so it can be used on mixed
interlaced+progressive.
mmx interpolation code coming soon...
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11644 b3059339-0415-0410-9bf9-f77b7e298cf2
simplify logic
eliminate stupid alternative affinity calculations (gave bad results)
favor output of clean duration-3 over duration-2 plus broken-1
(will give a more steady 3:2 pattern during telecine, w/ no quality loss)
options to adjust strictness of tests (but no way to set them presently :)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11642 b3059339-0415-0410-9bf9-f77b7e298cf2
different source frames -- is there a better way?) so that
postprocessing can be used afterwards.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11630 b3059339-0415-0410-9bf9-f77b7e298cf2
frames in output. this will make it easier for the caller to do timing
or framerate regulation.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11629 b3059339-0415-0410-9bf9-f77b7e298cf2
The filmdint filter does not handle NTSC "telecined" 15fps movies
where there is a frame break in the middle of every second NTSC frame,
it outputs only 15 frames for every 30 input frames, ignoring the io
option. You can notice this during encoding such a sequence you will
have lots of diplicate frames / skip frames messages. The patch below
fixes this.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11624 b3059339-0415-0410-9bf9-f77b7e298cf2
uncovered while trying to send sound to a remote esd server over a
wireless (11 mbs, just enough to handle to sound) link.
First, the sound was full "ticking" sounds. I found a bug that
prevented the "send the remainder of this block" code from ever being
called - so large chunks of audio were simply being ignored. Fixing
this bug removed the "ticking" from audio streams.
Fixing this bug, however, uncovered another problem - when the socket
buffer was full, doing a blocking write to finish the buffer would take
far too long and would turn video into a chunky mess. I'd imagine this
blocking write would be fine for an audio-only stream, but it turns out
to hold up the video far too much.
The solution in this patch is to write as much data as possible to the
socket, and then return as soon as possible, reporting the number of
bytes actually written accurately back to mplayer. I've tested it on
both local and remote esd servers, and it works well.
Patch by Benjamin Osheroff <ben@gimbo.net>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@11620 b3059339-0415-0410-9bf9-f77b7e298cf2
rik
nicolas
paszczi
attila
rtognimp
wight
henry
faust3
pontscho
colin
diego
michael
mosu
rfelker
lumag
alex
nauj27