http://blog.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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 http://comments.gmane.org/gmane.comp.video.xine.devel/19164 <pre>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 </pre> Torsten Jager 2012-04-13T17:45:03 http://comments.gmane.org/gmane.comp.video.xine.devel/19163 <pre>Hi, The following commit is breaking MOV playback for me, e.g. "The Hobbit" trailer: changeset:   10340:2a87c8b39a0a user:        Torsten Jager &lt;t.jager&lt; at &gt;gmx.de&gt; date:        Tue Feb 28 22:25:40 2012 +0000 files:       src/demuxers/demux_qt.c description: Made demux_ts send pts not dts even for reordered (b-framed) video. This fixes a very old bug causing more or less unpredictable a/v lag. You can download the particular MOV file that I am using with this command: $ wget -U QuickTime/7.6.2 http://trailers.apple.com/movies/wb/thehobbit1/thehobbit-tlr1_h720p.mov My test box is x86_64 Fedora 16. 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 htt</pre> Chris Rankin 2012-04-12T21:38:29 http://comments.gmane.org/gmane.comp.video.xine.devel/19156 <pre> 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? ------------------------------------------------------------------------------ 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> Brent Shellenberg 2012-04-10T18:34:23 http://comments.gmane.org/gmane.comp.video.xine.devel/19153 <pre>Hi, ok software deinterlacers may be a bit out of fashion these days (with hw decoding...) but nevertheless I was playing with that a bit as greedy2frame was too slow for me (with h.264 full hd streams). So first thing I did was convert it to use sse2 instead of mmx. Not quite unexpectedly it didn't actually help performance (for two reasons, one is the algorithm is nearly completely memory bandwidth bound, and second even if it wouldn't be memory bandwidth bound the cpu in question is a K8 which has only 64bit wide simd units anyway). Still, I think it's about time to use sse2. However, a big problem I encountered was there seems to be absolutely no guarantee about ANY alignment of either source or destination images. This is ok for mmx which doesn't require any alignment (though performance might suck if things aren't quite 64bit aligned) but is a problem for sse which requires 128bit aligned addresses. Loading the images from memory could be made to work with movdqu instead of movdqa (which wasn't much o</pre> Roland Scheidegger 2012-04-10T00:54:05 http://comments.gmane.org/gmane.comp.video.xine.devel/19152 <pre>Cuts roughly 10% of the instructions (with sse), results should be identical. Not sure why it was that complicated in the first place, the simplification is possible because the code gave a score of 1 to top and bottom comparisons, and 2 for the middle one, and weaved when all scores added together were more than 2. This is equivalent to weave when (cmp(m) AND (cmp(b) OR cmp(t))) which is a much better match for the available hw instructions. This also reduces the number of constant loads a lot, and the patch moves up some memory loads a bit which can never hurt. Doesn't make much of a performance difference (memory bandwidth bound) but looks nicer nonetheless. Roland ------------------------------------------------------------------------------ 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_______________________________________________ xine-devel mailing list</pre> Roland Scheidegger 2012-04-10T00:16:03 http://comments.gmane.org/gmane.comp.video.xine.devel/19151 <pre>Missed the availability of pavgb instruction last time (since the code required mmxext anyway) which is VERY useful. Cuts down assembly instructions nearly in half (and makes it completely memory bound again, the performance improvement is less than 10% here). Keep the old version fixed to work with mmx only if that's still useful. This code should also do better rounding (not 100% correct but better than the old code which did truncation), and is also changed to use the same assembly for both odd and even lines (as a simple argument swap is all that's needed). ------------------------------------------------------------------------------ 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> Roland Scheidegger 2012-04-09T23:55:21 http://comments.gmane.org/gmane.comp.video.xine.devel/19150 <pre>I've taken xinimin.c and added seek and osd functionality. The last big piece that I need to implement is deinterlacing, however, I'm finding very little documentation. I've been through the hacker's guide and of course I haved googled and googled. I found the deprecated method: xine_set_param(stream, XINE_PARAM_VO_DEINTERLACE, 1); which did not work. I saw that the current method involves post plugins, but my /usr/include/xine/post.h doesn't have the word deinterlace in it. Can anyone provide an example of how to implement deinterlacing. It would be nice to have the flexibility down the road to change the deinterlacer, but something equivalent to the -D option on the command line is what I'm looking for to start with. Is there a good resource for example source files? Thanks, John ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monit</pre> John Lips 2012-04-03T04:09:40 http://comments.gmane.org/gmane.comp.video.xine.devel/19147 <pre> Hello, I was playing around with a custom post plugin. It is running under version 1.1.19. The problem I'm having is that although it returns a non-zero value from it's init function, xine complains: load_plugins: post plugin lastpts failed to instantiate itself load_plugins: no post plugin named lastpts found The pertinent code from the plugin is: typedef struct lastpts_class_s { post_class_t post_class; xine_t *xine; }lastpts_class_t; void *lastpts_init_plugin(xine_t *xine, void *data) { xine_log(xine, XINE_LOG_PLUGIN, "Trying to init plugin here!\n"); lastpts_class_t *xineplug = (lastpts_class_t *) calloc(1, sizeof(lastpts_class_t)); xineplug-&gt;xine = xine; xineplug-&gt;post_class.open_plugin = lastpts_open_plugin; xineplug-&gt;post_class.get_identifier = get_identifier; xineplug-&gt;post_class.get_description = get_description; xineplug-&gt;post_class.dispose = lastpts_class_dispose; xine_log(xine, XINE_LOG_PLUGIN, "Returned %p from init plugin!\n", (void *</pre> tony speed 2012-03-13T19:58:01 http://comments.gmane.org/gmane.comp.video.xine.devel/19146 <pre>Dealing with rgb_color_range_fix I found another oddity. yuv2rgb_mmx.c scales YUV and rounds them down to 8 bits individually before the addition. That causes red and blue to be off by up to 2, green even off by 3. This little patch does the stuff using 10 bits per component, plus correct rounding. There seems to be no noticable impact on performance, but color gradients come out much smoother now. See attached test video (with vo_xshm or opengl). BTW. The same issue applies to the portable c version too but Im still looking for a reasonable fast way. Torsten </pre> Torsten Jager 2012-03-13T14:50:42 http://comments.gmane.org/gmane.comp.video.xine.devel/19144 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There is a bug in xine that's been bothering me for years! Here's the fix. The atitle buffer is copied with strdup(). This is fine and the strlcpy is careful not to exceed the size of the buffer. The problem is we calculate the size of the atitle string, not the size of the buffer. Regards Erik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ZftsACgkQY21D/n6bGwdgvgCfVGgEBae5WG7jOjPyLKXk/P/R kgMAn2LnMdxNUb0NpZAqjUN/A3+JkDR6 =pdEl -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Virtualization &amp; Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/_______________________________________________ xine-devel mailing list xine-devel&lt; at &gt;lists.s</pre> Erik Lotspeich 2012-03-09T03:54:03 http://comments.gmane.org/gmane.comp.video.xine.devel/19141 <pre>Hi guys ! Thanks for the good work so far ! The bug tracker seems down so I contact you directly through this mailing list. Recent versions of xine do not play ts files recorded from DVB-T adapter (using tzap command and grabbing content at /dev/dvb/adapter1/dvr0 ). It is working well with the 1.1.16.3 compiled from source and this now fails with 1.1.20.1 (for the same file). I suspect that this is due to modifiction of the ts demux, for stream that does not include PAT/PMT. (from the archive : http://old.nabble.com/Demuxing-an-MPEG-TS---descriptor- tag--td32315051.html) However, I don't know how to check that it really is the cause of my problem... Is there some black magic to get this working again (MRL parameter, ...) Or is there any chance of having this working again ? Thanks Ludovic video_decoder: can't raise nice priority by 1: Opération non permise video_out: can't raise nice priority by 2: Opération non permise video_decoder: can't raise nice priority by 1: Opération non permi</pre> pludov 2012-02-16T09:51:21 http://comments.gmane.org/gmane.comp.video.xine.devel/19140 <pre>Fixed a very old bug causing more or less unpredictable a/v lag. Made demux_ts send pts not dts even for reordered (b-framed) video. Torsten </pre> Torsten Jager 2012-02-18T16:27:06 http://comments.gmane.org/gmane.comp.video.xine.devel/19138 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Now that virtually all CDDA playing is done via digital audio extraction (vs analog audio), I have yet to find a player that works exactly like a "real" CD player. Xine is my CDDA player of choice and I'd like to help improve it. I've noticed three areas that need improvement: 1. Read CD-Text, if available, and prefer it to the (often dubious) CDDB information 2. Properly handle pre-gap 3. Eliminate the slight "pause" between tracks I've poked around a bit in the source and I see some CD-Text handling in the VCD plug-in, but not in (what I think is) the CDDA plug-in (input_cdda.c). I don't want to duplicate efforts, but I'd like to help code these improvements. Any pointers would be appreciated. I don't have all that much free time, but I'll contribute what I can. Regards Erik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk88cWEACgkQY21D/n6bGwdxRACeMbJ</pre> Erik Lotspeich 2012-02-16T03:00:49 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.xine.devel