http://permalink.gmane.org/gmane.comp.video.xine.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.xine.devel/19187 <pre>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 </pre> Roland Scheidegger 2012-05-18T01:10:38 http://permalink.gmane.org/gmane.comp.video.xine.devel/19186 <pre> Most of the problem disks I run into are rentals which I do not own. Of course you get defective disks but I am talking about disks which play perfectly on my hardware DVD player and usually on other software. You must have a rental operation somewhere so that you could get copies to test. The most common problem is that the on-disk menu does not work so you can't get at the content. I do find some that crash the program when it tries to play the main content and others that fail to open the disk, usually producing a "Cannot Decode" error. The DVD of the movie "Thor" will not open in any of the software I tried (I did not try Totem) but played perfectly on my old Sony box. It is a pretty sorry movie but looks like it might be a good debugging tool. It may have intentional errors intended to act as a copy protection scheme. Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's se</pre> Michael Hughes 2012-05-16T02:03:27 http://permalink.gmane.org/gmane.comp.video.xine.devel/19185 <pre>I do at least know that this particular DVD is not faulty, having watched it successfully in totem. ________________________________ From: James &lt;James&lt; at &gt;superbug.co.uk&gt; To: xine-devel&lt; at &gt;lists.sourceforge.net Sent: Tuesday, 15 May 2012, 11:14 Subject: Re: [xine-devel] Xine seriously hates the Thor DVD - libdvdread needs refreshing. On 20/04/12 14:32, Chris Rankin wrote: I suspect that xine produces an error message because its internal libdvdnav doesn't have the unicodes fixes. Once I add those fixes, xine fails more mysteriously. simply crash error message! episode disks work on would be benefit of about enough of this but I The only reliable way to fix this is to send a copy of the problem DVD to the developer, i.e. me. I have not come across a DVD that xine cannot play recently. xine does not currently support damaged DVDs. I.e. Ones with sector errors. For proper support of damaged DVDs, li</pre> Chris Rankin 2012-05-15T23:22:42 http://permalink.gmane.org/gmane.comp.video.xine.devel/19184 <pre>Didn't do any testing but I like the idea. I think though if the decoder already does threaded decoding this (like h.264 though I'm sometimes still seeing some trouble with that) won't really do much right? I am not convinced that using threads for csc, pulldown, deinterlacing, chroma filter is really the right way going forward. What makes these operations slow is the memory traversal so handling them all at once would make things way faster (in case of csc and deinterlacing it would also increase the chroma quality a lot for combined deinterlace/csc at least for deinterlacers doing bob/weave based on content, which means you'd most likely would want to throw out the not terribly useful chroma filter anyway for such setups so not much would be left for additional threads...). Can't say much about pulldown, as currently it is totally useless in a 50Hz world (not once in your lifetime will you see 3:2 pulldown which is the only thing it can handle), I guess though it might not really be worth using a separate</pre> Roland Scheidegger 2012-05-15T22:59:07 http://permalink.gmane.org/gmane.comp.video.xine.devel/19183 <pre>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 ------------------------------------------------------------------------------ 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/_______________________________________________ xine-devel mailing list xine-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xine-devel </pre> Petri Hintukainen 2012-05-15T12:13:15 http://permalink.gmane.org/gmane.comp.video.xine.devel/19182 <pre> The only reliable way to fix this is to send a copy of the problem DVD to the developer, i.e. me. I have not come across a DVD that xine cannot play recently. xine does not currently support damaged DVDs. I.e. Ones with sector errors. For proper support of damaged DVDs, libdvdnav requires a lot of work, and I don't have time for that currently, but I should have enough time to get a single problem DVD to play. Kind Regards James ------------------------------------------------------------------------------ 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/_______________________________________________ xine-devel mailing list xine-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xine-devel </pre> James 2012-05-15T10:14:07 http://permalink.gmane.org/gmane.comp.video.xine.devel/19181 <pre>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 T</pre> carlo.bramix< at >libero.it 2012-05-12T21:46:32 http://permalink.gmane.org/gmane.comp.video.xine.devel/19180 <pre>Am 10.05.2012 14:36, schrieb Christophe Thommeret: I dunno looks ok to me (with opensource driver). Granted it has its limitations but you can manage do vsync for instance (but only if you disable any compositors). In any case XV still seems to be lowest overhead which is very important for my box :-). Indeed. No packed yuv for one, hence no overlays... Do you actually require ARB_texture_non_power_of_two? I looked over it and you seem to use texture rectangles only. I like the idea though I wonder if it wouldn't be nice if things could be done in one pass. I'm fairly certain that my poor gpu has no chance of doing it in realtime with two passes :-). At least for the basic stuff (that is csc for vy12/yuy2, overlays, hue/sat/cont/brightness adjustments, and bilinear filtering). Also does the video PBO actually help? The texture data needs to be copied anyway, so what does this achieve? Roland ------------------------------------------------------------------------------ Live Security Virtual Conferenc</pre> Roland Scheidegger 2012-05-10T14:27:11 http://permalink.gmane.org/gmane.comp.video.xine.devel/19179 <pre>Hi Christophe, I'm experiencing a deadlock when using this opengl2 output. Below is the backtrace. Threads 1,15 and 17 are blocked. Does anybody have an idea what could be wrong? This is not necessarily related to your patch, since I remember that I had a similar problem with vdr-xineliboutput. That one was caused by hiding the mouse cursor. Instead of solving it properly I simply commented out the code that hides the cursor. Thanks for any help, Michal (gdb) t a a bt Thread 18 (Thread 0x7fbe4d593700 (LWP 15422)): #0 pthread_cond_timedwait&lt; at &gt;&lt; at &gt;GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 #1 0x00000000004838e8 in _tips_loop_thread (data=&lt;value optimized out&gt;) at tips.c:84 #2 0x0000003b54406ccb in start_thread (arg=0x7fbe4d593700) at pthread_create.c:301 #3 0x0000003b538e0c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 Thread 17 (Thread 0x7fbe4cd92700 (LWP 15423)): #0 pthread_cond_wait&lt; at &gt;&lt; at &gt;GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux</pre> Michal Novotny 2012-05-10T13:15:11 http://permalink.gmane.org/gmane.comp.video.xine.devel/19178 <pre>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 </pre> Christophe Thommeret 2012-05-10T12:36:08 http://permalink.gmane.org/gmane.comp.video.xine.devel/19177 <pre>Am 26.04.2012 11:26, schrieb Petri Hintukainen: Oh very nice. That stuff is old? Certainly better than my crude mem_blend32 attempt which failed to even recognize that it isn't necessary to reload src (but even then it was like 3 times less instructions in the loop than the c code). Still, it doesn't have y yuy2_exact mmx version, which is the one I'd really want :-). But I guess that needs different organization of line buffer to make it useful (I was also wondering if it wouldn't be easier if the y values would be just stored in the line buffer too and then one loop could blend both y and chroma values - not sure though.) 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/sfrnl0424201</pre> Roland Scheidegger 2012-04-26T15:42:09 http://permalink.gmane.org/gmane.comp.video.xine.devel/19176 <pre> Check http://anonscm.debian.org/hg/xine-lib/playgrounds/xine-lib-1.2-mpz/ I recently made some benchmarks with alphablending code. Simplifying blending functions resulted in ~50% speedup with quite minimal effort. To avoid lot of code duplication, hacks and so on some minor changes to alphablending API would be useful... Darren, should we branch 1.3 ? :) DVD clipping areas are checked very often for all kind of overlays. This could be done only once and only when clipping area is used. We could combine palettes so that first 256 entries are "normal" and next 256 for clipping area. Then we could simply modify palette indexes in compressed image by setting higher byte to 1 or 0 based on clipping area. This way blending functions and video drivers won't need to know anything about clipping areas. RLE could be re-generated when overlay changes or video size changes. This would eliminate checks for blending outside of dest image. At same time RLE elements could be breaked at end of each line (and at clipping</pre> Petri Hintukainen 2012-04-26T09:26:49 http://permalink.gmane.org/gmane.comp.video.xine.devel/19175 <pre>Forgot the attachment... Am 25.04.2012 21:00, schrieb Roland Scheidegger: ------------------------------------------------------------------------------ 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/_______________________________________________ xine-devel mailing list xine-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xine-devel </pre> Roland Scheidegger 2012-04-25T19:01:17 http://permalink.gmane.org/gmane.comp.video.xine.devel/19174 <pre>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 wi</pre> Roland Scheidegger 2012-04-25T19:00:26 http://permalink.gmane.org/gmane.comp.video.xine.devel/19173 <pre>$subject + commit message------------------------------------------------------------------------------ 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&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xine-devel </pre> Alexis Ballier 2012-04-21T19:30:12 http://permalink.gmane.org/gmane.comp.video.xine.devel/19172 <pre>I suspect that xine produces an error message because its internal libdvdnav doesn't have the unicodes fixes. Once I add those fixes, xine fails more mysteriously. Cheers, Chris ________________________________ From: Michael Hughes &lt;marynya&lt; at &gt;compuserve.com&gt; To: xine-devel&lt; at &gt;lists.sourceforge.net Sent: Friday, 20 April 2012, 13:56 Subject: Re: [xine-devel] Xine seriously hates the Thor DVD - libdvdread needs refreshing. MythTV dumps you back to the menus while MPlayer and VLC simply crash when you try to open the disk.  At least Xine produces an error message! There are actually quite a lot of commercial movie and TV episode disks which do not play for various reasons.  I am not prepared to work on that part of the code at the present time but I wonder if it would be worth posting references to disks which do not play for the benefit of the people working in that area.  Perhaps they already know about enough disks to keep them busy.  I should have been keeping a log of this but I haven't. Mi</pre> Chris Rankin 2012-04-20T13:32:41 http://permalink.gmane.org/gmane.comp.video.xine.devel/19171 <pre>MythTV dumps you back to the menus while MPlayer and VLC simply crash when you try to open the disk. At least Xine produces an error message! There are actually quite a lot of commercial movie and TV episode disks which do not play for various reasons. I am not prepared to work on that part of the code at the present time but I wonder if it would be worth posting references to disks which do not play for the benefit of the people working in that area. Perhaps they already know about enough disks to keep them busy. I should have been keeping a log of this but I haven't. Mike ------------------------------------------------------------------------------ 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 </pre> Michael Hughes 2012-04-20T12:56:34 http://permalink.gmane.org/gmane.comp.video.xine.devel/19170 <pre>So I stupidly went and bought the Thor DVD... This DVD has a garbage file with an invalid unicode name that pretends to be VIDEO_TS.IFO. Up-to-date versions of libdvdread know to ignore it, but xine's internal libdvdread is too old. Unfortunately, this isn't the end of the story either. I recompiled xine 1.1.21 against libdvdread/libdvdnav 4.2 but the DVD still wouldn't play. It plays in Totem though, despite complaining about a missing subpicture decoder plugin. So a refresh of libdvdnav would seem like a good starting place, but I suspect that there's a problem with xine's DVD plugin too. Cheers, Chris ------------------------------------------------------------------------------ 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&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/li</pre> Chris Rankin 2012-04-19T23:57:47 http://permalink.gmane.org/gmane.comp.video.xine.devel/19169 <pre> That's actually the reason why I added "--post pp:quality=0" after the deinterlacer. It converts yuy2 to yv12, which can be handled by 2D_Tex_Fragprog renderer. Otherwise 2D_Tex renderer would be used which converts yuy2 frame to rgb in opengl_frame_proc_slice() and this is really slow. ------------------------------------------------------------------------------ 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 </pre> Michal 2012-04-17T22:25:45 http://permalink.gmane.org/gmane.comp.video.xine.devel/19168 <pre>Le 17/04/2012 13:48, Michal a écrit : The old opengl output driver's FragProg method does not support yuy2. TVTime deinterlacer converts frames to yuy2 format, unless cheap_mode is set to 1. That might be the problem. ------------------------------------------------------------------------------ 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 </pre> Christophe Thommeret 2012-04-17T20:42:53 http://permalink.gmane.org/gmane.comp.video.xine.devel/19167 <pre>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 --------------------------------</pre> Michal 2012-04-17T11:48:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.xine.devel