[PATCH] sse2 version of greedy2frame deinterlacer

Hi,

here's the updated greedy2frame sse2 patch. In contrast to the first try
I've now made it fall back to the mmxext path when alignment
restrictions aren't met (I've also renamed that old path from sse as
it's really mmxext not sse). Thanks to Petri it also initializes the xmm
variables in a much less crappy way...
I couldn't quite reuse the old template, I'm sure there's some clever
way to reuse the same assembly for mmx and sse2 (the ffmpeg guys do that
for instance) but that's the way it is now.
btw performance results are intersting, on a c2d-class chip the
performance increase was little more than statistical noise (maybe 2%
overall including h264 decode), despite that this chip can execute the
arithmetic really twice as fast thanks to 128bit simd units (it indeed
clearly executed less instructions).
On a Athlon64 X2 the performance increase was much more substantial (25%
or so for deinterlacer alone), even though this chip doesn't gain
anything really from using sse2 over mmx (due to its 64bit simd units) -
all the difference came from incorporating the separate line copy loop
into the inline assembly and the prefetch instructions (slightly more
improvement from the former than the latter). Of course that could be
done for the mmx path too but I'm not sure how some older cpus would
react to that - apparently on a c2d it makes no difference anyway (I'm
quite sure the prefetch instructions are just a total waste there for
these simple patterns the hw prefetcher is more than adequate on that chip).
So on a c2d things are limited by memory bandwidth it seems. Might be
more of an improvement on chips which have both 128bit simd units AND a
fast memory interface (like Nehalem, Sandy Bridge, possibly Barcelona,
Bulldozer).

[PATCH][RFC] Run deinterlacer and decoder in separate threads

Hello,

Attached patch runs deinterlacer (tvtime plugin) and video decoder in
separate threads.

It could be further improved by splitting deinterlacing to multiple
threads, for example:
 - pipelining: color space conversion, pulldown detection,
deinterlacing, chroma filter, ...
 - processing frames in slices

Usage:
xine --post tvtime:threads=1

Not deeply tested ...

- Petri

diff --git a/src/post/deinterlace/xine_plugin.c b/src/post/deinterlace/xine_plugin.c
--- a/src/post/deinterlace/xine_plugin.c
+++ b/src/post/deinterlace/xine_plugin.c
@@ -31,6 +31,8 @@
 #define LOG
 */

+#define XINE_ENGINE_INTERNAL  /* non-blocking ticket release */
+
 #include <xine/xine_internal.h>
 #include <xine/post.h>

Xine-lib 1.2 and Windows

Hello friends,
some time ago I tried to download the latest xine-lib 1.2 and I discovered 
that support for Windows was completely broken.
So, I would like to know if Windows platform must be still considered as 
supported and it just needs a bit of maintenance, or it must be assumed as 
unsupported from now.
In the meanwhile, I attached a patch with a selection of small and safe fixes 
that I implemented for making working xine-lib 1.2 on Windows:

"weak" attribute may be not supported, so I implemented these fixes in these 
files:
* __attribute__((weak)) has been replaced with XINE_WEAK macro into xine.h
* In xine/attributes.h, the conditional declaration of XINE_WEAK macro has 
been implemented.
* In m4/attributes.m4, the function CC_ATTRIBUTE_WEAK has been implemented.
* In configure.ac, the CC_ATTRIBUTE_WEAK function has been called.

In configure.ac, I added the presence check of some include files:
pwd.h
unistd.h (it's available in MINGW but it is not into MSVC)
sys/socket.h
netinet/in.h
arpa/inet.h
These diagnostics will be useful for future changes.

lib/hstrerror.c failed to compile because an include path seems wrong.
The file to include is "xine/xineintl.h" and not "xineintl.h".

libdvdnav failed to compile and I got a makefile error of "missing separator".
In src/input/libdvdnav/Makefile.am, the source name "dvd_udf.c" is preceeded 

OpenGL 2.0 vo driver

Hi all,

I've recently used an ati videocard and found that XV support is .. well 
.. not so good :)
So, i've gone for opengl, and found that this one is quite limited.
I've then written an OpenGL 2.0 video out plugin.
It of course requires an OGL2 GPU/driver. It should gracefully fail to 
open if requirements aren't met.
(ARB_texture_rectangle, ARB_texture_non_power_of_two, 
ARB_pixel_buffer_object, ARB_framebuffer_object, ARB_fragment_shader)

It supports the following features:

- Color Space Conversion (YV12 and YUY2)
- Crop, Zoom
- Scaled and Unscaled overlays
- Hue, Saturation, Contrast, Brightness
- Sharpness
- Bicubic scaling

-- Christophe Thommeret

diff -r 3c08d65400c4 src/video_out/Makefile.am
--- a/src/video_out/Makefile.am	Thu Apr 19 09:43:05 2012 +0300
+++ b/src/video_out/Makefile.am	Thu May 10 14:14:18 2012 +0200
 <at>  <at>  -30,6 +30,7  <at>  <at> 
 endif
 if ENABLE_OPENGL
 opengl_module = xineplug_vo_out_opengl.la

RFC: inline assembly for alphablend functions

Hi,

xine's alphablend functions are terrible cpu hogs (in particular with hd
streams). I was wondering if it would be worthwile to improve things a
bit with simd instructions. I started with mem_blend32 because that's a
natural fit for mmx without touching anything else (and because this
itself uses a lot of time with yuy2 blending). Seems to work and reduce
executed instructions a lot though only on a K8 do I see any performance
improvement (the thing is once again heavily limited by memory
bandwidth). Of course it does exactly nothing unless you have
video.output.disable_exact_alphablend set. The code is also compiled and
executed unconditionally which obviously would need to change.
I guess there would be more of an improvement with the exact blend
function (looks a bit less limited by memory bandwidth) but that's
definitely much more work.
So what do you think?

Roland

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH] Include arpa/inet.h for htons in src/audio_dec/xine_lpcm_decoder.c

$subject + commit message

# HG changeset patch
# User Alexis Ballier <aballier <at> gentoo.org>
# Date 1335036489 10800
# Node ID 6fc56571c45a09d42829624a0d6339f3ad0f6168
# Parent  3c08d65400c4915891d8b8b18f21c5f0326537b0
Include arpa/inet.h for htons.

See http://pubs.opengroup.org/onlinepubs/9699919799/functions/htonl.html
Fixes build on FreeBSD.

diff -r 3c08d65400c4 -r 6fc56571c45a src/audio_dec/xine_lpcm_decoder.c
--- a/src/audio_dec/xine_lpcm_decoder.c	Thu Apr 19 09:43:05 2012 +0300
+++ b/src/audio_dec/xine_lpcm_decoder.c	Sat Apr 21 16:28:09 2012 -0300
@@ -41,6 +41,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
+#include <arpa/inet.h> /* htons */
 #include <netinet/in.h> /* ntohs */

 #include <xine/xine_internal.h>

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Xine seriously hates the Thor DVD - libdvdread needs refreshing.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
xine-devel mailing list
xine-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel

xine drops most of the frames from deinterlaced video when using opengl output

Recently, I had to switch from xv output to opengl, because Intel's 
sandybridge integrated graphics lacks vsync support for xv. 
Unfortunately, there is some problem with opengl output when tvtime 
deinterlacing is used. Most of the frames are dropped and the video is 
unwatchable.

Steps to reproduce are simple:
- download http://www.w6rz.net/vertrezmotion.zip
- run
   xine -V opengl \
      --post

tvtime:method=Greedy2Frame,enable=1,cheap=0,chroma_filter=0,pulldown=none,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1 
\
      --post pp:quality=0 \
      vertrezmotion.ts

If I use xv instead of opengl then everything works fine (except the 
tearing caused by missing vsync).

CPU usage is minimal. I've added a logging of frames_to_skip to function 
vo_frame_draw() in video_out.c. In case of xv output it settles around 
-14 after a while. And in case of opengl it oscillates between ca. -10 
and 24. Does anybody have an idea what could be wrong?

Michal

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

RFC

Please do comment my latest 2 patches in
mmx_precise_color and rgb_color_range_fix.

I'm new to mmx assembly. I used to code m68k Amiga assembly before :)

Thank you,

Torsten

--

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Regression playing MOV files with xine-1.1.21

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
xine-devel mailing list
xine-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel

Re: vdpau development

On Tue, 2012-04-10 at 12:39 -0700, VDR User wrote:

> On Tue, Apr 10, 2012 at 11:34 AM, Brent Shellenberg <brent <at> starmont.ca> wrote:
> >
> > I understand that vdpau support in xine is in its early days. Are there
> > particular developers working on it, or perhaps a developer on the list
> > that would be working on it (testing) if hardware was available?
> 
> VDPAU has been working for well over a year and a half. There are
> currently two implementations to choose from. Both work well in my
> experience, and I know many others who will say the same.
> 
> Do you have a specific problem or something?

I do. When viewing an image (a png) I get discoloured bands across the
image. The image detail is correct, but the colouring is wrong. I put in
a bug report about it. Works fine prior to libxine that didn't have
vdpau support (using opengl for output is still good, as an example) so
it's confined to vdpau. I can provide a quick  piece of test code and/or
media for this. It replicates on all nvidia hardware I've tried.

--

-- 
Brent Shellenberg
- Starmont Media Services Inc.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev