[FFmpeg-devel] [PATCH] FFmpeg: libavfilter/libmpcodecs: add vf_stereo3d high quality green-magenta and yellow-blue dubois anaglyph 3D output support

[thomas schorpp]

On 30.01.2013 19:45, Michael Niedermayer wrote:
> 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.H[2]SBS[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).
>>>>
>>>> y
>>>> tom
>>>>
>>>> ---------------
>>>>
>>>> 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)

Yes, I've taken the mplayer(1) version as base because it was the latest codebase but with errors (incomplete YB Anaglyph case handling).

>
>
>>
>> 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

schorpp at tom3:~$ du -sch .ccache
337M	.ccache
$ df -h |grep data
/dev/sda4              28G   23G  3,2G  88% /mnt/data

and someone should fix
CCACHE_DIR
            The CCACHE_DIR environment variable specifies where ccache will keep its cached compiler output. The default is $HOME/.ccache.

or invent a config file or do all of You have got workgroup servers running at home?

It's no very user friendly having "surprises" like hidden caches growing in $HOME, do this in the WD.

I can't consider that off topic if You recommend it for new FFmpeg developers.

>
>
>>
>> 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
> possible
>
> [...]
>

Affirmative and in progess, see my last mail.

y
tom