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