[FFmpeg-devel] [PATCH] FFmpeg: libavfilter/libmpcodecs: add vf_stereo3d high quality green-magenta and yellow-blue dubois anaglyph 3D output support
michaelni at gmx.at
Wed Jan 30 19:45:24 CET 2013
On Wed, Jan 30, 2013 at 11:28:42AM +0100, thomas schorpp wrote:
> On 30.01.2013 01:04, Michael Niedermayer wrote:
> >On Tue, Jan 29, 2013 at 12:01:47PM +0100, thomas schorpp wrote:
> >>@#%&§! Thunderbird! Resent word wrapped.
> >>This patch brings ecological and economical "Transcode once at 100% CPU - view many at ~20% CPU load" 3D (H)SBS, etc, media
> >>to the most advanced (2007) green-magenta eyes friendly anaglyph 3D projection method support using Eric Dubois' high quality method
> >>for people who want to avoid expensive resources consumed by (nice trying) real time conversion stereoscopic media players at every playback
> >>or expensive special 3D displays and 3D TV sets with polariser/shutter/no glasses without DVI-D inputs and more restrictions
> >>accepted by only ~5% of western TV/video users until today.
> >>Red-cyan (1970,2001) dubois method has been already implemented by the original author, added -topic-.
> >>Usage example to transcode 3D HSBSR h.264 format to anaglyph green-magenta 3D in MPEG4
> >>(See source code for enum encoded stereo3d filter arguments, defaults to MPlayer2 "sbs2l:agmd" now):
> >>$ ffmpeg -i test.3D.HSBS[R].x264.mp4 -c:a copy -vf mp=stereo3d=17:7 -qscale:v 8 test.3D.agmd.sbs2r.mp4
> >>OpenGL MPlayer1/2 output is suggested for best color display results (i915/i965GM GPUs).
> >>libavfilter/libmpcodecs: add vf_stereo3d high quality green-magenta and yellow-blue dubois anaglyph 3D output support
> >>Signed-off-by: Thomas Schorpp <thomas.schorpp at gmail.com>
> >>-Att. patch
> >> vf_stereo3d.c | 62 ++++++++++++++++++++++++++++++++++++++++++----------------
> >> 1 file changed, 45 insertions(+), 17 deletions(-)
> >>fb37defbbc9e16391fd3745f11dbe46f46d603ce ffmpeg-mpvfstereo3d-agmd-schorpp01.patch
> >>--- a/libavfilter/libmpcodecs/vf_stereo3d.c
> >>+++ b/libavfilter/libmpcodecs/vf_stereo3d.c
> >libmpcodecs improvments should be submited to mplayer
> >and the backported to ffmpeg
> Done already and commited. See attachments. Or do You mean MPlayer(1)? I'm little confused of all this forking has gone on, is mplayer2(.org) uncooperative?
the libmpcodecs in ffmpeg where taken from mplayer(1)
> I've only preferred mplayer2(.org) first because of dynamic linking to FFmpeg, if I understood MPlayer(1) homepage right it still requires its own
> version of FFmpeg and needs to be linked statically against it and so rebuilds for crystalhd.c testing take long on my old machines, here, sorry for that.
off topic but I can recommand ccache & clang (or gcc with lower
optimization level) if compile time is an issue
> MPlayer(1) People, please go get it, I've got no objections from the original author yet.
> Any other issues against commit ?
no, i just would like to keep the libmpcodecs "forks" in sync if
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel