From feifan.zhou at intel.com Tue Nov 1 07:20:41 2011 From: feifan.zhou at intel.com (Zhou, Feifan) Date: Tue, 1 Nov 2011 14:20:41 +0800 Subject: [MPlayer-dev-eng] mplayer with VAAPI Message-ID: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> Hi, The mplayer VAAPI branch server seems shutdown these days, do anybody know do the mail line want to merge the VAAPI patch to make the mplayer default support VAAPI? Ps: I have see some vaapi code in libavcodec, but leak the vaapi code in libvo. BRS Challen zhou From Dan.Oscarsson at tieto.com Tue Nov 1 07:59:00 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Tue, 01 Nov 2011 07:59:00 +0100 Subject: [MPlayer-dev-eng] [PATCH] Fix for fix for mpeg2 A/V sync bug. In-Reply-To: <4EA47978.2070701@unix-ag.uni-kl.de> References: <1319300723.4678.16.camel@luna.malmo.kicore.net> <4EA31C7D.5060809@unix-ag.uni-kl.de> <1319372964.4447.7.camel@luna.malmo.kicore.net> <4EA418BC.6070904@unix-ag.uni-kl.de> <1319393808.4447.15.camel@luna.malmo.kicore.net> <4EA47978.2070701@unix-ag.uni-kl.de> Message-ID: <1320130740.4798.2.camel@valinor.malmo.kicore.net> s?n 2011-10-23 klockan 22:30 +0200 skrev Erik Auerswald: > > Attached is a slightly changed version of my previous patch. Does it > > work better? > > Yes, it does indeed work better. Playback of the DVD mentioned above > works fine, I see no difference with or without your second patch. I > have tested another DVD as well, no problems with that either. > Anyone else having comments on the latest version of my patch? Dan From sfsheldo at gmail.com Tue Nov 1 20:08:21 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Tue, 01 Nov 2011 12:08:21 -0700 Subject: [MPlayer-dev-eng] [PATCH] glob-win.c not compiled for mingw32 Message-ID: <4EB043A5.1010306@gmail.com> The changes for r34271 did not have the desired effect for mingw32. In the configure file, && should have been ||. In the Makefile, OS_FEATURE is funny because it is appended to SRCS_COMMON when it is suffixed with -no, but in the case of GLOB-WIN, it is suffixed with -yes. I moved osdep/glob-win.c to SRCS_COMMON. Patch attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: glob.patch URL: From Reimar.Doeffinger at gmx.de Tue Nov 1 22:17:55 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Tue, 1 Nov 2011 22:17:55 +0100 Subject: [MPlayer-dev-eng] [PATCH] glob-win.c not compiled for mingw32 In-Reply-To: <4EB043A5.1010306@gmail.com> References: <4EB043A5.1010306@gmail.com> Message-ID: <20111101211754.GA2260@1und1.de> On Tue, Nov 01, 2011 at 12:08:21PM -0700, Stephen Sheldon wrote: > The changes for r34271 did not have the desired effect for mingw32. > In the configure file, && should have been ||. In > the Makefile, OS_FEATURE is funny because it is appended to > SRCS_COMMON when it is suffixed with -no, but in the case > of GLOB-WIN, it is suffixed with -yes. I moved osdep/glob-win.c > to SRCS_COMMON. Patch attached. Those two changes you make should exactly cancel each other out, so I don't see how it would fix anything... From sfsheldo at gmail.com Wed Nov 2 00:13:41 2011 From: sfsheldo at gmail.com (Stephen Sheldon) Date: Tue, 01 Nov 2011 16:13:41 -0700 Subject: [MPlayer-dev-eng] [PATCH] glob-win.c not compiled for mingw32 In-Reply-To: <20111101211754.GA2260@1und1.de> References: <4EB043A5.1010306@gmail.com> <20111101211754.GA2260@1und1.de> Message-ID: <4EB07D25.6050508@gmail.com> On 11/1/2011 2:17 PM, Reimar D?ffinger wrote: > Those two changes you make should exactly cancel each other out, so I > don't see how it would fix anything... Now I see that. I started down this path looking for why wildcard expansion on the command line did not work for me. How about this patch to make things a very little clearer? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: glob2.patch URL: From diego at biurrun.de Wed Nov 2 14:03:39 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 02 Nov 2011 14:03:39 +0100 Subject: [MPlayer-dev-eng] [PATCH] glob-win.c not compiled for mingw32 In-Reply-To: <4EB07D25.6050508@gmail.com> References: <4EB043A5.1010306@gmail.com> <20111101211754.GA2260@1und1.de> <4EB07D25.6050508@gmail.com> Message-ID: <20111102130339.GA2463@pool.informatik.rwth-aachen.de> On Tue, Nov 01, 2011 at 04:13:41PM -0700, Stephen Sheldon wrote: > On 11/1/2011 2:17 PM, Reimar D?ffinger wrote: > >Those two changes you make should exactly cancel each other out, > >so I don't see how it would fix anything... > Now I see that. I started down this path looking for why wildcard > expansion on the command line did not work for me. > How about this patch to make things a very little clearer? Sure, why not - applied. Diego From feifan.zhou at intel.com Thu Nov 3 02:07:47 2011 From: feifan.zhou at intel.com (Zhou, Feifan) Date: Thu, 3 Nov 2011 09:07:47 +0800 Subject: [MPlayer-dev-eng] mplayer with VAAPI In-Reply-To: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> References: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> Message-ID: <749B9D3DBF0F054390025D9EAFF47F2212D5AEEFAD@shsmsx501.ccr.corp.intel.com> Do we plan to support VAAPI completely? I see that we only has support in libavcodec for VAAPI ,but lack the libvo/vo_vaapi.c. If no, could I merger this back to mainline from VAAPI branch? From Reimar.Doeffinger at gmx.de Thu Nov 3 08:29:06 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Thu, 3 Nov 2011 08:29:06 +0100 Subject: [MPlayer-dev-eng] mplayer with VAAPI In-Reply-To: <749B9D3DBF0F054390025D9EAFF47F2212D5AEEFAD@shsmsx501.ccr.corp.intel.com> References: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> <749B9D3DBF0F054390025D9EAFF47F2212D5AEEFAD@shsmsx501.ccr.corp.intel.com> Message-ID: <3F72A2CD-A06A-4393-96D9-18A51440054A@gmx.de> On 3 Nov 2011, at 02:07, "Zhou, Feifan" wrote: > Do we plan to support VAAPI completely? I see that we only has support in libavcodec for VAAPI ,but lack the libvo/vo_vaapi.c. > If no, could I merger this back to mainline from VAAPI branch? Only if you are willing to fix the remaining code quality issues. As far as I remember the last time this came up the code had quite a lot of issues still. From feifan.zhou at intel.com Thu Nov 3 09:55:44 2011 From: feifan.zhou at intel.com (Zhou, Feifan) Date: Thu, 3 Nov 2011 16:55:44 +0800 Subject: [MPlayer-dev-eng] mplayer with VAAPI In-Reply-To: <3F72A2CD-A06A-4393-96D9-18A51440054A@gmx.de> References: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> <749B9D3DBF0F054390025D9EAFF47F2212D5AEEFAD@shsmsx501.ccr.corp.intel.com> <3F72A2CD-A06A-4393-96D9-18A51440054A@gmx.de> Message-ID: <749B9D3DBF0F054390025D9EAFF47F2212D5AEF47B@shsmsx501.ccr.corp.intel.com> I think it's ok for me, with my experience, the vo_vaapi.c is stable enough. I will help to apply some patches to merge vo_vaapi back to mplayer. Is it ok for you? -----Original Message----- From: mplayer-dev-eng-bounces at mplayerhq.hu [mailto:mplayer-dev-eng-bounces at mplayerhq.hu] On Behalf Of Reimar D?ffinger Sent: Thursday, November 03, 2011 3:29 PM To: mplayer-dev-eng at mplayerhq.hu Subject: Re: [MPlayer-dev-eng] mplayer with VAAPI On 3 Nov 2011, at 02:07, "Zhou, Feifan" wrote: > Do we plan to support VAAPI completely? I see that we only has support in libavcodec for VAAPI ,but lack the libvo/vo_vaapi.c. > If no, could I merger this back to mainline from VAAPI branch? Only if you are willing to fix the remaining code quality issues. As far as I remember the last time this came up the code had quite a lot of issues still. _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng at mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng From diego at biurrun.de Thu Nov 3 13:02:20 2011 From: diego at biurrun.de (Diego Biurrun) Date: Thu, 03 Nov 2011 13:02:20 +0100 Subject: [MPlayer-dev-eng] mplayer with VAAPI In-Reply-To: <749B9D3DBF0F054390025D9EAFF47F2212D5AEF47B@shsmsx501.ccr.corp.intel.com> References: <749B9D3DBF0F054390025D9EAFF47F2212D5AEE53C@shsmsx501.ccr.corp.intel.com> <749B9D3DBF0F054390025D9EAFF47F2212D5AEEFAD@shsmsx501.ccr.corp.intel.com> <3F72A2CD-A06A-4393-96D9-18A51440054A@gmx.de> <749B9D3DBF0F054390025D9EAFF47F2212D5AEF47B@shsmsx501.ccr.corp.intel.com> Message-ID: <20111103120220.GA13800@pool.informatik.rwth-aachen.de> On Thu, Nov 03, 2011 at 04:55:44PM +0800, Zhou, Feifan wrote: > I think it's ok for me, with my experience, the vo_vaapi.c is stable > enough. I will help to apply some patches to merge vo_vaapi back to > mplayer. > Is it ok for you? Yes. But first please learn what top-posting is and how to avoid it. Diego From diego at biurrun.de Thu Nov 3 14:24:53 2011 From: diego at biurrun.de (Diego Biurrun) Date: Thu, 03 Nov 2011 14:24:53 +0100 Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation In-Reply-To: <4ea164ea.56982fe2.bm001@wupperonline.de> References: <20110919095720.GA28145@pool.informatik.rwth-aachen.de> <4ea164ea.56982fe2.bm001@wupperonline.de> Message-ID: <20111103132453.GB13800@pool.informatik.rwth-aachen.de> On Fri, Oct 21, 2011 at 02:17:00PM +0200, Ingo Br?ckl wrote: > Diego Biurrun wrote on Mon, 19 Sep 2011 11:57:20 +0200: > > > On Thu, Sep 15, 2011 at 11:30:19AM +0200, Ingo Br?ckl wrote: > >> There are some conditional declarations within the GUI [...] that > >> currently won't appear in the doxygen documentation, i.e. the generated > >> documentation is rather one according to the personal settings than a > >> general one. This could be changed by using the PREDEFINED tag. > > >> -EXPAND_ONLY_PREDEF = NO > >> +EXPAND_ONLY_PREDEF = YES > > > What about setting MACRO_EXPANSION to "yes" instead? > > Diego, did you make up your mind? Shall any tag (and if yes, which) be > changed? I still think this is brittle and I'm not sure it is really desirable to have documentation for (locally) unavailable functions. In any case there is another option: try setting ENABLE_PREPROCESSING to "NO" and compare the result. Diego From naoya.oyama at gmail.com Thu Nov 3 14:53:18 2011 From: naoya.oyama at gmail.com (Naoya OYAMA) Date: Thu, 3 Nov 2011 22:53:18 +0900 Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder In-Reply-To: References: <20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE> <20110926183719.GC2399@1und1.de> <20111010132712.GA27852@pool.informatik.rwth-aachen.de> Message-ID: Hi. Thank you for your test resport. ad_spdif.c has two problems. The patch coping with a problem is attached. [problem 1] If demuxer specify -demuxer lavf, MPlayer will judge that ad_spdif.c:init() went wrong. Because bps and srate value were 0. Native demuxers are automatically choosen, bps and srate value were not 0. [problem 2] If demuxer specify -demuxer mpegps, bellow line will failed. lavf_ctx->oformat = av_guess_format(FILENAME_SPDIFENC, NULL, NULL); Because av_register_all() was not executed. Thank you. 2011/10/15, Carl Eugen Hoyos : > Hi! > > Naoya OYAMA gmail.com> writes: > >> Patch update. > > Thank you for your efforts! > > I tested current MPlayer svn with -ac spdifac3, and for me it *only* works > if > ac3 audio is inside a transport stream (DVB, MPEG TS) or a program stream > (DVD, > MPEG PS) and -demuxer lavf is not used. > It only works if the native demuxers are automatically chosen, if I specify > -demuxer mpegts (or -demuxer mpegps), it also does not work. > The following combinations (all files contain ac3 audio) do not work for me: > mplayer -ac spdifac3 ac3.ts -demuxer lavf > mplayer -ac spdifac3 ac3.mpg -demuxer lavf > mplayer -ac spdifac3 ac3.mkv (both -demuxer mkv and -demuxer lavf) > mplayer -ac spdifac3 ac3.avi (both -demuxer avi and -demuxer lavf) > mplayer -ac spdifac3 ac3.ac3 (both -demuxer rawaudio -rawaudio format=0x2000 > and > -demuxer lavf) > > Can you reproduce this or do all / some combinations work fine for you? > > EAC3 works fine for me, TrueHD and DTS have problems (only work with > -novideo > here), but that may be my hardware, I see the same problems with software > decoding and -channels 8 -srate 192000. > > Thanks again, Carl Eugen > > _______________________________________________ > MPlayer-dev-eng mailing list > MPlayer-dev-eng at mplayerhq.hu > https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng > -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer_ad_spdif_fix_demuxer_option_problem.diff Type: text/x-patch Size: 1534 bytes Desc: not available URL: From cehoyos at ag.or.at Thu Nov 3 19:53:33 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Thu, 3 Nov 2011 18:53:33 +0000 (UTC) Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder References: <20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE> <20110926183719.GC2399@1und1.de> <20111010132712.GA27852@pool.informatik.rwth-aachen.de> Message-ID: Naoya OYAMA gmail.com> writes: > + if (bps == 0 && srate == 0) { // last resort > + srate = 48000; //fake value > + bps = 768000/8; //fake value Shouldn't this be if (!bps) bps = 768000/8; if (!srate) srate = 48000; ? Applied the other hunks, thank you, Carl Eugen From diego at biurrun.de Thu Nov 3 23:06:15 2011 From: diego at biurrun.de (Diego Biurrun) Date: Thu, 03 Nov 2011 23:06:15 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions Message-ID: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> I looked into the baroque ALSA check in configure and noticed that we support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 release). While maintaining compatibility and such is all nice and great a decade sounds like the timeframe when one can safely eliminate cruft. Am I overlooking something non-obvious about systems without ALSA versions from at least 2003 (first 1.0 release)? Diego From Reimar.Doeffinger at gmx.de Fri Nov 4 16:57:25 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Fri, 4 Nov 2011 16:57:25 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> Message-ID: <20111104155725.GA2925@1und1.de> On Thu, Nov 03, 2011 at 11:06:15PM +0100, Diego Biurrun wrote: > I looked into the baroque ALSA check in configure and noticed that we > support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 > release). While maintaining compatibility and such is all nice and > great a decade sounds like the timeframe when one can safely eliminate > cruft. > > Am I overlooking something non-obvious about systems without ALSA > versions from at least 2003 (first 1.0 release)? Well, I don't consider 0.9 _that_ ancient. Also note that the ao looks like it works just fine with both, no ugliness at all. The ais on the other hand someone thought it a good idea to duplicate the whole file because of what essentially is 7 lines difference. I admit without someone to come forward to test it it risks being pointless, but I would like to keep 0.9 support for compiling and having ao_alsa.c. About 0.5 and ai for 0.9: From my side feel free to kill it. From Reimar.Doeffinger at gmx.de Sun Nov 6 11:04:10 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 6 Nov 2011 11:04:10 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test Message-ID: <20111106100410.GA16892@1und1.de> Hello, a bit hackish, video only, some samples fail even when testing on a single configuration. Some, like the wmv drm, do not yet test what they are supposed to test. Still, better than nothing and hopefully distros etc. will use it to check that things are working at least on a basic level. I manually removed the reference file since they made the patch 1.3 MB large... -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.diff Type: text/x-diff Size: 2415 bytes Desc: not available URL: From maister at archlinux.us Sun Nov 6 15:03:15 2011 From: maister at archlinux.us (Hans-Kristian Arntzen) Date: Sun, 06 Nov 2011 15:03:15 +0100 Subject: [MPlayer-dev-eng] GBR24P default conversion to BGR24 Message-ID: <4EB693A3.8040906@archlinux.us> As FFmpeg upstream recently got an unscaled GBR24P -> RGB path in swscale, it might be a good idea to default the conversion to BGR24 (or RGB24, whatever's the fastest). FFmpeg commit: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1e79926f9e8bbfa2920a1d40e36d9ffcf244fe0a Currently the GBR24P gets autoconverted to YUV444P for -vo gl, which isn't very ideal now. Attached is the very trivial patch to set preferred format. There might be a more ideal approach, i.e. supporting GBR24P directly in the various drivers, but that would probably create more work than necessary. -------------- next part -------------- A non-text attachment was scrubbed... Name: gbr24p-conv.patch Type: text/x-patch Size: 303 bytes Desc: not available URL: From cehoyos at ag.or.at Sun Nov 6 15:24:40 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Sun, 6 Nov 2011 14:24:40 +0000 (UTC) Subject: [MPlayer-dev-eng] GBR24P default conversion to BGR24 References: <4EB693A3.8040906@archlinux.us> Message-ID: Hans-Kristian Arntzen archlinux.us> writes: > Currently the GBR24P gets autoconverted to YUV444P for -vo gl, which > isn't very ideal now. I am definitely not against the patch, but why is is not ideal to use yuv444p for -vo gl? Carl Eugen From alexc.xander at yahoo.in Sun Nov 6 16:44:21 2011 From: alexc.xander at yahoo.in (Alex C.) Date: Sun, 6 Nov 2011 21:14:21 +0530 Subject: [MPlayer-dev-eng] MPlayer/MEncoder crash on using -vf scale and expand together. Fix attached. In-Reply-To: <20111031222105.GA2413@1und1.de> References: <1319806051.82903.YahooMailNeo@web137606.mail.in.yahoo.com> <20111028170145.GA3530@1und1.de> <1319911782.2110.9.camel@MERCEDES-II> <20111031222105.GA2413@1und1.de> Message-ID: <20111106211421.6a37d615@MERCEDES-II> I'm currently testing Michael Niedermeyer's updated ffmpeg. It has proved to be robust so far, apart from the swscaler warning message regarding possible speedloss (sic). I think that this change in libswscaler is the best solution for this problem. However, I would like a way to enable alignment, considering that the same codepath is utilised by MEncoder (my primary use for swscaler) which benefits from swscaler speed without having rendering issues. That said, I've not benchmarked the SSE3 routine with and without alignment, so can't say if there is a speed improvement in the first place. --- AC Live Free Or Die From Dan.Oscarsson at tieto.com Sun Nov 6 18:14:52 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sun, 06 Nov 2011 18:14:52 +0100 Subject: [MPlayer-dev-eng] threaded cache instead for forked? Message-ID: <1320599692.15602.10.camel@luna.malmo.kicore.net> Currently the caching code forks on Linux, uses threads on ms windows, from what I can see. I have looked at the code and enable threading on Linux too, and what I can see if works fine. Is there some reason why we still use fork instead of threads? Threads are used today in other parts of mplayer or its libraries. Using fork can result in the cache process left running when mplayer crashes. Looking at the code I see that I could add threaded sematics to enable control operation to wake up caching thread immediately, and there is one place where the code loops on the cpu waiting for cache thread/process to complete a control operation. Dan From maister at archlinux.us Mon Nov 7 17:35:23 2011 From: maister at archlinux.us (Hans-Kristian Arntzen) Date: Mon, 07 Nov 2011 17:35:23 +0100 Subject: [MPlayer-dev-eng] GBR24P default conversion to BGR24 Message-ID: <4EB808CB.2080303@archlinux.us> >I am definitely not against the patch, but why is is not ideal to use yuv444p >for -vo gl? > >Carl Eugen GBR24P -> YUV444 -> RGB is not a lossless process with 8-bit channels. The most common usage for H.264 RGB (GBR24P) so far is storing lossless recordings of video game material, so preserving this losslessness when playing back is important if possible. From Reimar.Doeffinger at gmx.de Mon Nov 7 19:43:19 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 7 Nov 2011 19:43:19 +0100 Subject: [MPlayer-dev-eng] GBR24P default conversion to BGR24 In-Reply-To: <4EB808CB.2080303@archlinux.us> References: <4EB808CB.2080303@archlinux.us> Message-ID: <20111107184319.GB11743@1und1.de> On Mon, Nov 07, 2011 at 05:35:23PM +0100, Hans-Kristian Arntzen wrote: > >I am definitely not against the patch, but why is is not ideal to use yuv444p > >for -vo gl? > > > >Carl Eugen > > GBR24P -> YUV444 -> RGB is not a lossless process with 8-bit channels. The most common usage for H.264 RGB (GBR24P) so far is storing lossless recordings of video game material, so preserving this losslessness when playing back is important if possible. There is also the matter of speed and energy usage of two useless conversions. On the other hand -vo gl supports gamma, brightness, contrast etc. with YUV444 but not with RGB... From Reimar.Doeffinger at gmx.de Mon Nov 7 19:50:28 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 7 Nov 2011 19:50:28 +0100 Subject: [MPlayer-dev-eng] GBR24P default conversion to BGR24 In-Reply-To: <4EB693A3.8040906@archlinux.us> References: <4EB693A3.8040906@archlinux.us> Message-ID: <20111107185028.GA11836@1und1.de> On Sun, Nov 06, 2011 at 03:03:15PM +0100, Hans-Kristian Arntzen wrote: > As FFmpeg upstream recently got an unscaled GBR24P -> RGB path in > swscale, it might be a good idea to default the conversion to BGR24 > (or RGB24, whatever's the fastest). > > FFmpeg commit: > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1e79926f9e8bbfa2920a1d40e36d9ffcf244fe0a > > Currently the GBR24P gets autoconverted to YUV444P for -vo gl, which > isn't very ideal now. > > Attached is the very trivial patch to set preferred format. There > might be a more ideal approach, i.e. supporting GBR24P directly in > the various drivers, but that would probably create more work than > necessary. > --- libmpcodecs/vf_scale.c.old 2011-11-06 14:42:33.905341624 +0100 > +++ libmpcodecs/vf_scale.c 2011-11-06 14:42:59.225342167 +0100 > @@ -135,6 +135,7 @@ > {IMGFMT_UYVY, IMGFMT_422P}, > {IMGFMT_422P, IMGFMT_YUY2}, > {IMGFMT_422P, IMGFMT_UYVY}, > + {IMGFMT_GBR24P, IMGFMT_BGR24}, I extended it to make RGB24, BGR32 and RGB32 preferred targets as well (e.g. in case of a theoretical VO that only supports RGB32 and YV12 for example). From Reimar.Doeffinger at gmx.de Mon Nov 7 19:55:05 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 7 Nov 2011 19:55:05 +0100 Subject: [MPlayer-dev-eng] threaded cache instead for forked? In-Reply-To: <1320599692.15602.10.camel@luna.malmo.kicore.net> References: <1320599692.15602.10.camel@luna.malmo.kicore.net> Message-ID: <20111107185505.GA11887@1und1.de> On Sun, Nov 06, 2011 at 06:14:52PM +0100, Dan Oscarsson wrote: > Currently the caching code forks on Linux, uses threads on ms windows, > from what I can see. I have looked at the code and enable threading on > Linux too, and what I can see if works fine. Is there some reason why we > still use fork instead of threads? Threads are used today in other parts > of mplayer or its libraries. > > Using fork can result in the cache process left running when mplayer > crashes. > > Looking at the code I see that I could add threaded sematics to enable > control operation to wake up caching thread immediately, and there is > one place where the code loops on the cpu waiting for cache > thread/process to complete a control operation. Well, as you see yourself there are things that can be done to improve it and probably there are things that _should_ be done before making it the default. In particular, testing it properly. There is also a bit the point of avoiding fragmenting the cases to test even more, if we make it the default there is a good chance enough people do still not have pthreads and/or don't want it used that we end up with 3 cache implementations in common use instead of just 2. From onemda at gmail.com Tue Nov 8 01:30:18 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Tue, 8 Nov 2011 00:30:18 +0000 Subject: [MPlayer-dev-eng] [PATCH] vo_caca.c: switch to newer API Message-ID: Hi, derived from 2006 version. -------------- next part -------------- A non-text attachment was scrubbed... Name: caca0.diff Type: text/x-diff Size: 6910 bytes Desc: not available URL: From diego at biurrun.de Tue Nov 8 09:15:36 2011 From: diego at biurrun.de (Diego Biurrun) Date: Tue, 08 Nov 2011 09:15:36 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <20111104155725.GA2925@1und1.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> <20111104155725.GA2925@1und1.de> Message-ID: <20111108081535.GA8975@pool.informatik.rwth-aachen.de> On Fri, Nov 04, 2011 at 04:57:25PM +0100, Reimar D?ffinger wrote: > On Thu, Nov 03, 2011 at 11:06:15PM +0100, Diego Biurrun wrote: > > I looked into the baroque ALSA check in configure and noticed that we > > support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 > > release). While maintaining compatibility and such is all nice and > > great a decade sounds like the timeframe when one can safely eliminate > > cruft. > > > > Am I overlooking something non-obvious about systems without ALSA > > versions from at least 2003 (first 1.0 release)? > > Well, I don't consider 0.9 _that_ ancient. Gosh, what *is* ancient then? :) > Also note that the ao looks like it works just fine with both, no > ugliness at all. There is some #ifdeffery, but I guess we can live with that. > The ais on the other hand someone thought it a good idea to duplicate > the whole file because of what essentially is 7 lines difference. > I admit without someone to come forward to test it it risks being > pointless, but I would like to keep 0.9 support for compiling and > having ao_alsa.c. I'm CCing Clemens, maybe he can add his opinion. > About 0.5 and ai for 0.9: From my side feel free to kill it. I'll go ahead. Diego From clemens at ladisch.de Tue Nov 8 10:53:28 2011 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue, 08 Nov 2011 10:53:28 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <20111108081535.GA8975@pool.informatik.rwth-aachen.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> <20111104155725.GA2925@1und1.de> <20111108081535.GA8975@pool.informatik.rwth-aachen.de> Message-ID: <4EB8FC18.7060600@ladisch.de> > On Fri, Nov 04, 2011 at 04:57:25PM +0100, Reimar D?ffinger wrote: > > On Thu, Nov 03, 2011 at 11:06:15PM +0100, Diego Biurrun wrote: > > > I looked into the baroque ALSA check in configure and noticed that we > > > support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 > > > release). While maintaining compatibility and such is all nice and > > > great a decade sounds like the timeframe when one can safely eliminate > > > cruft. > > > > > > Am I overlooking something non-obvious about systems without ALSA > > > versions from at least 2003 (first 1.0 release)? There really isn't much difference between 0.9* and 1.0; there weren't any big technical reasons for the version change. There was a small API change, but the libraries are binary compatible (as long as no newer APIs are used). OTOH, 0.5 was a completely different API and considered somewhat of a prototype. All 0.9/1.0 alsa-lib and kernel versions should be compatible; I think it somewhat unlikely that somebody would use a new mplayer without being able to update alsa-lib. It should be noted that ao_alsa.c uses some functions introduced in 0.9.0rc4, which was after the move to alsa/, so support can be dropped. > > The ais on the other hand someone thought it a good idea to duplicate > > the whole file because of what essentially is 7 lines difference. With "#define ALSA_PCM_NEW_*_API", ai_alsa1x.c can be used for both. With these defines (and with 0.5 dropped), no version check is needed in configure. Regards, Clemens From Reimar.Doeffinger at gmx.de Tue Nov 8 22:15:00 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Tue, 8 Nov 2011 22:15:00 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111106100410.GA16892@1und1.de> References: <20111106100410.GA16892@1und1.de> Message-ID: <20111108211500.GA14191@1und1.de> On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: > Hello, > a bit hackish, video only, some samples fail even when testing on a > single configuration. > Some, like the wmv drm, do not yet test what they are supposed to test. > Still, better than nothing and hopefully distros etc. will use it > to check that things are working at least on a basic level. > I manually removed the reference file since they made the patch 1.3 MB > large... Applied due to lack of objections. Note that a lot of files do not decode, and possibly some might decode wrongly - I did not verify the test results so far, this is a pure regression test right now. Though cd tests/res ; find -size 0c should give you an almost accurate list of files MPlayer completely fails to decode. From diego at biurrun.de Wed Nov 9 01:01:37 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 9 Nov 2011 01:01:37 +0100 Subject: [MPlayer-dev-eng] =?utf-8?q?=5BPATCH=5D_Remove_warning_when_tryin?= =?utf-8?q?g_to_invoke_long-gone_alsa9_and_alsa1x_ao_drivers=2E?= Message-ID: <1320796897-19322-1-git-send-email-diego@biurrun.de> These drivers have been replaced years ago, it's time to drop the hint. --- help/help_mp-bg.h | 3 --- help/help_mp-cs.h | 1 - help/help_mp-de.h | 3 --- help/help_mp-en.h | 1 - help/help_mp-es.h | 1 - help/help_mp-fr.h | 3 --- help/help_mp-hu.h | 1 - help/help_mp-it.h | 1 - help/help_mp-nl.h | 3 --- help/help_mp-pl.h | 3 --- help/help_mp-ru.h | 1 - help/help_mp-sv.h | 3 --- help/help_mp-tr.h | 3 --- help/help_mp-zh_CN.h | 1 - help/help_mp-zh_TW.h | 3 --- libao2/audio_out.c | 4 ---- 16 files changed, 0 insertions(+), 35 deletions(-) diff --git a/help/help_mp-bg.h b/help/help_mp-bg.h index 95fae30..5fd7e74 100644 --- a/help/help_mp-bg.h +++ b/help/help_mp-bg.h @@ -856,9 +856,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: ???????? alsa9 ? alsa1x ?? ??????????, ??????????? -ao alsa .\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: ?? ???? ?? ?????? ?????????? ???????? %s: %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup:\n?????????? ?? ????????? ????? ???? ????? '%s', ???????? ?? ??????????? ??.\n" diff --git a/help/help_mp-cs.h b/help/help_mp-cs.h index 0911a13..b83c181 100644 --- a/help/help_mp-cs.h +++ b/help/help_mp-cs.h @@ -1105,7 +1105,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: moduly alsa9 a alsa1x byly odstran?ny, m?sto nich pou?ijte -ao alsa.\n" #define MSGTR_AO_NoSuchDriver "Takov? audio rozhran? nen? '%.*s'\n" #define MSGTR_AO_FailedInit "Selhala inicializace audio rozhran? '%s'\n" diff --git a/help/help_mp-de.h b/help/help_mp-de.h index cd3037b..189d12f 100644 --- a/help/help_mp-de.h +++ b/help/help_mp-de.h @@ -1118,9 +1118,6 @@ static const char help_text[]= // ======================= Audioausgabetreiber ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed \ -"audio_out: Die Module alsa9 und alsa1x wurden entfernt, benutze stattdessen \n" \ -"-ao alsa.\n" #define MSGTR_AO_NoSuchDriver "Kein Audiotreiber '%.*s'\n" #define MSGTR_AO_FailedInit "Konnte Audiotreiber '%s' nicht initialisieren\n" diff --git a/help/help_mp-en.h b/help/help_mp-en.h index 387e711..658b3e6 100644 --- a/help/help_mp-en.h +++ b/help/help_mp-en.h @@ -1164,7 +1164,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9 and alsa1x modules were removed, use -ao alsa instead.\n" #define MSGTR_AO_NoSuchDriver "No such audio driver '%.*s'\n" #define MSGTR_AO_FailedInit "Failed to initialize audio driver '%s'\n" diff --git a/help/help_mp-es.h b/help/help_mp-es.h index d9fc316..d12d7dd 100644 --- a/help/help_mp-es.h +++ b/help/help_mp-es.h @@ -1119,7 +1119,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: los m?dulos alsa9 y alsa1x fueron eliminados, usa -ao alsa.\n" #define MSGTR_AO_NoSuchDriver "No existe ese controlador de audio '%.*s'\n" #define MSGTR_AO_FailedInit "Fallo al inicializar controlador de audio '%s'\n" diff --git a/help/help_mp-fr.h b/help/help_mp-fr.h index fa388c8..d7a4fd5 100644 --- a/help/help_mp-fr.h +++ b/help/help_mp-fr.h @@ -1029,9 +1029,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out : modules alsa9 et alsa1x enlev?s, utiliser plut?t -ao alsa.\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup : Impossible d'ouvrir mixeur %s : %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup : Mixeur de carte audio n'a pas canal '%s' utilise default.\n" diff --git a/help/help_mp-hu.h b/help/help_mp-hu.h index 2dc4aa6..6c7591e 100644 --- a/help/help_mp-hu.h +++ b/help/help_mp-hu.h @@ -1118,7 +1118,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9 ?s alsa1x modulok t?r?lve lettek, haszn?ld a -ao alsa kapcsol?t helyett?k.\n" #define MSGTR_AO_NoSuchDriver "Nincs ilyen audi? vez?rl?: '%.*s'\n" #define MSGTR_AO_FailedInit "A(z) '%s' audi? vez?rl? inicializ?l?sa nem siker?lt\n" diff --git a/help/help_mp-it.h b/help/help_mp-it.h index 863a3f1..09f13bd 100644 --- a/help/help_mp-it.h +++ b/help/help_mp-it.h @@ -1113,7 +1113,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: i moduli alsa9/alsa1x sono stati rimossi, ora usa -ao alsa.\n" #define MSGTR_AO_NoSuchDriver "driver audio '%.*s' non trovato\n" #define MSGTR_AO_FailedInit "Inizializzazione del driver audio '%s' non riuscita\n" diff --git a/help/help_mp-nl.h b/help/help_mp-nl.h index 5271552..b97b595 100644 --- a/help/help_mp-nl.h +++ b/help/help_mp-nl.h @@ -791,9 +791,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: de alsa9 en alsa1x modules werden verwijderd, gebruik -ao alsa.\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Kan het mixer apparaat %s niet openen : %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: De mixer van de geluidskaart heeft geen kanaal dat de standaard '%s' gebruikt.\n" diff --git a/help/help_mp-pl.h b/help/help_mp-pl.h index d50c0e4..b56bacd 100644 --- a/help/help_mp-pl.h +++ b/help/help_mp-pl.h @@ -995,9 +995,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: modu?y alsa9 i alsa1x zosta?y usuni?te, u?yj w zamian -ao alsa.\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Nie mog? otworzy? mixera %s: %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: Mixer karty d?wi?kowej nie ma kana?u '%s', u?ywam domy?lnego.\n" diff --git a/help/help_mp-ru.h b/help/help_mp-ru.h index 13048d3..ece74f5 100644 --- a/help/help_mp-ru.h +++ b/help/help_mp-ru.h @@ -1106,7 +1106,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "??????????: ?????? alsa9 ? alsa1x ???? ???????, ??????????? -ao alsa ??????.\n" #define MSGTR_AO_NoSuchDriver "??????????? ????? ??????? '%.*s'\n" #define MSGTR_AO_FailedInit "?? ???? ???????????????? ????? ??????? '%s'\n" diff --git a/help/help_mp-sv.h b/help/help_mp-sv.h index cef45f3..0315ddf 100644 --- a/help/help_mp-sv.h +++ b/help/help_mp-sv.h @@ -811,9 +811,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "audio_out: alsa9- samt alsa1xmodulerna har blivit borttagna, anv?nd -ao ist?llet.\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] audio_setup: Kan inte ?ppna mixernehet %s: %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] audio_setup: Audiokortsmixer har inte kanal '%s' anv?nder standard.\n" diff --git a/help/help_mp-tr.h b/help/help_mp-tr.h index 490cdab..ab56118 100644 --- a/help/help_mp-tr.h +++ b/help/help_mp-tr.h @@ -1043,9 +1043,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "ses_??k???: alsa9 ve alsa1x mod?lleri silindi, yerine -ao se?ene?ini kullan?n?z.\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] ses_kurulumu: %s kar??t?r?c? ayg?t? a??lam?yor: %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] ses_kurulumu: Ses kart? kar??t?r?c?s? '%s' kanal?na sahip de?il, varsay?lan kullan?l?yor.\n" diff --git a/help/help_mp-zh_CN.h b/help/help_mp-zh_CN.h index 0f34f06..252cd9b 100644 --- a/help/help_mp-zh_CN.h +++ b/help/help_mp-zh_CN.h @@ -1164,7 +1164,6 @@ static const char help_text[]= // ======================= audio output drivers ======================== // audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "?????alsa9 ? alsa1x ????????? -ao alsa ???\n" #define MSGTR_AO_NoSuchDriver "???????%.*s?\n" #define MSGTR_AO_FailedInit "??????????%s?\n" diff --git a/help/help_mp-zh_TW.h b/help/help_mp-zh_TW.h index ba49494..4d074e3 100644 --- a/help/help_mp-zh_TW.h +++ b/help/help_mp-zh_TW.h @@ -1014,9 +1014,6 @@ static const char help_text[]= // libao2 -// audio_out.c -#define MSGTR_AO_ALSA9_1x_Removed "????: alsa9 ? alsa1x ??????, ?? -ao alsa ???\n" - // ao_oss.c #define MSGTR_AO_OSS_CantOpenMixer "[AO OSS] ????: ????????? %s: %s\n" #define MSGTR_AO_OSS_ChanNotFound "[AO OSS] ????: ???????'%s', ???????\n" diff --git a/libao2/audio_out.c b/libao2/audio_out.c index c0840a4..56b0b77 100644 --- a/libao2/audio_out.c +++ b/libao2/audio_out.c @@ -141,10 +141,6 @@ const ao_functions_t* init_best_audio_out(char** ao_list,int use_plugin,int rate while(ao_list[0][0]){ char* ao=ao_list[0]; int ao_len; - if (strncmp(ao, "alsa9", 5) == 0 || strncmp(ao, "alsa1x", 6) == 0) { - mp_msg(MSGT_AO, MSGL_FATAL, MSGTR_AO_ALSA9_1x_Removed); - exit_player(EXIT_NONE); - } free(ao_subdevice); ao_subdevice = NULL; ao_subdevice=strchr(ao,':'); -- 1.7.2.5 From diego at biurrun.de Wed Nov 9 01:40:27 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 09 Nov 2011 01:40:27 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111108211500.GA14191@1und1.de> References: <20111106100410.GA16892@1und1.de> <20111108211500.GA14191@1und1.de> Message-ID: <20111109004027.GA14063@pool.informatik.rwth-aachen.de> On Tue, Nov 08, 2011 at 10:15:00PM +0100, Reimar D?ffinger wrote: > On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: > > a bit hackish, video only, some samples fail even when testing on a > > single configuration. > > Some, like the wmv drm, do not yet test what they are supposed to test. > > Still, better than nothing and hopefully distros etc. will use it > > to check that things are working at least on a basic level. > > I manually removed the reference file since they made the patch 1.3 MB > > large... > > Applied due to lack of objections. There were no objections due to lack of time to give them. Diego From diego at biurrun.de Wed Nov 9 02:28:26 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 09 Nov 2011 02:28:26 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <4EB8FC18.7060600@ladisch.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> <20111104155725.GA2925@1und1.de> <20111108081535.GA8975@pool.informatik.rwth-aachen.de> <4EB8FC18.7060600@ladisch.de> Message-ID: <20111109012825.GB14063@pool.informatik.rwth-aachen.de> On Tue, Nov 08, 2011 at 10:53:28AM +0100, Clemens Ladisch wrote: > > On Fri, Nov 04, 2011 at 04:57:25PM +0100, Reimar D?ffinger wrote: > > > On Thu, Nov 03, 2011 at 11:06:15PM +0100, Diego Biurrun wrote: > > > > I looked into the baroque ALSA check in configure and noticed that we > > > > support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 > > > > release). While maintaining compatibility and such is all nice and > > > > great a decade sounds like the timeframe when one can safely eliminate > > > > cruft. > > > > > > > > Am I overlooking something non-obvious about systems without ALSA > > > > versions from at least 2003 (first 1.0 release)? > > There really isn't much difference between 0.9* and 1.0; there weren't > any big technical reasons for the version change. There was a small > API change, but the libraries are binary compatible (as long as no > newer APIs are used). > > OTOH, 0.5 was a completely different API and considered somewhat of > a prototype. > > All 0.9/1.0 alsa-lib and kernel versions should be compatible; I think > it somewhat unlikely that somebody would use a new mplayer without > being able to update alsa-lib. > > It should be noted that ao_alsa.c uses some functions introduced in > 0.9.0rc4, which was after the move to alsa/, so > support can be dropped. > > > > The ais on the other hand someone thought it a good idea to duplicate > > > the whole file because of what essentially is 7 lines difference. > > With "#define ALSA_PCM_NEW_*_API", ai_alsa1x.c can be used for both. > > With these defines (and with 0.5 dropped), no version check is needed > in configure. I say go right ahead and implement it. Diego From diego at biurrun.de Wed Nov 9 02:43:18 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 09 Nov 2011 02:43:18 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111106100410.GA16892@1und1.de> References: <20111106100410.GA16892@1und1.de> Message-ID: <20111109014318.GC14063@pool.informatik.rwth-aachen.de> On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: > a bit hackish, video only, some samples fail even when testing on a > single configuration. > --- Makefile (revision 34309) > +++ Makefile (working copy) > @@ -926,6 +926,7 @@ > > clean: > -$(MAKE) -C ffmpeg $@ > + -$(MAKE) -C tests clean > -rm -f $(call ADD_ALL_DIRS,/*.o /*.a /*.ho /*~) > -rm -f $(call ADD_ALL_EXESUFS,mplayer mencoder) > > @@ -1087,12 +1088,14 @@ > > +fatetest: mplayer$(EXESUF) > + $(MAKE) -C tests fatetest > > > -include $(DEP_FILES) $(DRIVER_DEP_FILES) $(TESTS_DEP_FILES) $(TOOLS_DEP_FILES) $(DHAHELPER_DEP_FILES) > > .PHONY: all doxygen *install* *tools drivers dhahelper* > -.PHONY: checkheaders *clean tests check_checksums > +.PHONY: checkheaders *clean tests check_checksums fatetest I designed the build system non-recursive and monolithic on purpose. tests/Makefile should be part of the main Makefile. > --- tests/faterun.sh (revision 0) > +++ tests/faterun.sh (revision 0) > @@ -0,0 +1,10 @@ > +#!/bin/sh > +i=$1 > +echo "running $i" > +mkdir -p res/$(dirname $i) > +touch res/$i.md5 > +../mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=res/$i.md5 $FATE_SAMPLES/$i > +if ! diff -uw ref/$i.md5 res/$i.md5 ; then > + mv res/$i.md5 res/$i.md5.bad > + exit 1 > +fi "i" is not really a better variable name than "1". Also, a few empty lines could make this more readable. I'll have to play with it still, but adding a test suite is a great idea in principle. Diego From diego at biurrun.de Wed Nov 9 02:54:22 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 09 Nov 2011 02:54:22 +0100 Subject: [MPlayer-dev-eng] [PATCH] vo_caca.c: switch to newer API In-Reply-To: References: Message-ID: <20111109015422.GD14063@pool.informatik.rwth-aachen.de> On Tue, Nov 08, 2011 at 12:30:18AM +0000, Paul B. Mahol wrote: > > derived from 2006 version. Thanks, will apply shortly after testing. Diego From Reimar.Doeffinger at gmx.de Wed Nov 9 08:30:13 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Wed, 9 Nov 2011 08:30:13 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111109014318.GC14063@pool.informatik.rwth-aachen.de> References: <20111106100410.GA16892@1und1.de> <20111109014318.GC14063@pool.informatik.rwth-aachen.de> Message-ID: <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> On 9 Nov 2011, at 02:43, Diego Biurrun wrote: > On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: >> a bit hackish, video only, some samples fail even when testing on a >> single configuration. > >> --- Makefile (revision 34309) >> +++ Makefile (working copy) >> @@ -926,6 +926,7 @@ >> >> clean: >> -$(MAKE) -C ffmpeg $@ >> + -$(MAKE) -C tests clean >> -rm -f $(call ADD_ALL_DIRS,/*.o /*.a /*.ho /*~) >> -rm -f $(call ADD_ALL_EXESUFS,mplayer mencoder) >> >> @@ -1087,12 +1088,14 @@ >> >> +fatetest: mplayer$(EXESUF) >> + $(MAKE) -C tests fatetest >> >> >> -include $(DEP_FILES) $(DRIVER_DEP_FILES) $(TESTS_DEP_FILES) $(TOOLS_DEP_FILES) $(DHAHELPER_DEP_FILES) >> >> .PHONY: all doxygen *install* *tools drivers dhahelper* >> -.PHONY: checkheaders *clean tests check_checksums >> +.PHONY: checkheaders *clean tests check_checksums fatetest > > I designed the build system non-recursive and monolithic on purpose. > > tests/Makefile should be part of the main Makefile. Well, including it should be no problem, but I really don't want everything in one single Makefile, that one is already almost as "nice" to get an overview of as mplayer.c I remember you complaining that people don't apply good programming principles to build systems, so this is a good point at applying the principle "independent stuff I different files" IMO. There's also some other minor annoyance like that it is convenient to run the test script from the tests directory, that's a bit more difficult with non-recursive make. > >> --- tests/faterun.sh (revision 0) >> +++ tests/faterun.sh (revision 0) >> @@ -0,0 +1,10 @@ >> +#!/bin/sh >> +i=$1 >> +echo "running $i" >> +mkdir -p res/$(dirname $i) >> +touch res/$i.md5 >> +../mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=res/$i.md5 $FATE_SAMPLES/$i >> +if ! diff -uw ref/$i.md5 res/$i.md5 ; then >> + mv res/$i.md5 res/$i.md5.bad >> + exit 1 >> +fi > > "i" is not really a better variable name than "1". > Also, a few empty lines could make this more readable. I had a loop in there originally and forgot to clean it up. I is still better since it's easier to change i=$1 to i=$2 for example than having to change it everywhere. > From Reimar.Doeffinger at gmx.de Wed Nov 9 08:32:19 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Wed, 9 Nov 2011 08:32:19 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111109004027.GA14063@pool.informatik.rwth-aachen.de> References: <20111106100410.GA16892@1und1.de> <20111108211500.GA14191@1und1.de> <20111109004027.GA14063@pool.informatik.rwth-aachen.de> Message-ID: <36A93E85-6D42-4742-8B22-41578444620F@gmx.de> On 9 Nov 2011, at 01:40, Diego Biurrun wrote: > On Tue, Nov 08, 2011 at 10:15:00PM +0100, Reimar D?ffinger wrote: >> On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: >>> a bit hackish, video only, some samples fail even when testing on a >>> single configuration. >>> Some, like the wmv drm, do not yet test what they are supposed to test. >>> Still, better than nothing and hopefully distros etc. will use it >>> to check that things are working at least on a basic level. >>> I manually removed the reference file since they made the patch 1.3 MB >>> large... >> >> Applied due to lack of objections. > > There were no objections due to lack of time to give them. Sorry, but I would have thought that 2.5 should have been enough for someone to say _something_ and if it's only "I want to review more". Either way it's not like it can really break anything even if it happens to be messy. > From Reimar.Doeffinger at gmx.de Wed Nov 9 09:04:31 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Wed, 9 Nov 2011 09:04:31 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> References: <20111106100410.GA16892@1und1.de> <20111109014318.GC14063@pool.informatik.rwth-aachen.de> <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> Message-ID: <55A9112A-A319-4F43-B753-9942891D401F@gmx.de> On 9 Nov 2011, at 08:30, Reimar D?ffinger wrote: > On 9 Nov 2011, at 02:43, Diego Biurrun wrote: > >> On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: >>> a bit hackish, video only, some samples fail even when testing on a >>> single configuration. >> >>> --- Makefile (revision 34309) >>> +++ Makefile (working copy) >>> @@ -926,6 +926,7 @@ >>> >>> clean: >>> -$(MAKE) -C ffmpeg $@ >>> + -$(MAKE) -C tests clean >>> -rm -f $(call ADD_ALL_DIRS,/*.o /*.a /*.ho /*~) >>> -rm -f $(call ADD_ALL_EXESUFS,mplayer mencoder) >>> >>> @@ -1087,12 +1088,14 @@ >>> >>> +fatetest: mplayer$(EXESUF) >>> + $(MAKE) -C tests fatetest >>> >>> >>> -include $(DEP_FILES) $(DRIVER_DEP_FILES) $(TESTS_DEP_FILES) $(TOOLS_DEP_FILES) $(DHAHELPER_DEP_FILES) >>> >>> .PHONY: all doxygen *install* *tools drivers dhahelper* >>> -.PHONY: checkheaders *clean tests check_checksums >>> +.PHONY: checkheaders *clean tests check_checksums fatetest >> >> I designed the build system non-recursive and monolithic on purpose. >> >> tests/Makefile should be part of the main Makefile. > > Well, including it should be no problem, but I really don't want everything in one single Makefile, that one is already almost as "nice" to get an overview of as mplayer.c > I remember you complaining that people don't apply good programming principles to build systems, so this is a good point at applying the principle "independent stuff I different files" IMO. > There's also some other minor annoyance like that it is convenient to run the test script from the tests directory, that's a bit more difficult with non-recursive make. A different solution I'd be completely fine with - for now at least - is to have two completely separate Makefiles, then it is not recursive. I do see (now) and agree that what I added to the main Makefile ended up being messy and broken. From diego at biurrun.de Wed Nov 9 15:27:10 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 09 Nov 2011 15:27:10 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> References: <20111106100410.GA16892@1und1.de> <20111109014318.GC14063@pool.informatik.rwth-aachen.de> <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> Message-ID: <20111109142710.GA8565@pool.informatik.rwth-aachen.de> On Wed, Nov 09, 2011 at 08:30:13AM +0100, Reimar D?ffinger wrote: > On 9 Nov 2011, at 02:43, Diego Biurrun wrote: > > On Sun, Nov 06, 2011 at 11:04:10AM +0100, Reimar D?ffinger wrote: > >> a bit hackish, video only, some samples fail even when testing on a > >> single configuration. > > > >> --- Makefile (revision 34309) > >> +++ Makefile (working copy) > >> @@ -926,6 +926,7 @@ > >> > >> clean: > >> -$(MAKE) -C ffmpeg $@ > >> + -$(MAKE) -C tests clean > >> -rm -f $(call ADD_ALL_DIRS,/*.o /*.a /*.ho /*~) > >> -rm -f $(call ADD_ALL_EXESUFS,mplayer mencoder) > >> > >> @@ -1087,12 +1088,14 @@ > >> > >> +fatetest: mplayer$(EXESUF) > >> + $(MAKE) -C tests fatetest > >> > >> > >> -include $(DEP_FILES) $(DRIVER_DEP_FILES) $(TESTS_DEP_FILES) $(TOOLS_DEP_FILES) $(DHAHELPER_DEP_FILES) > >> > >> .PHONY: all doxygen *install* *tools drivers dhahelper* > >> -.PHONY: checkheaders *clean tests check_checksums > >> +.PHONY: checkheaders *clean tests check_checksums fatetest > > > > I designed the build system non-recursive and monolithic on purpose. > > > > tests/Makefile should be part of the main Makefile. > > Well, including it should be no problem, but I really don't want > everything in one single Makefile, that one is already almost as > "nice" to get an overview of as mplayer.c Currently the Makefile is 1134 lines, but only 400 lines or so of that are actually code, the rest is variable declarations with one file per line. Given the size and complexity of MPlayer this is very moderate. Notice that the most arcane stuff in there comes from VIDIX, kernel drivers, tools and other things of little relevance nowadays. If you are worried about build system complexity, let's eliminate some more cruft. > I remember you complaining that people don't apply good programming > principles to build systems, so this is a good point at applying the > principle "independent stuff I different files" IMO. If only it were independent - it is not. Recursive make is always a bad idea. I'm under the impression that you have not read the "Recursive Make Considered Harmful" paper yet. Go right ahead, it's short and sweet: http://miller.emu.id.au/pmiller/books/rmch/ Folding tests/Makefile into the top-level Makefile would not only add less lines than tests/Makefile has now; it would also actually work. > There's also some other minor annoyance like that it is convenient > to run the test script from the tests directory, that's a bit more > difficult with non-recursive make. Just shake the habit .. > >> --- tests/faterun.sh (revision 0) > >> +++ tests/faterun.sh (revision 0) > >> @@ -0,0 +1,10 @@ > >> +#!/bin/sh > >> +i=$1 > >> +echo "running $i" > >> +mkdir -p res/$(dirname $i) > >> +touch res/$i.md5 > >> +../mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=res/$i.md5 $FATE_SAMPLES/$i > >> +if ! diff -uw ref/$i.md5 res/$i.md5 ; then > >> + mv res/$i.md5 res/$i.md5.bad > >> + exit 1 > >> +fi > > > > "i" is not really a better variable name than "1". > > Also, a few empty lines could make this more readable. > > I had a loop in there originally and forgot to clean it up. > I is still better since it's easier to change i=$1 to i=$2 for example > than having to change it everywhere. Nah, I'm operating under the assumption that everybody is smart enough for automatic search and replace around here :) Diego From Reimar.Doeffinger at gmx.de Wed Nov 9 19:45:44 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 9 Nov 2011 19:45:44 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111109142710.GA8565@pool.informatik.rwth-aachen.de> References: <20111106100410.GA16892@1und1.de> <20111109014318.GC14063@pool.informatik.rwth-aachen.de> <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> <20111109142710.GA8565@pool.informatik.rwth-aachen.de> Message-ID: <20111109184544.GA3369@1und1.de> On Wed, Nov 09, 2011 at 03:27:10PM +0100, Diego Biurrun wrote: > On Wed, Nov 09, 2011 at 08:30:13AM +0100, Reimar D?ffinger wrote: > > I remember you complaining that people don't apply good programming > > principles to build systems, so this is a good point at applying the > > principle "independent stuff I different files" IMO. > > If only it were independent - it is not. Recursive make is always a bad > idea. I'm under the impression that you have not read the "Recursive > Make Considered Harmful" paper yet. Go right ahead, it's short and > sweet: > > http://miller.emu.id.au/pmiller/books/rmch/ That one suggests splitting make files and including them, which is exactly what I was arguing for here, so I do not follow your point. (though not putting it into the subdir and/or not calling it Makefile would be advisable). However it misses things that with including you still end up with a single variable name-space, so at least in that aspect you _still_ need to know the whole Makefile including everything it includes. I also slightly disagree with you line number argument: If you're new to a build system and need to change something the total number of lines matters almost as much as how many actually "do something useful". Btw. the median file size of .c files seems to be around 350 lines, so even by that measure the Makefile is larger. Either way you either make sure I know a way to fix it that you'd accept or could you consider doing it yourself? I could just go ahead, but I am too lazy to do something and risk you'll hate it :-P > > >> --- tests/faterun.sh (revision 0) > > >> +++ tests/faterun.sh (revision 0) > > >> @@ -0,0 +1,10 @@ > > >> +#!/bin/sh > > >> +i=$1 > > >> +echo "running $i" > > >> +mkdir -p res/$(dirname $i) > > >> +touch res/$i.md5 > > >> +../mplayer -noconfig all -lavdopts threads=4:bitexact -really-quiet -noconsolecontrols -nosound -benchmark -vo md5sum:outfile=res/$i.md5 $FATE_SAMPLES/$i > > >> +if ! diff -uw ref/$i.md5 res/$i.md5 ; then > > >> + mv res/$i.md5 res/$i.md5.bad > > >> + exit 1 > > >> +fi > > > > > > "i" is not really a better variable name than "1". > > > Also, a few empty lines could make this more readable. > > > > I had a loop in there originally and forgot to clean it up. > > I is still better since it's easier to change i=$1 to i=$2 for example > > than having to change it everywhere. > > Nah, I'm operating under the assumption that everybody is smart enough > for automatic search and replace around here :) That doesn't make the diff better. So a proper variable name I would consider the better solution. From diego at biurrun.de Thu Nov 10 00:00:37 2011 From: diego at biurrun.de (Diego Biurrun) Date: Thu, 10 Nov 2011 00:00:37 +0100 Subject: [MPlayer-dev-eng] [PATCH] Add fate test In-Reply-To: <20111109184544.GA3369@1und1.de> References: <20111106100410.GA16892@1und1.de> <20111109014318.GC14063@pool.informatik.rwth-aachen.de> <5C2B45A2-7B55-4DD8-97A8-409158F0488A@gmx.de> <20111109142710.GA8565@pool.informatik.rwth-aachen.de> <20111109184544.GA3369@1und1.de> Message-ID: <20111109230037.GA11688@pool.informatik.rwth-aachen.de> On Wed, Nov 09, 2011 at 07:45:44PM +0100, Reimar D?ffinger wrote: > On Wed, Nov 09, 2011 at 03:27:10PM +0100, Diego Biurrun wrote: > > On Wed, Nov 09, 2011 at 08:30:13AM +0100, Reimar D?ffinger wrote: > > > I remember you complaining that people don't apply good programming > > > principles to build systems, so this is a good point at applying the > > > principle "independent stuff I different files" IMO. > > > > If only it were independent - it is not. Recursive make is always a bad > > idea. I'm under the impression that you have not read the "Recursive > > Make Considered Harmful" paper yet. Go right ahead, it's short and > > sweet: > > > > http://miller.emu.id.au/pmiller/books/rmch/ > > That one suggests splitting make files and including them, which is > exactly what I was arguing for here, so I do not follow your point. You did not include your subdir Makefile, you called it recursively, that's a very decisive difference. My point here is that the stuff is not independent. You have a dependency on the mplayer binary in the subdirectory Makefile, but no way to build that dependency for example. There's only really two variants of one way to construct Makefiles: as a single monolithic Makefile (my design) or as snippets that get included and thus assembled into a monolithic Makefile at runtime (Mans' design). > (though not putting it into the subdir and/or not calling it Makefile > would be advisable). > However it misses things that with including you still end up with a > single variable name-space, so at least in that aspect you _still_ need > to know the whole Makefile including everything it includes. Yes. This is unavoidable - Make needs to "see the whole picture" in order to function properly. > I also slightly disagree with you line number argument: If you're new > to a build system and need to change something the total number of lines > matters almost as much as how many actually "do something useful". > Btw. the median file size of .c files seems to be around 350 lines, so > even by that measure the Makefile is larger. I know that it looks daunting due to its length, but once you realize that length does not equal complexity, it's quite manageable IMO. It's *much* shorter than its recursive predecessors combined. > Either way you either make sure I know a way to fix it that you'd accept > or could you consider doing it yourself? > I could just go ahead, but I am too lazy to do something and risk you'll > hate it :-P I'll look into it. Diego From onemda at gmail.com Thu Nov 10 03:19:41 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Thu, 10 Nov 2011 02:19:41 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling Message-ID: Hi, Some keys where not working and mouse was not supported at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: caca1.diff Type: text/x-diff Size: 2246 bytes Desc: not available URL: From rogerdpack2 at gmail.com Thu Nov 10 22:32:45 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Thu, 10 Nov 2011 14:32:45 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization Message-ID: Based off a patch from Patrick Dinh, this prevents mplayer from crashing when a direct3d window is minimized. http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-August/083097.html Feedback welcome, this is my first patch attempt. -roger- -------------- next part -------------- A non-text attachment was scrubbed... Name: direct3d_allow_minimization.diff Type: application/octet-stream Size: 1141 bytes Desc: not available URL: From rogerdpack2 at gmail.com Thu Nov 10 23:44:44 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Thu, 10 Nov 2011 15:44:44 -0700 Subject: [MPlayer-dev-eng] [PATCH] minor OSD fraction cleanups Message-ID: dont_round_up_decimals.diff: currently if the PTS timestamps come in as something like this: 1.95 1.997 2.03 The OSD fraction is displayed like this: 1.95 1.00 2.03 which is less than desirable. remove_apparently_inaccurate_comment.diff: I could not understand why it would be called "fallback on the timer" since we're not falling back, we're using the only thing we have, AFAIK. I wasn't as sure on this one. Feedback welcome. -roger- -------------- next part -------------- A non-text attachment was scrubbed... Name: dont_round_up_decimals.diff Type: application/octet-stream Size: 644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_apparently_inaccurate_comment.diff Type: application/octet-stream Size: 371 bytes Desc: not available URL: From rogerdpack2 at gmail.com Fri Nov 11 00:21:39 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Thu, 10 Nov 2011 16:21:39 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix OSD decimal output for dvdnav Message-ID: Hello. Apologies for the flood. Anyway, currently with the OSD decimal output, it gets the "second" portion from demuxer_get_current_time (the NAV packets) and gets the "decimal portion" of the output from sh_video->pts. Since these don't match with DVD's (the NAV packets only occur every 0.5s, and are usually about 0.1s "off" the MPEG timestamps), it can lead to odd OSD output, for example: $ mplayer dvdnav://1 -osd-fractions 1 -osdlevel 2 OSD output: ... 00:00:04.04 00:00:04.08 00:00:04.12 00:00:04.16 00:00:04.20 00:00:04.24 00:00:04.29 00:00:04.33 00:00:05.37 # note the shift here... 00:00:05.41 00:00:05.45 00:00:05.50 00:00:05.55 00:00:05.60 00:00:05.65 00:00:05.70 00:00:05.75 00:00:05.80 00:00:05.84 00:00:05.90 00:00:05.95 00:00:05.99 00:00:05.04 # shift again, because the two are offset. ... [repeat] Also if there has been a timestamp reset ever, it leads to even odder output numbers, like 01:20:05.-8 displayed in the OSD. This patch makes the OSD "monotonically increase" and doesn't seem to hurt other stream types. For dvdnav, it now outputs the equivalent of: ... 00:00:00.40 00:00:00.40 00:00:00.40 00:00:00.40 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:00.80 00:00:01.20 00:00:01.20 ... which, though less precise, seems more accurate (and works past reset's et al). My hope is to (should these patches eventually be applied) submit another diff that makes these timestamps even more accurate, but this would is an improvement, at least from my perspective. I also am considering another similar patch for EDL timestamps checking, so that EDL's can work with dvdnav (esp. past any MPEG PTs resets). Feedback welcome. Thanks. -roger- -------------- next part -------------- A non-text attachment was scrubbed... Name: show_correct_osd_fractions_for_dvdnav.diff Type: application/octet-stream Size: 3739 bytes Desc: not available URL: From rogerdpack2 at gmail.com Fri Nov 11 20:21:21 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Fri, 11 Nov 2011 12:21:21 -0700 Subject: [MPlayer-dev-eng] [PATCH] return hopefully correct value from dvdnav::seek Message-ID: $subj I think returning 0 is right here... -roger- -------------- next part -------------- A non-text attachment was scrubbed... Name: return_error_response_on_fail_dvdnav_seek.diff Type: application/octet-stream Size: 425 bytes Desc: not available URL: From eclipse7 at gmx.net Sat Nov 12 14:31:10 2011 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sat, 12 Nov 2011 14:31:10 +0100 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: References: Message-ID: <20111112133110.GA3151@tane> Hi! Roger Pack wrote: > Based off a patch from Patrick Dinh, this prevents mplayer from > crashing when a direct3d window is minimized. > > http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-August/083097.html I could reproduce this: 1. activate OSD or subtitles 2. minimize the video window => segfault I also can confirm that the crash goes away with your patch applied. > Feedback welcome, this is my first patch attempt. I am not familiar enough with vo direct3d to tell you if the patch is a correct solution. The whole OSD rendering mechanism in vo direct3d was a bit to complex for me to grasp immediately. But at the very least the comments are inaccurate after your patch is applied. This in itself is a rather bad sign. Therefore the patch should not be committed as is. How would you modify the comments after your change? No need to change the patches yet! Just write us how you would extend the comments. Thanks for your work! Alexander From rogerdpack2 at gmail.com Sat Nov 12 16:12:49 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Sat, 12 Nov 2011 08:12:49 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: <20111112133110.GA3151@tane> References: <20111112133110.GA3151@tane> Message-ID: > ?I am not familiar enough with vo direct3d to tell you if the patch > is a correct solution. The whole OSD rendering mechanism in vo direct3d > was a bit to complex for me to grasp immediately. > > ?But at the very least the comments are inaccurate after your patch is > applied. This in itself is a rather bad sign. Therefore the patch should > not be committed as is. > > ?How would you modify the comments after your change? No need to change > the patches yet! Just write us how you would extend the comments. Hmm. After looking a bit more closely, I think maybe only the last "3rd" of the commit is probably needed. So...I would modify that and I guess leave the comments the same [?] @@ -1029,7 +1029,7 @@ static void draw_osd(void) { // we can not render OSD if we lost the device e.g. because it was uncooperative - if (!priv->d3d_device) + if (!priv->d3d_device || !priv->d3d_texture_osd) return; if (vo_osd_changed(0)) { From eclipse7 at gmx.net Sat Nov 12 18:27:49 2011 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sat, 12 Nov 2011 18:27:49 +0100 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: References: <20111112133110.GA3151@tane> Message-ID: <20111112172749.GA3169@tane> Hi, Roger Pack wrote: > > ?I am not familiar enough with vo direct3d to tell you if the patch > > is a correct solution. The whole OSD rendering mechanism in vo direct3d > > was a bit to complex for me to grasp immediately. > > > > ?But at the very least the comments are inaccurate after your patch is > > applied. This in itself is a rather bad sign. Therefore the patch should > > not be committed as is. > > > > ?How would you modify the comments after your change? No need to change > > the patches yet! Just write us how you would extend the comments. > > Hmm. > After looking a bit more closely, I think maybe only the last "3rd" of > the commit is probably needed. > So...I would modify that and I guess leave the comments the same [?] > > @@ -1029,7 +1029,7 @@ > static void draw_osd(void) > { > // we can not render OSD if we lost the device e.g. because it > was uncooperative > - if (!priv->d3d_device) > + if (!priv->d3d_device || !priv->d3d_texture_osd) > return; This comment is not worded the same as the others, but I think it conveys the same meaning. So this would only reduce the number of problem instances to one but the comment would still have to be changed. I looked a bit deeper, so here comes my analysis: If the window is minimized the VO gets a resize event. When handling the resize event, vo direct3d destroys the osd textures and creates them again with a size fitting the new window size. This works well normally, but fails in case of minimization because then the sizes are 0 and the texture creation fails. This causes the crash later when draw_osd() gets invoked. I did not think about a proper solution yet. Alexander From rogerdpack2 at gmail.com Sat Nov 12 22:09:28 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Sat, 12 Nov 2011 14:09:28 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: <20111112172749.GA3169@tane> References: <20111112133110.GA3151@tane> <20111112172749.GA3169@tane> Message-ID: > This comment is not worded the same as the others, but I think > it conveys the same meaning. So this would only reduce the number > of problem instances to one but the comment would still have to be > changed. > > I looked a bit deeper, so here comes my analysis: > > If the window is minimized the VO gets a resize event. When > handling the resize event, vo direct3d destroys the osd textures > and creates them again with a size fitting the new window size. > > This works well normally, but fails in case of minimization > because then the sizes are 0 and the texture creation fails. > This causes the crash later when draw_osd() gets invoked. > > I did not think about a proper solution yet. Thanks for your attention to this, looking forward to a fix (or we could just use that patch as a work around or the like). -r From eclipse7 at gmx.net Sun Nov 13 15:17:45 2011 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sun, 13 Nov 2011 15:17:45 +0100 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: References: <20111112133110.GA3151@tane> <20111112172749.GA3169@tane> Message-ID: <20111113141745.GA6469@tane> Hi Roger Pack wrote: > Alexander Strasser wrote: [...] > > If the window is minimized the VO gets a resize event. When > > handling the resize event, vo direct3d destroys the osd textures > > and creates them again with a size fitting the new window size. > > > > This works well normally, but fails in case of minimization > > because then the sizes are 0 and the texture creation fails. > > This causes the crash later when draw_osd() gets invoked. > > > > I did not think about a proper solution yet. > > Thanks for your attention to this, looking forward to a fix (or we > could just use that patch as a work around or the like). I think the attached patch would be OK as a proper fix for the problem. There could be other issues in certain corner cases, but they were there before (if I did not make any mistake in my patch). I tested it while developing. Would be great if you or any other users of vo direct3d could test it too and confirm it fixes the issue and that it does not introduce regressions. If I hear no comlaints or objections from other developers I will apply this in a few days. I pinged the maintainer already, but got no reply yet. Still I think it is rather important to have this fixed soon. (It is annoying if you can't minimize a video window because a sub might be shown and it would crash). Alexander -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer-vo_direct3d_osd_when_minimized.diff Type: text/x-diff Size: 903 bytes Desc: not available URL: From Dan.Oscarsson at tieto.com Sun Nov 13 19:24:35 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sun, 13 Nov 2011 19:24:35 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed Message-ID: <1321208675.6469.23.camel@luna.malmo.kicore.net> Do not know if this patch was lost but it is needed to get h264 data in mpeg_ts demuxed streams to work correctly. Without it the pts values are not in order. I suspect that h264 encoded data in other demuxers would also not be in order without it. It works fine for me and a friend who watches a lot of DVB-T streams. If you want to split it into two parts, the if statement starting with: + // if many incomplete frames, keep only delay values + if (!got_picture && sh_video->num_buffered_pts >= delay) could be separate as it is to fix so a sequence of bad frames do not result in oldest pts value used for first valid frame. This can happen in a DVB-T h264 stream which starts with a lot of partial frames. If this is not good, we need to get pts values in order in some other way to be able to play h264 in mpeg_ts good. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: reorder.patch Type: text/x-patch Size: 1519 bytes Desc: not available URL: From diego at biurrun.de Mon Nov 14 11:01:33 2011 From: diego at biurrun.de (Diego Biurrun) Date: Mon, 14 Nov 2011 11:01:33 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <20111109012825.GB14063@pool.informatik.rwth-aachen.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> <20111104155725.GA2925@1und1.de> <20111108081535.GA8975@pool.informatik.rwth-aachen.de> <4EB8FC18.7060600@ladisch.de> <20111109012825.GB14063@pool.informatik.rwth-aachen.de> Message-ID: <20111114100133.GA2650@pool.informatik.rwth-aachen.de> On Wed, Nov 09, 2011 at 02:28:26AM +0100, Diego Biurrun wrote: > On Tue, Nov 08, 2011 at 10:53:28AM +0100, Clemens Ladisch wrote: > > > On Fri, Nov 04, 2011 at 04:57:25PM +0100, Reimar D?ffinger wrote: > > > > On Thu, Nov 03, 2011 at 11:06:15PM +0100, Diego Biurrun wrote: > > > > > I looked into the baroque ALSA check in configure and noticed that we > > > > > support ALSA versions from 2000 (last 0.5 release) and 2003 (last 0.9 > > > > > release). While maintaining compatibility and such is all nice and > > > > > great a decade sounds like the timeframe when one can safely eliminate > > > > > cruft. > > > > > > > > > > Am I overlooking something non-obvious about systems without ALSA > > > > > versions from at least 2003 (first 1.0 release)? > > > > There really isn't much difference between 0.9* and 1.0; there weren't > > any big technical reasons for the version change. There was a small > > API change, but the libraries are binary compatible (as long as no > > newer APIs are used). > > > > OTOH, 0.5 was a completely different API and considered somewhat of > > a prototype. > > > > All 0.9/1.0 alsa-lib and kernel versions should be compatible; I think > > it somewhat unlikely that somebody would use a new mplayer without > > being able to update alsa-lib. > > > > It should be noted that ao_alsa.c uses some functions introduced in > > 0.9.0rc4, which was after the move to alsa/, so > > support can be dropped. > > > > > > The ais on the other hand someone thought it a good idea to duplicate > > > > the whole file because of what essentially is 7 lines difference. > > > > With "#define ALSA_PCM_NEW_*_API", ai_alsa1x.c can be used for both. > > > > With these defines (and with 0.5 dropped), no version check is needed > > in configure. > > I say go right ahead and implement it. I went ahead, all the complexity is gone now, which is nice - configure should also run noticeably faster now. That said, the ALSA check in configure is not very smart right now, it just checks that alsa/asoundlib is available and that we can link with -lasoundlib. If there is a way to detect unsuitable 0.9 versions, I'm all ears. Diego From clemens at ladisch.de Mon Nov 14 13:03:01 2011 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon, 14 Nov 2011 13:03:01 +0100 Subject: [MPlayer-dev-eng] supported ALSA versions In-Reply-To: <20111114100133.GA2650@pool.informatik.rwth-aachen.de> References: <20111103220615.GA19631@pool.informatik.rwth-aachen.de> <20111104155725.GA2925@1und1.de> <20111108081535.GA8975@pool.informatik.rwth-aachen.de> <4EB8FC18.7060600@ladisch.de> <20111109012825.GB14063@pool.informatik.rwth-aachen.de> <20111114100133.GA2650@pool.informatik.rwth-aachen.de> Message-ID: <4EC10375.2090104@ladisch.de> Diego Biurrun wrote: > That said, the ALSA check in configure is not very smart right now, it > just checks that alsa/asoundlib is available and that we can link with > -lasoundlib. If there is a way to detect unsuitable 0.9 versions, I'm > all ears. 0.9.0rc4 or later would be: SND_LIB_VERSION > 0x000900 || (SND_LIB_VERSION == 0x000900 && SND_LIB_EXTRAVER >= 100004) I'm not sure if you want to make the -lasound check more robust; detecting inconsistent header/library versions is probably not the purpose of configure. Regards, Clemens From rogerdpack2 at gmail.com Mon Nov 14 19:25:07 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Mon, 14 Nov 2011 11:25:07 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: <20111113141745.GA6469@tane> References: <20111112133110.GA3151@tane> <20111112172749.GA3169@tane> <20111113141745.GA6469@tane> Message-ID: > ?I tested it while developing. Would be great if you or any other > users of vo direct3d could test it too and confirm it fixes the > issue and that it does not introduce regressions. Seems to work fine, and also doesn't spit any warnings out to the console on minimization, which is nice :) From czf86123 at gmail.com Tue Nov 15 16:46:58 2011 From: czf86123 at gmail.com (Zhaofei Chen) Date: Tue, 15 Nov 2011 16:46:58 +0100 Subject: [MPlayer-dev-eng] Question about buffer when doing RTSP audio streaming with Live555 libraries Message-ID: Hello, I'm developing something related to real-time audio streaming and I use MPlayer with Live555 libraries to enable RTSP streaming features. Here is the problem that I observe: When a MP3 audio file is streamed, MPlayer starts to play immediately after receiving RTP packets. However, if other data formats, such as raw PCM audio data, AMR, WAV files are streamed, MPlayer will starts to play only after receiving a certain amount of data. Based on my understanding, there should be a buffer which is used for those audio formats, except MP3 files, and MPlayer will starts to play after this buffer is filled with data. I checked the source code but I'm not sure if this buffer means the stream cache (default size 2048) since there is a setting of STREAM_NON_CACHEABLE in stream_live555.c (though it is a hack). So here are my questions: 1. I would like to ask what could this buffer be and why it acts differently with MP3 and other audio formats. 2. Is this buffer changeable since my application will suffer from the delay time caused by this buffer. Thanks! Regards, Zhaofei Chen From nicolas.george at normalesup.org Tue Nov 15 18:59:49 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Tue, 15 Nov 2011 18:59:49 +0100 Subject: [MPlayer-dev-eng] [PATCH] minor OSD fraction cleanups In-Reply-To: References: Message-ID: <20111115175949.GA13251@phare.normalesup.org> Le decadi 20 brumaire, an CCXX, Roger Pack a ?crit?: > dont_round_up_decimals.diff: Applied (also bringing the % 100 from the next line). Although, your other patch, which covers part of the code I do not know enough, changes demuxer_get_current_time to return a floating-point PTS: if it is applied, a more elegant solution can be devised. > remove_apparently_inaccurate_comment.diff: > I could not understand why it would be called "fallback on the > timer" since we're not falling back, we're using the only thing we > have, AFAIK. > I wasn't as sure on this one. The way I understand it is: we do not have anything interesting to display, so we fall back to displaying just the time in the movie. The comment is very laconic, but it seems true. Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rogerdpack2 at gmail.com Tue Nov 15 20:04:39 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Tue, 15 Nov 2011 12:04:39 -0700 Subject: [MPlayer-dev-eng] [PATCH] minor OSD fraction cleanups In-Reply-To: <20111115175949.GA13251@phare.normalesup.org> References: <20111115175949.GA13251@phare.normalesup.org> Message-ID: > Applied (also bringing the % 100 from the next line). > > Although, your other patch, which covers part of the code I do not know > enough, changes demuxer_get_current_time to return a floating-point PTS: if > it is applied, a more elegant solution can be devised. Good point. I guess I just split them up because they "could" be committed separately, so be considered different patches :) >> ? I wasn't as sure on this one. > > The way I understand it is: we do not have anything interesting to display, > so we fall back to displaying just the time in the movie. The comment is > very laconic, but it seems true. Ahh gotcha. Maybe it could be made a bit more verbose in the future. Thanks! -roger- From diego at biurrun.de Wed Nov 16 12:44:58 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 16 Nov 2011 12:44:58 +0100 Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib In-Reply-To: <20110920181954.GA32134@1und1.de> References: <20110920181954.GA32134@1und1.de> Message-ID: <20111116114458.GA11607@pool.informatik.rwth-aachen.de> On Tue, Sep 20, 2011 at 08:19:54PM +0200, Reimar D?ffinger wrote: > I am still interested in seeing performance numbers and statistics from > ffmp3 vs. mp3lib when ffmp3 is slower, but I guess it's time to start > some more specific moves to get rid of it. Was there ever some sort or progress or decision about this? I stumbled across this again because I was looking into an old bug report on Bugzilla about the -flto gcc flag: http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1695 mp3lib fails to compile with that flag, gcc runs out of registers. I did not investigate in much detail nor try other gcc version apart from the 4.5 variant I happened to have installed. Note that vf_fspp causes linking errors with -flto, mp3lib is not the only problem. Diego From zongyao.qu at gmail.com Wed Nov 16 15:30:18 2011 From: zongyao.qu at gmail.com (Zongyao Qu) Date: Wed, 16 Nov 2011 14:30:18 +0000 (UTC) Subject: [MPlayer-dev-eng] Add Mac OS X for hw acceleration support Message-ID: Sorry for the duplicated thread on the user-list. But there was no one replying, so I think maybe I should post it here. I found FFmpeg started to support VDA framework, which is a HW accelerating framework for H264 decoding on Mac OS X. I want to add it to mplayer, but I don't know how. If there is anyone who could give me some hints on such thing, it will be deeply appreciate. Thank you. From rogerdpack2 at gmail.com Wed Nov 16 18:30:16 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 16 Nov 2011 10:30:16 -0700 Subject: [MPlayer-dev-eng] [PATCH] update directx7 contrib URL's Message-ID: Appears that for some reason, only the english version was updated to a working URL. This patch attempts to remedy that. -roger- -------------- next part -------------- A non-text attachment was scrubbed... Name: update_directx_url_nonenglish.diff Type: application/octet-stream Size: 3957 bytes Desc: not available URL: From rogerdpack2 at gmail.com Wed Nov 16 19:15:35 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 16 Nov 2011 11:15:35 -0700 Subject: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing? In-Reply-To: References: Message-ID: No response from mplayer-users, so forwarding it on here, as I know some "knowledgeable" people on the subject sometimes hang out here... ---------- Forwarded message ---------- Hello. I notice when using dvdnav:// this warning message: Remember to disable MPlayer's cache when playing dvdnav:// streams (adding -nocache to your command line) so I do :) Also I notice in stream_dvdnav.c: ?/* turn off dvdnav caching */ ?dvdnav_set_readahead_flag(priv->dvdnav, 0); My question is...why is this needed? Anybody know why? VLC seems to enable its internal cacheing, and also has some external caching for it ( --dvdnav-caching= [300ms is the default]) ?dvdnav_set_readahead_flag( p_sys->dvdnav, DVD_READ_CACHE /* == 1 */ ) Anybody know the motivation for turning it off in mplayer, and/or to have to use -nocache with it still? Thanks! -roger- From rogerdpack2 at gmail.com Wed Nov 16 23:06:27 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 16 Nov 2011 15:06:27 -0700 Subject: [MPlayer-dev-eng] suggestion: svn external libdvdcss? Message-ID: I've noticed that libdvdcss has had some changes since 1.2.10, some needed for a few DVD's: http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-October/083551.html (synopsis: I think it was necessary to have TRUNK in order to play a few DVD's well). Perhaps it should be made into an svn:external (or version bumped)? Anyway just pointing it out. Thanks! -roger- From alexander at roalter.it Thu Nov 17 00:23:43 2011 From: alexander at roalter.it (Alexander Roalter) Date: Thu, 17 Nov 2011 00:23:43 +0100 Subject: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing? In-Reply-To: References: Message-ID: <4EC445FF.2080807@roalter.it> On 11/16/2011 07:15 PM, Roger Pack wrote: > No response from mplayer-users, so forwarding it on here, as I know > some "knowledgeable" people on the subject sometimes hang out here... > > ---------- Forwarded message ---------- > > Hello. > I notice when using dvdnav:// this warning message: > > Remember to disable MPlayer's cache when playing dvdnav:// streams > (adding -nocache to your command line) > > so I do :) > > Also I notice in > > stream_dvdnav.c: > > /* turn off dvdnav caching */ > dvdnav_set_readahead_flag(priv->dvdnav, 0); > > My question is...why is this needed? Anybody know why? > > VLC seems to enable its internal cacheing, and also has some external > caching for it ( --dvdnav-caching= [300ms is the default]) > > dvdnav_set_readahead_flag( p_sys->dvdnav, DVD_READ_CACHE /* == 1 */ ) > > Anybody know the motivation for turning it off in mplayer, and/or to > have to use -nocache with it still? > Thanks! As far as I can remember, Nico once said the -nocache is no more explicitly needed with dvdnav, but I could be wrong. Also, the text is displayed irregardless of the option taken, so it shows with or without -nocache (which is a bit annoying) I simply commented that line out... -- Cheers, Alex From rogerdpack2 at gmail.com Thu Nov 17 00:41:51 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 16 Nov 2011 16:41:51 -0700 Subject: [MPlayer-dev-eng] [PATCH] minor OSD fraction cleanups In-Reply-To: <20111115175949.GA13251@phare.normalesup.org> References: <20111115175949.GA13251@phare.normalesup.org> Message-ID: > Although, your other patch, which covers part of the code I do not know > enough, changes demuxer_get_current_time to return a floating-point PTS: if > it is applied, a more elegant solution can be devised. The "other" patch also allows for other interesting follow-up patches, like being able to use EDL's on DVD's past MPEG PTS timestamp resets accurately: https://gist.github.com/1371781 Thanks for your help here. -roger- From nicola.sabbi at poste.it Thu Nov 17 16:36:21 2011 From: nicola.sabbi at poste.it (Nico Sabbi) Date: Thu, 17 Nov 2011 16:36:21 +0100 Subject: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing? In-Reply-To: <4EC445FF.2080807@roalter.it> References: <4EC445FF.2080807@roalter.it> Message-ID: <4EC529F5.7060207@poste.it> Alexander Roalter ha scritto: > > As far as I can remember, Nico once said the -nocache is no more > explicitly needed with dvdnav, but I could be wrong. > Also, the text is displayed irregardless of the option taken, so it > shows with or without -nocache (which is a bit annoying) I simply > commented that line out... > Long time ago Reimar patched mplayer to permit the caching of dvdnav streams, but mplayer's caching is a totally different thing from dvdnav's caching. IIRC setting the readahead flag in dvdnav caused all sorts of problems at the time. Maybe the two are no more incompatible, but too many years (and tears) have passed, I don't know. From rogerdpack2 at gmail.com Thu Nov 17 17:51:33 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Thu, 17 Nov 2011 09:51:33 -0700 Subject: [MPlayer-dev-eng] Fwd: enable libdvdnav cacheing? In-Reply-To: <4EC529F5.7060207@poste.it> References: <4EC445FF.2080807@roalter.it> <4EC529F5.7060207@poste.it> Message-ID: > Long time ago Reimar patched mplayer to permit the caching of dvdnav > streams, > but mplayer's caching is a totally different thing from dvdnav's caching. > IIRC setting the readahead flag in dvdnav caused all sorts of problems at > the time. > Maybe the two are no more incompatible, but too many years (and tears) have > passed, > I don't know. Ok thanks for the response! -r From onemda at gmail.com Thu Nov 17 21:37:59 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Thu, 17 Nov 2011 20:37:59 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: Message-ID: ping From ib at wupperonline.de Fri Nov 18 16:06:37 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Fri, 18 Nov 2011 16:06:37 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue Message-ID: <4ec677fd.7270f7f4.bm000@wupperonline.de> Today I refreshed my mplayer build (with a new copy of ffmepg - the last one was approx. one month old). Now, all of a sudden there are sound issues. If I let mplayer choose the codec, it selects ffmp3float and there is no sound but only occasional crackles. If I force -afm mp3lib, everything's fine. Was there a change in ffmepg? (I assume that the problem results from there.) Ingo From rogerdpack2 at gmail.com Fri Nov 18 16:26:39 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Fri, 18 Nov 2011 08:26:39 -0700 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec677fd.7270f7f4.bm000@wupperonline.de> References: <4ec677fd.7270f7f4.bm000@wupperonline.de> Message-ID: > Today I refreshed my mplayer build (with a new copy of ffmepg - the last one > was approx. one month old). > > Now, all of a sudden there are sound issues. If I let mplayer choose the > codec, it selects ffmp3float and there is no sound but only occasional > crackles. If I force -afm mp3lib, everything's fine. maybe a reconfigure and/or make clean would help? -r From ib at wupperonline.de Fri Nov 18 16:34:44 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Fri, 18 Nov 2011 16:34:44 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: Message-ID: <4ec67b16.441ad3d5.bm000@wupperonline.de> Roger Pack wrote on Fri, 18 Nov 2011 08:26:39 -0700: >> Now, all of a sudden there are sound issues. If I let mplayer choose the >> codec, it selects ffmp3float and there is no sound but only occasional >> crackles. If I force -afm mp3lib, everything's fine. > maybe a reconfigure and/or make clean would help? It is a completely new build, i.e. fresh copies of (only) the source files, configure, make and make install. Ingo From tempn at twmi.rr.com Fri Nov 18 17:47:39 2011 From: tempn at twmi.rr.com (compn) Date: Fri, 18 Nov 2011 11:47:39 -0500 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec677fd.7270f7f4.bm000@wupperonline.de> References: <4ec677fd.7270f7f4.bm000@wupperonline.de> Message-ID: <20111118114739.a030f139.tempn@twmi.rr.com> On Fri, 18 Nov 2011 16:06:37 +0100, Ingo Br?ckl wrote: >Today I refreshed my mplayer build (with a new copy of ffmepg - the last one >was approx. one month old). i wonder if you have an old codecs.conf lying around? could you paste mplayer -v file.mp3 output ? >Now, all of a sudden there are sound issues. If I let mplayer choose the >codec, it selects ffmp3float and there is no sound but only occasional >crackles. If I force -afm mp3lib, everything's fine. > >Was there a change in ffmepg? (I assume that the problem results from there.) ffmp3float used to garble audio for me, but it was fixed long ago. i havent tested latest svn. does -af resample=44100 or 48000 have any effect? -compn From Reimar.Doeffinger at gmx.de Fri Nov 18 18:17:22 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Fri, 18 Nov 2011 18:17:22 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: Message-ID: <20111118171722.GC2343@1und1.de> On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > + case CACA_KEY_F1: > + case CACA_KEY_F2: > + case CACA_KEY_F3: > + case CACA_KEY_F4: > + case CACA_KEY_F5: > + case CACA_KEY_F6: > + case CACA_KEY_F7: > + case CACA_KEY_F8: > + case CACA_KEY_F9: > + case CACA_KEY_F10: > + case CACA_KEY_F11: > + case CACA_KEY_F12: > + case CACA_KEY_F13: > + case CACA_KEY_F14: > + case CACA_KEY_F15: > + mplayer_put_key(KEY_F + key - 0x119); Did you mean - CACA_KEY_F1? That hard-coded 0x119 seems like a really bad idea. Looks good to me otherwise, except that the issue that at most one even is processed per check_events call still remains. From ib at wupperonline.de Fri Nov 18 18:26:55 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Fri, 18 Nov 2011 18:26:55 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111118114739.a030f139.tempn@twmi.rr.com> Message-ID: <4ec69561.3b3ef556.bm000@wupperonline.de> compn wrote on Fri, 18 Nov 2011 11:47:39 -0500: > On Fri, 18 Nov 2011 16:06:37 +0100, Ingo Br?ckl wrote: >>Today I refreshed my mplayer build (with a new copy of ffmepg - the last one >>was approx. one month old). > i wonder if you have an old codecs.conf lying around? Nope. I'm always using the built-in one. > could you paste mplayer -v file.mp3 output ? Attached. >>Now, all of a sudden there are sound issues. If I let mplayer choose the >>codec, it selects ffmp3float and there is no sound but only occasional >>crackles. If I force -afm mp3lib, everything's fine. >> >>Was there a change in ffmepg? (I assume that the problem results from there.) > ffmp3float used to garble audio for me, but it was fixed long ago. i > havent tested latest svn. does -af resample=44100 or 48000 have any > effect? No effect with resample. I'm not sure whether ffmp3float was the chosen codec with my previous builds, but I guess so, because I haven't changed anything. I'm just regularly updating mplayer from my svn copy and once a month or so (or earlier if there is a change in mp_taglists.c) ffmpeg. Never had a problem so far. Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer.output Type: application/octet-stream Size: 4677 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Fri Nov 18 18:31:37 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Fri, 18 Nov 2011 18:31:37 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec69561.3b3ef556.bm000@wupperonline.de> References: <20111118114739.a030f139.tempn@twmi.rr.com> <4ec69561.3b3ef556.bm000@wupperonline.de> Message-ID: <20111118173137.GA4271@1und1.de> On Fri, Nov 18, 2011 at 06:26:55PM +0100, Ingo Br?ckl wrote: > compn wrote on Fri, 18 Nov 2011 11:47:39 -0500: > > > On Fri, 18 Nov 2011 16:06:37 +0100, Ingo Br?ckl wrote: > >>Today I refreshed my mplayer build (with a new copy of ffmepg - the last one > >>was approx. one month old). > > > i wonder if you have an old codecs.conf lying around? > > Nope. I'm always using the built-in one. > > > could you paste mplayer -v file.mp3 output ? > > Attached. Hm, it outputs float directly to ALSA, maybe ALSA incorrectly thinks your soundcard supports that (did you have a recent ALSA/kernel update that might have broken it)? Try forcing conversion with -af format=s16le From Reimar.Doeffinger at gmx.de Fri Nov 18 18:35:02 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Fri, 18 Nov 2011 18:35:02 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111118173137.GA4271@1und1.de> References: <20111118114739.a030f139.tempn@twmi.rr.com> <4ec69561.3b3ef556.bm000@wupperonline.de> <20111118173137.GA4271@1und1.de> Message-ID: <20111118173502.GA4295@1und1.de> On Fri, Nov 18, 2011 at 06:31:37PM +0100, Reimar D?ffinger wrote: > On Fri, Nov 18, 2011 at 06:26:55PM +0100, Ingo Br?ckl wrote: > > compn wrote on Fri, 18 Nov 2011 11:47:39 -0500: > > > > > On Fri, 18 Nov 2011 16:06:37 +0100, Ingo Br?ckl wrote: > > >>Today I refreshed my mplayer build (with a new copy of ffmepg - the last one > > >>was approx. one month old). > > > > > i wonder if you have an old codecs.conf lying around? > > > > Nope. I'm always using the built-in one. > > > > > could you paste mplayer -v file.mp3 output ? > > > > Attached. > > Hm, it outputs float directly to ALSA, maybe ALSA incorrectly thinks > your soundcard supports that (did you have a recent ALSA/kernel update > that might have broken it)? Try forcing conversion with > -af format=s16le And try -ao pcm. Bonus points for expanding tests/Makefile to be able to test audio while you're at it :-P (Which reminds me: Diego, I'll happily do my best to clean that up, make it non-recursive etc. if you don't have time. You just have to live with that it's probably not as good as you could do it even with not too much effort). From ib at wupperonline.de Fri Nov 18 18:44:17 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Fri, 18 Nov 2011 18:44:17 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111118173137.GA4271@1und1.de> Message-ID: <4ec69da2.27317990.bm000@wupperonline.de> Reimar D?ffinger wrote on Fri, 18 Nov 2011 18:31:37 +0100: > On Fri, Nov 18, 2011 at 06:26:55PM +0100, Ingo Br?ckl wrote: >> compn wrote on Fri, 18 Nov 2011 11:47:39 -0500: >> >> > On Fri, 18 Nov 2011 16:06:37 +0100, Ingo Br?ckl wrote: >> >>Today I refreshed my mplayer build (with a new copy of ffmepg - the last one >> >>was approx. one month old). >> >> > could you paste mplayer -v file.mp3 output ? >> >> Attached. > Hm, it outputs float directly to ALSA, maybe ALSA incorrectly thinks > your soundcard supports that (did you have a recent ALSA/kernel update > that might have broken it)? No, I was very inactive recently and only updated wine since my last mplayer build. > Try forcing conversion with -af format=s16le No change. These are the outputs for: -afm mp3lib ========================================================================== Erzwungener Audiocodec: hwac3 Versuche Audiocodecfamilie mp3lib zu erzwingen... ?ffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 44100 Hz, 2 ch, s16le, 96.0 kbit/6.80% (ratio: 12000->176400) Ausgew?hlter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) no option at all ========================================================================== Erzwungener Audiocodec: hwac3 ?ffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 96.0 kbit/3.40% (ratio: 12000->352800) Ausgew?hlter Audiocodec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) ========================================================================== AO: [alsa] 44100Hz 2ch floatle (4 bytes per sample) -af format=s16le ========================================================================== Erzwungener Audiocodec: hwac3 ?ffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 96.0 kbit/3.40% (ratio: 12000->352800) Ausgew?hlter Audiocodec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) ========================================================================== AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) > And try -ao pcm. Hmm, that very quickly did play nothing. The dumped file sounds broken as well. -ao pcm ========================================================================== Erzwungener Audiocodec: hwac3 ?ffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 96.0 kbit/3.40% (ratio: 12000->352800) Ausgew?hlter Audiocodec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) ========================================================================== [AO PCM] Datei: audiodump.wav (WAVE) PCM: Samplerate: 44100Hz Kan?le: Stereo Format floatle [AO PCM] Info: Das Anlegen von Dump-Dateien wird am schnellsten mit -benchmark -vc null -vo null -ao pcm:fast erreicht. [AO PCM] Info: Um WAVE-Dateien zu schreiben, benutze -ao pcm:waveheader (Standard). AO: [pcm] 44100Hz 2ch floatle (4 bytes per sample) > Bonus points for expanding tests/Makefile to be able to test audio > while you're at it :-P I haven't had time yet to look at it and see what this is all about and how it works. Ingo From tempn at twmi.rr.com Fri Nov 18 19:10:22 2011 From: tempn at twmi.rr.com (compn) Date: Fri, 18 Nov 2011 13:10:22 -0500 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec69561.3b3ef556.bm000@wupperonline.de> References: <20111118114739.a030f139.tempn@twmi.rr.com> <4ec69561.3b3ef556.bm000@wupperonline.de> Message-ID: <20111118131022.eaa17398.tempn@twmi.rr.com> On Fri, 18 Nov 2011 18:26:55 +0100, Ingo Br?ckl wrote: >[mp3float @ 0xb75c2240]err{or,}_recognition separate: 1; 1 >[mp3float @ 0xb75c2240]err{or,}_recognition combined: 1; 1 could be the source of your problems. people have been messing with mp3float decoder, history: http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/mpegaudiodec_float.c;h=a0bc7696bf7262f2fce847e4bc6a86da3cd76508;hb=HEAD so if you want you can bisect and find out where it broke? -compn From onemda at gmail.com Fri Nov 18 23:17:13 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Fri, 18 Nov 2011 22:17:13 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: <20111118171722.GC2343@1und1.de> References: <20111118171722.GC2343@1und1.de> Message-ID: On 11/18/11, Reimar Doeffinger wrote: > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> + case CACA_KEY_F1: >> + case CACA_KEY_F2: >> + case CACA_KEY_F3: >> + case CACA_KEY_F4: >> + case CACA_KEY_F5: >> + case CACA_KEY_F6: >> + case CACA_KEY_F7: >> + case CACA_KEY_F8: >> + case CACA_KEY_F9: >> + case CACA_KEY_F10: >> + case CACA_KEY_F11: >> + case CACA_KEY_F12: >> + case CACA_KEY_F13: >> + case CACA_KEY_F14: >> + case CACA_KEY_F15: >> + mplayer_put_key(KEY_F + key - 0x119); > > Did you mean - CACA_KEY_F1? That hard-coded 0x119 > seems like a really bad idea. > Looks good to me otherwise, except that the issue that > at most one even is processed per check_events call still > remains. Fixed both issues. Additionaly caca1x.diff stop pointless dither recreation calls on resize. -------------- next part -------------- A non-text attachment was scrubbed... Name: caca1.diff Type: text/x-diff Size: 7609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: caca1x.diff Type: text/x-diff Size: 8750 bytes Desc: not available URL: From onemda at gmail.com Fri Nov 18 23:43:36 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Fri, 18 Nov 2011 22:43:36 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> Message-ID: On 11/18/11, Paul B. Mahol wrote: > Additionaly caca1x.diff stop pointless dither recreation calls on resize. > Oh, this one probably introduce memory leak, but it is easy to fix it by just adding caca_free_dither(dither); above caca_create_dither(..) in config() function. From eclipse7 at gmx.net Sat Nov 19 15:14:07 2011 From: eclipse7 at gmx.net (aru) Date: Sat, 19 Nov 2011 15:14:07 +0100 Subject: [MPlayer-dev-eng] [PATCH] fix direct3d crash on window minimization In-Reply-To: <20111113141745.GA6469@tane> References: <20111112133110.GA3151@tane> <20111112172749.GA3169@tane> <20111113141745.GA6469@tane> Message-ID: <20111119141407.GA2612@akuma> Alexander Strasser wrote: > Roger Pack wrote: > > Alexander Strasser wrote: > [...] > > > If the window is minimized the VO gets a resize event. When > > > handling the resize event, vo direct3d destroys the osd textures > > > and creates them again with a size fitting the new window size. > > > > > > This works well normally, but fails in case of minimization > > > because then the sizes are 0 and the texture creation fails. > > > This causes the crash later when draw_osd() gets invoked. > > > > > > I did not think about a proper solution yet. > > > > Thanks for your attention to this, looking forward to a fix (or we > > could just use that patch as a work around or the like). > > I think the attached patch would be OK as a proper fix for the > problem. There could be other issues in certain corner cases, but > they were there before (if I did not make any mistake in my patch). > > I tested it while developing. Would be great if you or any other > users of vo direct3d could test it too and confirm it fixes the > issue and that it does not introduce regressions. > > If I hear no comlaints or objections from other developers I will > apply this in a few days. I pinged the maintainer already, but got > no reply yet. Still I think it is rather important to have this fixed > soon. (It is annoying if you can't minimize a video window because > a sub might be shown and it would crash). Committed with a slightly changed comment for better readability. Georgi will look into the issue himself when he gets the time. Thanks to the original patch creator Patrick Dinh and to Roger Pack for taking this further. Alexander From rogerdpack2 at gmail.com Sat Nov 19 20:47:35 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Sat, 19 Nov 2011 12:47:35 -0700 Subject: [MPlayer-dev-eng] suggestion: svn external libdvdcss? In-Reply-To: References: Message-ID: > Perhaps it should be made into an svn:external (or version bumped)? > Anyway just pointing it out. looks like 1.2.11 was just released, FWIW. -r From mywing81 at gmail.com Sun Nov 20 00:53:36 2011 From: mywing81 at gmail.com (Giorgio Vazzana) Date: Sun, 20 Nov 2011 00:53:36 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111118131022.eaa17398.tempn@twmi.rr.com> References: <20111118114739.a030f139.tempn@twmi.rr.com> <4ec69561.3b3ef556.bm000@wupperonline.de> <20111118131022.eaa17398.tempn@twmi.rr.com> Message-ID: 2011/11/18 compn : > On Fri, 18 Nov 2011 18:26:55 +0100, Ingo Br?ckl wrote: >>[mp3float @ 0xb75c2240]err{or,}_recognition separate: 1; 1 >>[mp3float @ 0xb75c2240]err{or,}_recognition combined: 1; 1 > > could be the source of your problems. I get these messages too, but here I can play .mp3 files just fine. Ingo, I'm not sure this will help, but have you tried something like this: mplayer -noconfig all -ao alsa Giorgio Vazzana From ib at wupperonline.de Sun Nov 20 11:19:10 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 20 Nov 2011 11:19:10 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111118131022.eaa17398.tempn@twmi.rr.com> Message-ID: <4ec8d4e3.4737ad5a.bm001@wupperonline.de> compn wrote on Fri, 18 Nov 2011 13:10:22 -0500: > people have been messing with mp3float decoder The reason seems to be some assembler optimization. > so if you want you can bisect and find out where it broke? All the compilations took some time, but I tracked it down to commit 22e25c002e103e52ace35703423e896b08b51aef. Ingo From cehoyos at ag.or.at Sun Nov 20 11:56:53 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Sun, 20 Nov 2011 10:56:53 +0000 (UTC) Subject: [MPlayer-dev-eng] FFmpeg? sound issue References: <20111118131022.eaa17398.tempn@twmi.rr.com> <4ec8d4e3.4737ad5a.bm001@wupperonline.de> Message-ID: Ingo Br?ckl wupperonline.de> writes: > All the compilations took some time, but I tracked it down to commit > 22e25c002e103e52ace35703423e896b08b51aef. ffmpeg -i input out.wav ? And please add cpuflags. Carl Eugen From ib at wupperonline.de Sun Nov 20 12:28:37 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 20 Nov 2011 12:28:37 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: Message-ID: <4ec8e787.27a2ed3a.bm001@wupperonline.de> Carl Eugen Hoyos wrote on Sun, 20 Nov 2011 10:56:53 +0000 (UTC): > ffmpeg -i input out.wav Surprisingly, out.wav sounds ok. [mp3 @ 0x9bcaa80] max_analyze_duration 5000000 reached at 5015510 [mp3 @ 0x9bcaa80] Estimating duration from bitrate, this may be inaccurate Input #0, mp3, from '4210.mp3': Metadata: genre : Other Duration: 00:01:04.87, start: 0.000000, bitrate: 95 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16, 96 kb/s Output #0, wav, to 'out.wav': Metadata: genre : Other encoder : Lavf53.21.0 Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s Stream mapping: Stream #0:0 -> #0:0 (mp3 -> pcm_s16le) size= 4864kB time=00:00:28.31 bitrate=1407.2kbits/s size= 9248kB time=00:00:53.76 bitrate=1409.2kbits/s size= 11111kB time=00:01:04.49 bitrate=1411.2kbits/s video:0kB audio:11110kB global headers:0kB muxing overhead 0.000404% > And please add cpuflags. CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 0 SSSE3: 0 Ingo From Reimar.Doeffinger at gmx.de Sun Nov 20 12:43:54 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 20 Nov 2011 12:43:54 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec8d4e3.4737ad5a.bm001@wupperonline.de> References: <20111118131022.eaa17398.tempn@twmi.rr.com> <4ec8d4e3.4737ad5a.bm001@wupperonline.de> Message-ID: <20111120114353.GA3452@1und1.de> On Sun, Nov 20, 2011 at 11:19:10AM +0100, Ingo Br?ckl wrote: > compn wrote on Fri, 18 Nov 2011 13:10:22 -0500: > > > people have been messing with mp3float decoder > > The reason seems to be some assembler optimization. > > > so if you want you can bisect and find out where it broke? > > All the compilations took some time, but I tracked it down to commit > 22e25c002e103e52ace35703423e896b08b51aef. Try disabling them from the top. Easiest way is to add "0 &&" to the ifs. It is possible that AVX requires larger alignment than MPlayer currently provides, and AVX and SSSE3 are the two I can't test. From ib at wupperonline.de Sun Nov 20 14:01:53 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 20 Nov 2011 14:01:53 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111120114353.GA3452@1und1.de> Message-ID: <4ec8fa79.55ce2ee0.bm000@wupperonline.de> Reimar D?ffinger wrote on Sun, 20 Nov 2011 12:43:54 +0100: > On Sun, Nov 20, 2011 at 11:19:10AM +0100, Ingo Br?ckl wrote: >> compn wrote on Fri, 18 Nov 2011 13:10:22 -0500: >> >> > people have been messing with mp3float decoder >> >> The reason seems to be some assembler optimization. >> >> > so if you want you can bisect and find out where it broke? >> >> All the compilations took some time, but I tracked it down to commit >> 22e25c002e103e52ace35703423e896b08b51aef. > Try disabling them from the top. Easiest way is to add "0 &&" to the ifs. > It is possible that AVX requires larger alignment than MPlayer currently > provides, and AVX and SSSE3 are the two I can't test. It sets s->imdct36_float = ff_imdct36_float_sse, i.e. the last 'else if' is true. If I disable it, it works again. The new imdct36_sse.asm seems to break it. Ingo From Reimar.Doeffinger at gmx.de Sun Nov 20 15:06:59 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 20 Nov 2011 15:06:59 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec8fa79.55ce2ee0.bm000@wupperonline.de> References: <20111120114353.GA3452@1und1.de> <4ec8fa79.55ce2ee0.bm000@wupperonline.de> Message-ID: <20111120140659.GB12980@1und1.de> On Sun, Nov 20, 2011 at 02:01:53PM +0100, Ingo Br?ckl wrote: > Reimar D?ffinger wrote on Sun, 20 Nov 2011 12:43:54 +0100: > > > On Sun, Nov 20, 2011 at 11:19:10AM +0100, Ingo Br?ckl wrote: > >> compn wrote on Fri, 18 Nov 2011 13:10:22 -0500: > >> > >> > people have been messing with mp3float decoder > >> > >> The reason seems to be some assembler optimization. > >> > >> > so if you want you can bisect and find out where it broke? > >> > >> All the compilations took some time, but I tracked it down to commit > >> 22e25c002e103e52ace35703423e896b08b51aef. > > > Try disabling them from the top. Easiest way is to add "0 &&" to the ifs. > > It is possible that AVX requires larger alignment than MPlayer currently > > provides, and AVX and SSSE3 are the two I can't test. > > It sets s->imdct36_float = ff_imdct36_float_sse, i.e. the last 'else if' is > true. If I disable it, it works again. Unfortunately that doesn't say much since it's the only one that your CPU supports. Can someone with a SSE2 CPU test if disabling all others so that the ff_imdct36_float_sse will be used breaks for them, too? I looked at the SSE-only code a bit but could not see anything that would break SSE compared to e.g. SSE2... From nicolas.george at normalesup.org Sun Nov 20 15:12:29 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Sun, 20 Nov 2011 15:12:29 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111120140659.GB12980@1und1.de> References: <20111120114353.GA3452@1und1.de> <4ec8fa79.55ce2ee0.bm000@wupperonline.de> <20111120140659.GB12980@1und1.de> Message-ID: <20111120141229.GA32651@phare.normalesup.org> Le decadi 30 brumaire, an CCXX, Reimar D?ffinger a ?crit?: > Can someone with a SSE2 CPU test if disabling all others so that the > ff_imdct36_float_sse will be used breaks for them, too? I have got this: cigaes at gellei ~ $ grep --color sse /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm but I did not follow the start of the discussion: is it what you need? Can you be somewhat more specific about what needs to be done? Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From ib at wupperonline.de Sun Nov 20 15:29:08 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 20 Nov 2011 15:29:08 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111120141229.GA32651@phare.normalesup.org> Message-ID: <4ec90f0d.62beabf3.bm000@wupperonline.de> Nicolas George wrote on Sun, 20 Nov 2011 15:12:29 +0100: > but I did not follow the start of the discussion: is it what you need? > Can you be somewhat more specific about what needs to be done? If I get Reimar right, it should be checked whether this patch breaks mp3 sound with sse2 CPUs. Ingo -------------- next part -------------- --- ffmpeg/libavcodec/x86/mpegaudiodec_mmx.c 2011-11-19 19:57:17.000000000 +0100 +++ ffmpeg/libavcodec/x86/mpegaudiodec_mmx.c 2011-11-20 15:24:06.000000000 +0100 @@ -157,7 +157,7 @@ { int mm_flags = av_get_cpu_flags(); - if (mm_flags & AV_CPU_FLAG_SSE2) { + /*if (mm_flags & AV_CPU_FLAG_SSE2) { s->apply_window_float = apply_window_mp3; } if (HAVE_YASM && mm_flags & AV_CPU_FLAG_AVX && HAVE_AVX) { @@ -172,7 +172,7 @@ else if (HAVE_YASM && mm_flags & AV_CPU_FLAG_SSE2 && HAVE_SSE) { s->imdct36_float = ff_imdct36_float_sse2; } - else if (HAVE_YASM && mm_flags & AV_CPU_FLAG_SSE && HAVE_SSE) { + else*/ if (HAVE_YASM && mm_flags & AV_CPU_FLAG_SSE && HAVE_SSE) { s->imdct36_float = ff_imdct36_float_sse; } } From auerswal at unix-ag.uni-kl.de Sun Nov 20 15:36:47 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 20 Nov 2011 15:36:47 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec90f0d.62beabf3.bm000@wupperonline.de> References: <4ec90f0d.62beabf3.bm000@wupperonline.de> Message-ID: <4EC9107F.70700@unix-ag.uni-kl.de> Hi, On 11/20/2011 03:29 PM, Ingo Br?ckl wrote: > Nicolas George wrote on Sun, 20 Nov 2011 15:12:29 +0100: > >> but I did not follow the start of the discussion: is it what you need? >> Can you be somewhat more specific about what needs to be done? > > If I get Reimar right, it should be checked whether this patch breaks mp3 > sound with sse2 CPUs. MP3 playback still works for me after applying the patch. $ ./mplayer -v | grep CPU CPU vendor name: AuthenticAMD max cpuid level: 1 CPU: AMD Sempron(tm) Processor 3000+ (Family: 15, Model: 28, Stepping: 0) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowExt SSE SSE2 CMOV Erik From auerswal at unix-ag.uni-kl.de Sun Nov 20 15:40:12 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 20 Nov 2011 15:40:12 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4EC9107F.70700@unix-ag.uni-kl.de> References: <4ec90f0d.62beabf3.bm000@wupperonline.de> <4EC9107F.70700@unix-ag.uni-kl.de> Message-ID: <4EC9114C.9080200@unix-ag.uni-kl.de> Hi, On 11/20/2011 03:36 PM, Erik Auerswald wrote: > On 11/20/2011 03:29 PM, Ingo Br?ckl wrote: >> Nicolas George wrote on Sun, 20 Nov 2011 15:12:29 +0100: >> >>> but I did not follow the start of the discussion: is it what you need? >>> Can you be somewhat more specific about what needs to be done? >> >> If I get Reimar right, it should be checked whether this patch breaks mp3 >> sound with sse2 CPUs. > > MP3 playback still works for me after applying the patch. > > $ ./mplayer -v | grep CPU > CPU vendor name: AuthenticAMD max cpuid level: 1 > CPU: AMD Sempron(tm) Processor 3000+ (Family: 15, Model: 28, Stepping: 0) > CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0 > Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowExt SSE SSE2 CMOV Just to add that ffmpeg is used for MP3 playback: Audio only file format detected. ========================================================================== Requested audio codec family [mpg123] (afm=mpg123) not available. Enable it at compilation. Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800) Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) ========================================================================== AO: [alsa] 44100Hz 2ch floatle (4 bytes per sample) Erik From nicolas.george at normalesup.org Sun Nov 20 15:47:57 2011 From: nicolas.george at normalesup.org (Nicolas George) Date: Sun, 20 Nov 2011 15:47:57 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4EC9107F.70700@unix-ag.uni-kl.de> References: <4ec90f0d.62beabf3.bm000@wupperonline.de> <4EC9107F.70700@unix-ag.uni-kl.de> Message-ID: <20111120144757.GA3530@phare.normalesup.org> Le decadi 30 brumaire, an CCXX, Erik Auerswald a ?crit?: > MP3 playback still works for me after applying the patch. > > $ ./mplayer -v | grep CPU > CPU vendor name: AuthenticAMD max cpuid level: 1 > CPU: AMD Sempron(tm) Processor 3000+ (Family: 15, Model: 28, Stepping: 0) > CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0 > Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowExt SSE SSE2 CMOV Same here, with: cigaes at gellei ~/mplayer $ ./mplayer -v | grep CPU CPU vendor name: GenuineIntel max cpuid level: 11 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (Family: 6, Model: 26, Stepping: 5) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSSE3: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 SSSE3 CMOV ========================================================================== Requested audio codec family [mpg123] (afm=mpg123) not available. Enable it at compilation. Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800) Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) ========================================================================== Regards, -- Nicolas George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Reimar.Doeffinger at gmx.de Sun Nov 20 17:31:04 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Sun, 20 Nov 2011 17:31:04 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ec90f0d.62beabf3.bm000@wupperonline.de> References: <4ec90f0d.62beabf3.bm000@wupperonline.de> Message-ID: <47399649-F97F-4D1F-96B5-8A22BDB9D2A6@gmx.de> On 20 Nov 2011, at 15:29, Ingo Br?ckl wrote: > Nicolas George wrote on Sun, 20 Nov 2011 15:12:29 +0100: > >> but I did not follow the start of the discussion: is it what you need? >> Can you be somewhat more specific about what needs to be done? > > If I get Reimar right, it should be checked whether this patch breaks mp3 > sound with sse2 CPUs. Well, I meant only the imdct36 part, though that should not make a difference. > From ib at wupperonline.de Sun Nov 20 18:40:42 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Sun, 20 Nov 2011 18:40:42 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <47399649-F97F-4D1F-96B5-8A22BDB9D2A6@gmx.de> Message-ID: <4ec93c09.274226d9.bm000@wupperonline.de> Reimar D?ffinger wrote on Sun, 20 Nov 2011 17:31:04 +0100: > On 20 Nov 2011, at 15:29, Ingo Br?ckl wrote: >> Nicolas George wrote on Sun, 20 Nov 2011 15:12:29 +0100: >> >>> but I did not follow the start of the discussion: is it what you need? >>> Can you be somewhat more specific about what needs to be done? >> >> If I get Reimar right, it should be checked whether this patch breaks mp3 >> sound with sse2 CPUs. > Well, I meant only the imdct36 part, though that should not make a > difference. Is there still anything I can do or test? I can't be the only one with that problem - even if it's a SSE CPU bug (can it?) Ingo From cehoyos at ag.or.at Sun Nov 20 21:26:55 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Sun, 20 Nov 2011 20:26:55 +0000 (UTC) Subject: [MPlayer-dev-eng] FFmpeg? sound issue References: <47399649-F97F-4D1F-96B5-8A22BDB9D2A6@gmx.de> <4ec93c09.274226d9.bm000@wupperonline.de> Message-ID: Ingo Br?ckl wupperonline.de> writes: > Is there still anything I can do or test? You claimed on ffmpeg-user that you found a FFmpeg bug, please post complete, uncut output there. Carl Eugen From ib at wupperonline.de Mon Nov 21 10:24:46 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Mon, 21 Nov 2011 10:24:46 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: Message-ID: <4eca2ad8.34e78683.bm000@wupperonline.de> Carl Eugen Hoyos wrote on Sun, 20 Nov 2011 20:26:55 +0000 (UTC): > Ingo Br?ckl wupperonline.de> writes: >> Is there still anything I can do or test? > You claimed on ffmpeg-user that you found a FFmpeg bug, please post > complete, uncut output there. Doesn't the result of your suggestion to do a 'ffmpeg -i input out.wav' indicate that it might rather be a MPlayer issue? The wav file created by 'ffmpeg -i 4210.mp3 outf.wav' plays fine and sounds ok whereas the file created by 'mplayer -ao pcm:file=outm.wav 4210.mp3' (I hope that does the same) has the mentioned issues. outm.wav (http://www.load.to/dAzgTM7wV8/outm.zip) consists of nothing but 00 00 C0 7F patters. Ingo From cehoyos at ag.or.at Mon Nov 21 11:52:20 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Mon, 21 Nov 2011 10:52:20 +0000 (UTC) Subject: [MPlayer-dev-eng] FFmpeg? sound issue References: <4eca2ad8.34e78683.bm000@wupperonline.de> Message-ID: Ingo Br?ckl wupperonline.de> writes: > >> Is there still anything I can do or test? > > > You claimed on ffmpeg-user that you found a FFmpeg bug, please post > > complete, uncut output there. > > Doesn't the result of your suggestion to do a 'ffmpeg -i input out.wav' > indicate that it might rather be a MPlayer issue? > > The wav file created by 'ffmpeg -i 4210.mp3 outf.wav' plays fine I assumed you were able to reproduce the problem with FFmpeg because you posted on ffmpeg-uxers. Please configure FFmpeg with "./configure --disable-decoders=mp2,mp3" to be able to test float decoders reliably. Carl Eugen From ib at wupperonline.de Mon Nov 21 13:24:35 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Mon, 21 Nov 2011 13:24:35 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: Message-ID: <4eca4305.3d08a575.bm000@wupperonline.de> Carl Eugen Hoyos wrote on Mon, 21 Nov 2011 10:52:20 +0000 (UTC): > Ingo Br?ckl wupperonline.de> writes: >> The wav file created by 'ffmpeg -i 4210.mp3 outf.wav' plays fine > I assumed you were able to reproduce the problem with FFmpeg because you > posted on ffmpeg-uxers. This was when I tracked down the bad commit with 'git bisect'. I wasn't aware that there is a difference between pure ffmpeg and its using by mplayer. > Please configure FFmpeg with "./configure --disable-decoders=mp2,mp3" to be > able to test float decoders reliably. For my mplayer build I assume? Nothing changed, no sound. Ingo From cehoyos at ag.or.at Mon Nov 21 13:38:48 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Mon, 21 Nov 2011 12:38:48 +0000 (UTC) Subject: [MPlayer-dev-eng] FFmpeg? sound issue References: <4eca4305.3d08a575.bm000@wupperonline.de> Message-ID: Ingo Br?ckl wupperonline.de> writes: > > Please configure FFmpeg with "./configure --disable-decoders=mp2,mp3" to be > > able to test float decoders reliably. > > For my mplayer build I assume? Nothing changed, no sound. No, this is needed if you want to try to reproduce your playback problem with ffmpeg/ffplay. (Does mplayer's configure accept --disable-decoders=mp2.mp3 ?) Carl Eugen From ib at wupperonline.de Mon Nov 21 14:29:37 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Mon, 21 Nov 2011 14:29:37 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: Message-ID: <4eca5408.7ec1ec7a.bm000@wupperonline.de> Carl Eugen Hoyos wrote on Mon, 21 Nov 2011 12:38:48 +0000 (UTC): > Ingo Br?ckl wupperonline.de> writes: >> > Please configure FFmpeg with "./configure --disable-decoders=mp2,mp3" to be >> > able to test float decoders reliably. >> >> For my mplayer build I assume? Nothing changed, no sound. > No, this is needed if you want to try to reproduce your playback problem > with ffmpeg/ffplay. Oh, I see. Yep, the wav file created by the mp2,mp3 disabled ffmpeg is as bad as the one from mplayer (and only contains 00 80 patterns) now. Only now I noticed that my previous ffmpeg build created the (good) wav file with mp3 -> pcm_s16le (which was in my posted output though) whereas the bad wav file was created with mp3float -> pcm_s16le now. So, it seems to be a ffmpeg bug after all then? What can I do furthermore? > (Does mplayer's configure accept --disable-decoders=mp2.mp3 ?) Both ffmpeg and mplayer accept '--disable-decoder=' (singular). Ingo From thomas-forum at orgis.org Mon Nov 21 17:49:16 2011 From: thomas-forum at orgis.org (Thomas Orgis) Date: Mon, 21 Nov 2011 17:49:16 +0100 Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib In-Reply-To: <20111116114458.GA11607@pool.informatik.rwth-aachen.de> References: <20110920181954.GA32134@1und1.de> <20111116114458.GA11607@pool.informatik.rwth-aachen.de> Message-ID: <20111121174916.659a838b@orgis.org> Am Wed, 16 Nov 2011 12:44:58 +0100 schrieb Diego Biurrun : > Was there ever some sort or progress or decision about this? It is still on my TODO list to track down those performance inconsistencies / the penalty when using libmpg123 from MPlayer, specifically making it slower than built-in mp3lib for 3DNow(Ext). I understood that the possibility of performance regression has to be put out of the way before dropping mp3lib. Help appreciated, as I should really, really spend my time on RL matters:-/ Alrighty then, Thomas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Mon Nov 21 19:31:19 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 21 Nov 2011 19:31:19 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4eca2ad8.34e78683.bm000@wupperonline.de> References: <4eca2ad8.34e78683.bm000@wupperonline.de> Message-ID: <20111121183119.GB2164@1und1.de> On Mon, Nov 21, 2011 at 10:24:46AM +0100, Ingo Br?ckl wrote: > outm.wav (http://www.load.to/dAzgTM7wV8/outm.zip) consists of nothing but > 00 00 C0 7F patters. Uh, that is a silenced NaN. I have absolutely no idea how that would come in. 0/0 or inf - inf would be possible sources, but seem unlikely. From ib at wupperonline.de Tue Nov 22 11:33:08 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Tue, 22 Nov 2011 11:33:08 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <20111121183119.GB2164@1und1.de> Message-ID: <4ecb81dc.7dfa780c.bm000@wupperonline.de> Reimar D?ffinger wrote on Mon, 21 Nov 2011 19:31:19 +0100: > On Mon, Nov 21, 2011 at 10:24:46AM +0100, Ingo Br?ckl wrote: >> outm.wav (http://www.load.to/dAzgTM7wV8/outm.zip) consists of nothing but >> 00 00 C0 7F patters. > Uh, that is a silenced NaN. > I have absolutely no idea how that would come in. > 0/0 or inf - inf would be possible sources, but seem unlikely. Are there any test patterns for in, win, etc. I could use to do a test call of ff_imdct36_float_sse() from a simple test program? (I tried with simple float arrays, both empty and containing 1.0, 2.0, 3.0, ... but only get segmentation faults.) On the other hand, it seems quite clear that ff_imdct36_float_sse() is the problem. If I force using ff_imdct36_float() instead, everything's fine again. >From what I found on the ffmpeg mailing list, ff_imdct36_float_sse() has been developed on an Atom CPU and Erik and Nicolas did their tests on more modern CPUs than mine as well. Ingo From diego at biurrun.de Tue Nov 22 21:46:25 2011 From: diego at biurrun.de (Diego Biurrun) Date: Tue, 22 Nov 2011 21:46:25 +0100 Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib In-Reply-To: <20111121174916.659a838b@orgis.org> References: <20110920181954.GA32134@1und1.de> <20111116114458.GA11607@pool.informatik.rwth-aachen.de> <20111121174916.659a838b@orgis.org> Message-ID: <20111122204625.GA4952@pool.informatik.rwth-aachen.de> On Mon, Nov 21, 2011 at 05:49:16PM +0100, Thomas Orgis wrote: > Am Wed, 16 Nov 2011 12:44:58 +0100 > schrieb Diego Biurrun : > > > Was there ever some sort or progress or decision about this? > > It is still on my TODO list to track down those performance > inconsistencies / the penalty when using libmpg123 from MPlayer, > specifically making it slower than built-in mp3lib for 3DNow(Ext). > > I understood that the possibility of performance regression has to be > put out of the way before dropping mp3lib. Help appreciated, as I > should really, really spend my time on RL matters:-/ Since I'm probably the only living person still using a K6-III, I think you can ignore this issue - I'll not keep using that machine for much longer. That said, if you give me something to benchmark, I will. Diego From thomas-forum at orgis.org Wed Nov 23 08:22:49 2011 From: thomas-forum at orgis.org (Thomas Orgis) Date: Wed, 23 Nov 2011 08:22:49 +0100 Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib In-Reply-To: <20111122204625.GA4952@pool.informatik.rwth-aachen.de> References: <20110920181954.GA32134@1und1.de> <20111116114458.GA11607@pool.informatik.rwth-aachen.de> <20111121174916.659a838b@orgis.org> <20111122204625.GA4952@pool.informatik.rwth-aachen.de> Message-ID: <20111123082249.69a513b6@orgis.org> Am Tue, 22 Nov 2011 21:46:25 +0100 schrieb Diego Biurrun : > Since I'm probably the only living person still using a K6-III, I think > you can ignore this issue - I'll not keep using that machine for much > longer. Well... I also do have a K6-|||+, but not in regular use, I admit. Thing is, that Ivan has seen it on an Athlon without SSE, too. Of course one could say that MPEG audio performace isn't that much of an issue nowadays, but since I claim to maintain the fastest decoder, it should stay so, also when used from MPlayer. I might find some time on Monday afternoon to analyse the data Ivan already provided. The main point is already that external libmpg123 is hard on cache. Alrighty then, Thomas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kirin_e at users.sourceforge.net Wed Nov 23 13:02:41 2011 From: kirin_e at users.sourceforge.net (kirin_e at users.sourceforge.net) Date: Wed, 23 Nov 2011 12:02:41 -0000 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo Message-ID: <20111123154030.A22870@localhost> Hi, I needed OpenGL ES X11 output for a device i have so i ended up writing a gles vo, here it is in case it's useful to others. Patch against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs support for npot textures. Any comments or improvements are welcome. /kirin -------------- next part -------------- diff -Naur --exclude '*.o' --exclude '*.d' --exclude ffmpeg --exclude codec-cfg --exclude codecs.conf.h --exclude 'config.*' --exclude GLES --exclude help_mp.h --exclude mplayer --exclude mencoder --exclude version.h --exclude mplayer.c org/mplayer-export-2011-10-31/configure mplayer-export-2011-10-31/configure --- org/mplayer-export-2011-10-31/configure 2011-10-30 18:40:22.000000000 +0100 +++ mplayer-export-2011-10-31/configure 2011-11-23 03:33:30.000000000 +0100 @@ -470,6 +470,7 @@ --enable-dhahelper enable VIDIX dhahelper support --enable-svgalib_helper enable VIDIX svgalib_helper support --enable-gl enable OpenGL video output [autodetect] + --enable-gles enable OpenGL ES X11 video output [disable] --disable-matrixview disable OpenGL MatrixView video output [autodetect] --enable-dga2 enable DGA 2 support [autodetect] --enable-dga1 enable DGA 1 support [autodetect] @@ -697,6 +698,7 @@ _yuv4mpeg=yes _gif=auto _gl=auto +_gles=no matrixview=auto _ggi=auto _ggiwmh=auto @@ -1053,6 +1055,8 @@ --disable-gif) _gif=no ;; --enable-gl) _gl=yes ;; --disable-gl) _gl=no ;; + --enable-gles) _gles=yes ;; + --disable-gles) _gles=no ;; --enable-matrixview) matrixview=yes ;; --disable-matrixview) matrixview=no ;; --enable-ggi) _ggi=yes ;; @@ -5040,6 +5044,18 @@ echores "$_sdl" +echocheck "OpenGL ES" +if test "$_gles" = yes ; then + vomodules="gles $vomodules" + libs_mplayer="$libs_mplayer -lEGL -lGLESv1_CM" + def_gles='#define CONFIG_GLES 1' +else + novomodules="gles $novomodules" + def_gles='#undef CONFIG_GLES' +fi +echores "$_gles" + + # make sure this stays below CoreVideo to avoid issues due to namespace # conflicts between -lGL and -framework OpenGL echocheck "OpenGL" @@ -7896,6 +7912,7 @@ GL_WIN32 = $_gl_win32 GL_X11 = $_gl_x11 GL_SDL = $_gl_sdl +GLES = $_gles MATRIXVIEW = $matrixview GUI = $_gui GUI_GTK = $_gui_gtk @@ -8441,6 +8458,7 @@ $def_gl_win32 $def_gl_x11 $def_gl_sdl +$def_gles $def_matrixview $def_ivtv $def_jpeg diff -Naur --exclude '*.o' --exclude '*.d' --exclude ffmpeg --exclude codec-cfg --exclude codecs.conf.h --exclude 'config.*' --exclude GLES --exclude help_mp.h --exclude mplayer --exclude mencoder --exclude version.h --exclude mplayer.c org/mplayer-export-2011-10-31/DOCS/man/en/mplayer.1 mplayer-export-2011-10-31/DOCS/man/en/mplayer.1 --- org/mplayer-export-2011-10-31/DOCS/man/en/mplayer.1 2011-10-24 19:44:13.000000000 +0200 +++ mplayer-export-2011-10-31/DOCS/man/en/mplayer.1 2011-11-23 00:51:22.000000000 +0100 @@ -4355,6 +4355,10 @@ .REss . .TP +.B gles (X11 only) +OpenGL ES output driver. +. +.TP .B matrixview OpenGL-based renderer creating a Matrix-like running-text effect. .PD 0 diff -Naur --exclude '*.o' --exclude '*.d' --exclude ffmpeg --exclude codec-cfg --exclude codecs.conf.h --exclude 'config.*' --exclude GLES --exclude help_mp.h --exclude mplayer --exclude mencoder --exclude version.h --exclude mplayer.c org/mplayer-export-2011-10-31/libvo/video_out.c mplayer-export-2011-10-31/libvo/video_out.c --- org/mplayer-export-2011-10-31/libvo/video_out.c 2011-07-05 14:05:06.000000000 +0200 +++ mplayer-export-2011-10-31/libvo/video_out.c 2011-11-01 00:26:10.000000000 +0100 @@ -99,6 +99,7 @@ extern const vo_functions_t video_out_gl_nosw; extern const vo_functions_t video_out_gl; extern const vo_functions_t video_out_gl2; +extern const vo_functions_t video_out_gles; extern const vo_functions_t video_out_matrixview; extern const vo_functions_t video_out_dga; extern const vo_functions_t video_out_sdl; @@ -208,6 +209,9 @@ &video_out_gl, &video_out_gl2, #endif +#ifdef CONFIG_GLES + &video_out_gles, +#endif #ifdef CONFIG_DGA &video_out_dga, #endif diff -Naur --exclude '*.o' --exclude '*.d' --exclude ffmpeg --exclude codec-cfg --exclude codecs.conf.h --exclude 'config.*' --exclude GLES --exclude help_mp.h --exclude mplayer --exclude mencoder --exclude version.h --exclude mplayer.c org/mplayer-export-2011-10-31/libvo/vo_gles.c mplayer-export-2011-10-31/libvo/vo_gles.c --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 @@ -0,0 +1,480 @@ +/* + * This file is part of MPlayer. + * + * MPlayer is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * MPlayer is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with MPlayer; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + * You can alternatively redistribute this file and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + */ + +// TODO +// - handle aspect +// - check for extensions +// - fallback if no support for NPOT textures +// - GLES 2.0 (YUV conversion using shader) +// MPlayer quirks +// - OSD resize delay +// - fixed-vo no resize event on nofs->fs->loop->nofs +// - 640x480 default on fs->nofs +// - drawing before check_events(resize) + +#include +#include + +#include "mp_core.h" +#include "video_out.h" +#include "video_out_internal.h" +#include "x11_common.h" +#include "sub/sub.h" + +#include +#include +#define GL_GLEXT_PROTOTYPES 1 +#include + +#ifndef GL_EXT_bgra // not defined in Khronos GLES/glext.h +#define GL_EXT_bgra 1 +#define GL_BGR_EXT 0x80E0 +#define GL_BGRA_EXT 0x80E1 +#endif + +//uncomment to disable extensions +//#undef GL_OES_draw_texture +//#undef GL_EXT_bgra +//#undef GL_EXT_texture_format_BGRA8888 + +#define IS_ALIGNED(a, b) ((((uintptr_t)(const void *)(a)) & ((b) - 1)) == 0) +#define MAX_CONFIGS 10 + +//#define FAST_OSD 1 + +static const vo_info_t info = { + "OpenGL ES (X11)", + "gles", + "kirin_e at users.sourceforge.net", + "" +}; + +const LIBVO_EXTERN(gles) + +static int unshown = 0; +static unsigned int src_width = 0, src_height = 0; +static unsigned int win_width = 0, win_height = 0; +static unsigned int src_pixel_bytes = 0; +static GLenum tex_format = GL_RGBA; +static GLuint texture[2] = { 0, 0 }; + +#ifndef GL_OES_draw_texture +static const GLshort texcoord_buffer[16] = { 0, 1, 0, 0, 1, 1, 1, 0, + 0, 1, 0, 0, 1, 1, 1, 0 }; +static GLshort vertex_buffer[16] = { 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0 }; +#endif + +static void draw(uint8_t *src[], int stride[], int w, int h, int x, int y) +{ + int src_align, align, w_bytes_aligned, i; + + for (src_align = 8; !IS_ALIGNED(src[0], src_align); src_align >>= 1); + for (align = src_align; !IS_ALIGNED(stride[0], align); align >>= 1); + + glPixelStorei(GL_UNPACK_ALIGNMENT, align); + glBindTexture(GL_TEXTURE_2D, texture[0]); + + w_bytes_aligned = (w * src_pixel_bytes + align - 1) & ~(align - 1); + if (w_bytes_aligned == stride[0]) { + if (x != 0 || y != 0 || w != src_width || h != src_height) { + glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, w, h, tex_format, GL_UNSIGNED_BYTE, src[0]); + } else { + glTexImage2D(GL_TEXTURE_2D, 0, tex_format, w, h, 0, tex_format, GL_UNSIGNED_BYTE, src[0]); + } + } else { + for (i = 0; i < h; i++) { + glTexSubImage2D(GL_TEXTURE_2D, 0, x, y + i, w, 1, tex_format, GL_UNSIGNED_BYTE, src[0] + stride[0] * i); + } + } +#ifndef GL_OES_draw_texture + glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); +#else + glDrawTexiOES(0, 0, 0, win_width, win_height); +#endif + unshown = 1; +} + +static void draw_alpha(int x0, int y0, int w, int h, unsigned char *src, + unsigned char *srca, int stride) +{ + int src_align, align, w_bytes_aligned, i; +#ifdef FAST_OSD + GLenum osd_tex_format = GL_LUMINANCE; + int osd_pixel_bytes = 1; +#else + GLenum osd_tex_format = GL_LUMINANCE_ALPHA; + int osd_pixel_bytes = 2, j; + char src_la[h * stride * 2]; + + for (i = 0; i < h; i++) { + for (j = 0; j < w; j++) { + src_la[i * stride * 2 + j * 2] = src[i * stride + j]; + src_la[i * stride * 2 + j * 2 + 1] = srca[i * stride + j] ? srca[i * stride + j] : 255; + } + } + src = src_la; + stride = stride * 2; +#endif + + //printf("\n at draw_alpha: %ix%i xoffset %i yoffset %i stride %i (%p %p)\n", w, h, x0, y0, stride, src, srca); + for (src_align = 8; !IS_ALIGNED(src, src_align); src_align >>= 1); + for (align = src_align; !IS_ALIGNED(stride, align); align >>= 1); + + glPixelStorei(GL_UNPACK_ALIGNMENT, align); + glBindTexture(GL_TEXTURE_2D, texture[1]); +#ifdef GL_OES_draw_texture + { + GLint crop_rect[4] = { 0, h, w, -h }; + + glTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_CROP_RECT_OES, crop_rect); + } +#endif + + w_bytes_aligned = (w * osd_pixel_bytes + align - 1) & ~(align - 1); + //printf("osd data alignment: %i, w_bytes_aligned: %i\n", align, w_bytes_aligned); + if (w_bytes_aligned == stride) { + glTexImage2D(GL_TEXTURE_2D, 0, osd_tex_format, w, h, 0, osd_tex_format, GL_UNSIGNED_BYTE, src); + } else { + glTexImage2D(GL_TEXTURE_2D, 0, osd_tex_format, w, h, 0, osd_tex_format, GL_UNSIGNED_BYTE, NULL); + for (i = 0; i < h; i ++) { + glTexSubImage2D(GL_TEXTURE_2D, 0, 0, i, w, 1, osd_tex_format, GL_UNSIGNED_BYTE, src + stride * i); + } + } + glEnable(GL_BLEND); +#ifndef GL_OES_draw_texture + { + int y0i = win_height - y0 - h; + + vertex_buffer[8] = x0; + vertex_buffer[9] = y0i; + vertex_buffer[10] = x0; + vertex_buffer[11] = y0i + h; + vertex_buffer[12] = x0 + w; + vertex_buffer[13] = y0i; + vertex_buffer[14] = x0 + w; + vertex_buffer[15] = y0i + h; + glDrawArrays(GL_TRIANGLE_STRIP, 4, 4); + } +#else + glDrawTexiOES(x0, win_height - y0 - h, 0, w, h); +#endif + glDisable(GL_BLEND); +} + +static void reshape(int width, int height) +{ +#ifndef GL_OES_draw_texture + vertex_buffer[3] = height; + vertex_buffer[4] = width; + vertex_buffer[6] = width; + vertex_buffer[7] = height; +#endif + glViewport(0, 0, (GLint) width, (GLint) height); + glMatrixMode(GL_PROJECTION); + glLoadIdentity(); + glOrthox(0 << 16, width << 16, 0 << 16, height << 16, -1 << 16, 1 << 16); + glMatrixMode(GL_MODELVIEW); +} + +static void gl_init(void) +{ + mp_msg(MSGT_VO, MSGL_V, "GL_RENDERER = %s\n", (char *) glGetString(GL_RENDERER)); + mp_msg(MSGT_VO, MSGL_V, "GL_VERSION = %s\n", (char *) glGetString(GL_VERSION)); + mp_msg(MSGT_VO, MSGL_V, "GL_VENDOR = %s\n", (char *) glGetString(GL_VENDOR)); + mp_msg(MSGT_VO, MSGL_V, "GL_EXTENSIONS = %s\n", (char *) glGetString(GL_EXTENSIONS)); + + reshape(win_width, win_height); + glGenTextures(2, texture); + + glBindTexture(GL_TEXTURE_2D, texture[0]); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); +#ifdef GL_OES_draw_texture + { + GLint crop_rect[4] = { 0, src_height, src_width, -src_height }; + + glTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_CROP_RECT_OES, crop_rect); + } +#endif + glTexImage2D(GL_TEXTURE_2D, 0, tex_format, src_width, src_height, 0, tex_format, GL_UNSIGNED_BYTE, NULL); + + glBindTexture(GL_TEXTURE_2D, texture[1]); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); + +#ifndef GL_OES_draw_texture + glTexCoordPointer(2, GL_SHORT, 0, texcoord_buffer); + glVertexPointer(2, GL_SHORT, 0, vertex_buffer); + glEnableClientState(GL_VERTEX_ARRAY); + glEnableClientState(GL_TEXTURE_COORD_ARRAY); +#endif + glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE); + glEnable(GL_TEXTURE_2D); + glBlendFunc(GL_ONE, GL_SRC_ALPHA); +} + +// ----------------------------------------------- + +static Display *dpy = NULL; +static Window window = 0; +static Colormap colormap = 0; + +static EGLDisplay egldpy; +static EGLSurface eglwindow; +static EGLContext eglctx; + +static void createEGLWindow(int width, int height, char *name, uint32_t flags) +{ + const EGLint attrib_list[] = { EGL_RED_SIZE, 1, EGL_GREEN_SIZE, 1, EGL_BLUE_SIZE, 1, EGL_NONE }; + EGLConfig configs[MAX_CONFIGS]; + EGLint num_configs; + EGLint visual_id = 0, attrib; + + XVisualInfo *vinfo, vinfo_template; + int i, cfg, num_visuals; + + dpy = mDisplay; // set by vo_init() + + egldpy = eglGetDisplay(dpy); + if (egldpy == EGL_NO_DISPLAY) exit_player(EXIT_ERROR); + if (eglInitialize(egldpy, NULL, NULL) == EGL_FALSE) exit_player(EXIT_ERROR); + if (eglChooseConfig(egldpy, attrib_list, configs, MAX_CONFIGS, &num_configs) == EGL_FALSE) exit_player(EXIT_ERROR); + if (num_configs == 0) { + mp_msg(MSGT_VO, MSGL_ERR, "gles: no matching EGL frame buffer configurations found!\n"); + exit_player(EXIT_ERROR); + } + for (cfg = 0; cfg < num_configs && visual_id == 0; cfg++) { + mp_msg(MSGT_VO, MSGL_V, "gles: configs[%i]: ", cfg); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_NATIVE_VISUAL_ID, &visual_id); + mp_msg(MSGT_VO, MSGL_V, "VisualID: 0x%02x ", visual_id); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_BUFFER_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "bpp: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_RED_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "R: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_GREEN_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "G: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_BLUE_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "B: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_ALPHA_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "A: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_DEPTH_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "Z: %i ", attrib); + eglGetConfigAttrib(egldpy, configs[cfg], EGL_STENCIL_SIZE, &attrib); + mp_msg(MSGT_VO, MSGL_V, "S: %i\n", attrib); + } + if (visual_id == 0) { + mp_msg(MSGT_VO, MSGL_INFO, "gles: no useable VisualID found in configs, matching on depth instead!\n"); + cfg = 0; + eglGetConfigAttrib(egldpy, configs[cfg], EGL_BUFFER_SIZE, &vinfo_template.depth); + vinfo = XGetVisualInfo(dpy, VisualDepthMask, &vinfo_template, &num_visuals); + } else { + vinfo_template.visualid = visual_id; + vinfo = XGetVisualInfo(dpy, VisualIDMask, &vinfo_template, &num_visuals); + } + if (vinfo == NULL || num_visuals == 0) exit_player(EXIT_ERROR); + for (i = 0; i < num_visuals; i++) { + mp_msg(MSGT_VO, MSGL_V, "gles: visuals[%i]: visual depth: %i\n", i, vinfo[i].depth); + } + + colormap = XCreateColormap(dpy, RootWindow(dpy, vinfo->screen), vinfo->visual, AllocNone); + + vo_x11_create_vo_window(vinfo, 0, 0, width, height, flags, colormap, "EGL", name); + window = vo_window; // set by vo_x11_create_vo_window() + + XFree(vinfo); + + eglctx = eglCreateContext(egldpy, configs[cfg], EGL_NO_CONTEXT, NULL); + if (eglctx == EGL_NO_CONTEXT) exit_player(EXIT_ERROR); + eglwindow = eglCreateWindowSurface(egldpy, configs[cfg], (NativeWindowType) window, NULL); + if (eglwindow == EGL_NO_SURFACE) exit_player(EXIT_ERROR); + if (eglMakeCurrent(egldpy, eglwindow, eglwindow, eglctx) == EGL_FALSE) exit_player(EXIT_ERROR); + + win_width = width; + win_height = height; +} + +static void destroyEGLWindow(void) +{ + eglMakeCurrent(egldpy, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); + eglDestroySurface(egldpy, eglwindow); + eglDestroyContext(egldpy, eglctx); + eglTerminate(egldpy); +} + +static void postEGLWindow(void) +{ + eglSwapBuffers(egldpy, eglwindow); +} + +// ----------------------------------------------- + +static int query_format(uint32_t format) +{ + int flags = VFCAP_CSP_SUPPORTED | VFCAP_ACCEPT_STRIDE | VFCAP_OSD; + //uint32_t fourcc[2] = { format, 0 }; + + //printf("\n at query_format: 0x%08x (%s)\n", format, (char *) fourcc); + switch (format) { + case IMGFMT_RGB32: + case IMGFMT_RGB24: +#if defined(GL_EXT_bgra) || defined(GL_EXT_texture_format_BGRA8888) + case IMGFMT_BGR32: +#endif +#if defined(GL_EXT_bgra) + case IMGFMT_BGR24: +#endif + return flags; + } + + return 0; +} + +// ----------------------------------------------- + +static int draw_frame(uint8_t *src[]) +{ + int stride[] = { src_width * src_pixel_bytes }; + + //printf("\n at draw_frame\n"); + draw(src, stride, src_width, src_height, 0, 0); + + return 0; +} + +static int draw_slice(uint8_t *src[], int stride[], int w, int h, int x, int y) +{ + //printf("\n at draw_slice x: %i y: %i w: %i h: %i stride: %i src@%p\n", x, y, w, h, stride[0], src[0]); + draw(src, stride, w, h, x, y); + + return 0; +} + +static void draw_osd(void) +{ + vo_draw_text(win_width, win_height, draw_alpha); +} + +static void check_events(void) +{ + int event = vo_x11_check_events(dpy); + + if (event & VO_EVENT_RESIZE) { + XWindowAttributes window_attributes; + + XGetWindowAttributes(dpy, window, &window_attributes); + mp_msg(MSGT_VO, MSGL_INFO, "gles: resize event! (%ix%i, vo: %ix%i)\n", + window_attributes.width, window_attributes.height, vo_dwidth, vo_dheight); + if (unshown) mp_msg(MSGT_VO, MSGL_INFO, "gles: resizing with non-empty buffer!\n"); + if (win_width != window_attributes.width || win_height != window_attributes.height) { + win_width = window_attributes.width; + win_height = window_attributes.height; + reshape(win_width, win_height); + } else mp_msg(MSGT_VO, MSGL_INFO, "gles: hmm.. resize event without size change!\n"); + } +} + +static void flip_page(void) +{ + if (!unshown) mp_msg(MSGT_VO, MSGL_INFO, "gles: flipping empty buffer!\n"); + postEGLWindow(); + unshown = 0; +} + +static int config(uint32_t width, uint32_t height, uint32_t d_width, + uint32_t d_height, uint32_t flags, char *title, + uint32_t format) +{ + switch (format) { + case IMGFMT_RGB32: + tex_format = GL_RGBA; + src_pixel_bytes = 4; + break; + case IMGFMT_RGB24: + tex_format = GL_RGB; + src_pixel_bytes = 3; + break; +#if defined(GL_EXT_bgra) || defined(GL_EXT_texture_format_BGRA8888) + case IMGFMT_BGR32: + tex_format = GL_BGRA_EXT; + src_pixel_bytes = 4; + break; +#endif +#if defined(GL_EXT_bgra) + case IMGFMT_BGR24: + tex_format = GL_BGR_EXT; + src_pixel_bytes = 3; + break; +#endif + default: /* unsupported */ + return 1; + }; + + src_width = width; + src_height = height; + + if (!eglwindow) createEGLWindow(width, height, title, flags); + gl_init(); + + return 0; +} + +static int preinit(const char *arg) +{ + if (!vo_init()) return VO_FALSE; // x11 init + + return 0; +} + +static void uninit(void) +{ + if (eglwindow) destroyEGLWindow(); + vo_x11_uninit(); + if (colormap) XFreeColormap(dpy, colormap); +} + +static int control(uint32_t request, void *data) +{ + switch (request) { + case VOCTRL_QUERY_FORMAT: + return query_format(*((uint32_t *) data)); + case VOCTRL_ONTOP: + vo_x11_ontop(); + return VO_TRUE; + case VOCTRL_BORDER: + vo_x11_border(); + return VO_TRUE; + case VOCTRL_FULLSCREEN: + vo_x11_fullscreen(); + return VO_TRUE; + case VOCTRL_UPDATE_SCREENINFO: + update_xinerama_info(); + return VO_TRUE; + } + + return VO_NOTIMPL; +} diff -Naur --exclude '*.o' --exclude '*.d' --exclude ffmpeg --exclude codec-cfg --exclude codecs.conf.h --exclude 'config.*' --exclude GLES --exclude help_mp.h --exclude mplayer --exclude mencoder --exclude version.h --exclude mplayer.c org/mplayer-export-2011-10-31/Makefile mplayer-export-2011-10-31/Makefile --- org/mplayer-export-2011-10-31/Makefile 2011-10-27 14:16:01.000000000 +0200 +++ mplayer-export-2011-10-31/Makefile 2011-10-31 23:38:39.000000000 +0100 @@ -520,6 +520,7 @@ SRCS_MPLAYER-$(GIF) += libvo/vo_gif89a.c SRCS_MPLAYER-$(GL) += libvo/gl_common.c libvo/vo_gl.c \ libvo/vo_gl2.c libvo/csputils.c +SRCS_MPLAYER-$(GLES) += libvo/vo_gles.c SRCS_MPLAYER-$(GL_SDL) += libvo/sdl_common.c SRCS_MPLAYER-$(GL_WIN32) += libvo/w32_common.c SRCS_MPLAYER-$(GL_X11) += libvo/x11_common.c From diego at biurrun.de Wed Nov 23 13:22:56 2011 From: diego at biurrun.de (Diego Biurrun) Date: Wed, 23 Nov 2011 13:22:56 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111123154030.A22870@localhost> References: <20111123154030.A22870@localhost> Message-ID: <20111123122256.GA11324@pool.informatik.rwth-aachen.de> On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > I needed OpenGL ES X11 output for a device i have so i ended up > writing a gles vo, here it is in case it's useful to others. Patch > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs > support for npot textures. Any comments or improvements are welcome. > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 > @@ -0,0 +1,480 @@ > +/* > + * This file is part of MPlayer. > + * > + * MPlayer is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * MPlayer is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with MPlayer; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * You can alternatively redistribute this file and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + */ This is pointless, read the LGPL ?3 :) You can always upgrade LGPL to any GPL version. So just place this file under LGPL 2.1 to achieve what you want to. Diego From ib at wupperonline.de Wed Nov 23 13:26:59 2011 From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=) Date: Wed, 23 Nov 2011 13:26:59 +0100 Subject: [MPlayer-dev-eng] FFmpeg? sound issue In-Reply-To: <4ecb81dc.7dfa780c.bm000@wupperonline.de> Message-ID: <4ecce694.0e343953.bm001@wupperonline.de> I wrote on Tue, 22 Nov 2011 11:33:08 +0100: > On the other hand, it seems quite clear that ff_imdct36_float_sse() is the > problem. If I force using ff_imdct36_float() instead, everything's fine > again. In case somebody is interested, Vitor (the author) found the bug. Apparently there were SSE2 instructions where they should not be. Thankfully, my outdated CPU is still supported. :-) Ingo From kirin_e at users.sourceforge.net Wed Nov 23 13:33:06 2011 From: kirin_e at users.sourceforge.net (kirin_e at users.sourceforge.net) Date: Wed, 23 Nov 2011 12:33:06 -0000 Subject: [MPlayer-dev-eng] [PATCH] move check_events to after pageflip Message-ID: <20111123161857.A22903@localhost> Hi, when resizing the output window the event is handled by the vo after drawing but before flipping. This means the vo has to redraw/resize the already drawn frame or end up showing an incorrect frame. Attached is a simple patch to mplayer.c that moves check_events to right after the pageflip, so the vo can start drawing the correct size right away instead. /kirin -------------- next part -------------- --- mplayer.c 2011-10-25 22:45:09.000000000 +0200 +++ ../../mplayer-export-2011-10-31/mplayer.c 2011-11-06 02:05:18.000000000 +0100 @@ -3757,11 +3757,6 @@ goto_enable_cache: if (use_gui) gui(GUI_HANDLE_EVENTS, 0); #endif - - current_module = "vo_check_events"; - if (vo_config_count) - mpctx->video_out->check_events(); - #ifdef CONFIG_X11 if (stop_xscreensaver) { current_module = "stop_xscreensaver"; @@ -3794,6 +3789,11 @@ goto_enable_cache: vout_time_usage += (GetTimer() - t2) * 0.000001; } } + + current_module = "vo_check_events"; + if (vo_config_count) + mpctx->video_out->check_events(); + //====================== A-V TIMESTAMP CORRECTION: ========================= adjust_sync_and_print_status(frame_time_remaining, mpctx->time_frame); From cehoyos at ag.or.at Wed Nov 23 14:58:38 2011 From: cehoyos at ag.or.at (Carl Eugen Hoyos) Date: Wed, 23 Nov 2011 13:58:38 +0000 (UTC) Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib References: <20110920181954.GA32134@1und1.de> <1316586506.815.85.camel@valinor.malmo.kicore.net> <4E79AFE3.5050908@free.fr> <20110921144925.GA11022@sushi.unix-ag.uni-kl.de> <4E7A828D.7080401@free.fr> <20110922160031.GB2485@1und1.de> Message-ID: Reimar D?ffinger gmx.de> writes: > I would welcome performance measurements from you, too > (perf record/perf report for example). > Carl will need a while longer before he can provide any. I can still reproduce (with the improved FFmpeg decoder) that -ac mp3 is measurably faster than -ac ffmp3float on a CPU where it actually matters (Pentium SSE, Pentium Mobile). Carl Eugen From onemda at gmail.com Wed Nov 23 19:40:18 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Wed, 23 Nov 2011 18:40:18 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> Message-ID: On 11/18/11, Paul B. Mahol wrote: > On 11/18/11, Paul B. Mahol wrote: > > Additionaly caca1x.diff stop pointless dither recreation calls on > resize. >> > > Oh, this one probably introduce memory leak, but it is easy to fix it > by just adding > > caca_free_dither(dither); > > above caca_create_dither(..) in config() function. Ping. [I would prefer to fix pointless reallocations in separate commit/patch] From rogerdpack2 at gmail.com Wed Nov 23 19:44:51 2011 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 23 Nov 2011 11:44:51 -0700 Subject: [MPlayer-dev-eng] [PATCH] fix OSD decimal output for dvdnav In-Reply-To: References: Message-ID: > Anyway, currently with the OSD decimal output, it gets the "second" > portion from ?demuxer_get_current_time (the NAV packets) and gets the > "decimal portion" of the output from sh_video->pts. > > Since these don't match with DVD's (the NAV packets only occur every > 0.5s, and are usually about 0.1s "off" the MPEG timestamps), it can > lead to odd OSD output, for example: > Feedback welcome. Any chance for a look at this one by someone knowledgeable? I'd be happy to update it if requested, etc. Thanks! -roger- From Reimar.Doeffinger at gmx.de Wed Nov 23 20:10:19 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:10:19 +0100 Subject: [MPlayer-dev-eng] [PATCH] fix OSD decimal output for dvdnav In-Reply-To: References: Message-ID: <20111123191019.GA2955@1und1.de> On Wed, Nov 23, 2011 at 11:44:51AM -0700, Roger Pack wrote: > > Anyway, currently with the OSD decimal output, it gets the "second" > > portion from ?demuxer_get_current_time (the NAV packets) and gets the > > "decimal portion" of the output from sh_video->pts. > > > > Since these don't match with DVD's (the NAV packets only occur every > > 0.5s, and are usually about 0.1s "off" the MPEG timestamps), it can > > lead to odd OSD output, for example: > > > Feedback welcome. > > Any chance for a look at this one by someone knowledgeable? I'd be > happy to update it if requested, etc. The patch seems to absolutely make sense to me, and I have no idea why it was done the way it is right now. From Reimar.Doeffinger at gmx.de Wed Nov 23 20:13:57 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:13:57 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> Message-ID: <20111123191357.GB2955@1und1.de> On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: > On 11/18/11, Reimar Doeffinger wrote: > > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > >> + case CACA_KEY_F1: > >> + case CACA_KEY_F2: > >> + case CACA_KEY_F3: > >> + case CACA_KEY_F4: > >> + case CACA_KEY_F5: > >> + case CACA_KEY_F6: > >> + case CACA_KEY_F7: > >> + case CACA_KEY_F8: > >> + case CACA_KEY_F9: > >> + case CACA_KEY_F10: > >> + case CACA_KEY_F11: > >> + case CACA_KEY_F12: > >> + case CACA_KEY_F13: > >> + case CACA_KEY_F14: > >> + case CACA_KEY_F15: > >> + mplayer_put_key(KEY_F + key - 0x119); > > > > Did you mean - CACA_KEY_F1? That hard-coded 0x119 > > seems like a really bad idea. > > Looks good to me otherwise, except that the issue that > > at most one even is processed per check_events call still > > remains. > > Fixed both issues. Please don't put large reindentations in the same patch as functional changes, it is near impossible to figure out what changed. Also IMHO '\0' is a pointlessly obfuscated way of writing 0. From Reimar.Doeffinger at gmx.de Wed Nov 23 20:16:11 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:16:11 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111123122256.GA11324@pool.informatik.rwth-aachen.de> References: <20111123154030.A22870@localhost> <20111123122256.GA11324@pool.informatik.rwth-aachen.de> Message-ID: <20111123191611.GA3021@1und1.de> On Wed, Nov 23, 2011 at 01:22:56PM +0100, Diego Biurrun wrote: > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > > > I needed OpenGL ES X11 output for a device i have so i ended up > > writing a gles vo, here it is in case it's useful to others. Patch > > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs > > support for npot textures. Any comments or improvements are welcome. > > > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 > > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 > > @@ -0,0 +1,480 @@ > > +/* > > + * This file is part of MPlayer. > > + * > > + * MPlayer is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * MPlayer is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License along > > + * with MPlayer; if not, write to the Free Software Foundation, Inc., > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * You can alternatively redistribute this file and/or > > + * modify it under the terms of the GNU Lesser General Public > > + * License as published by the Free Software Foundation; either > > + * version 2.1 of the License, or (at your option) any later version. > > + */ > > This is pointless, read the LGPL ?3 :) > > You can always upgrade LGPL to any GPL version. So just place this > file under LGPL 2.1 to achieve what you want to. Yes, but he can't place MPlayer under LGPL, which is what the text would claim if you replaced the whole header the LGPL variant. Which is why vo gl uses this convoluted text. From Reimar.Doeffinger at gmx.de Wed Nov 23 20:26:39 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:26:39 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111123154030.A22870@localhost> References: <20111123154030.A22870@localhost> Message-ID: <20111123192639.GB3021@1und1.de> On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > I needed OpenGL ES X11 output for a device i have so i ended up writing a gles vo, here it is in case it's useful to others. Patch against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs support for npot textures. Any comments or improvements are welcome. Thanks, but I do not really like it for several reasons: 1) It is only egl/X11 with no clear way forward 2) It is only 1.1 which without shaders just isn't good performance-wise and horrible for memory bandwidth, particularly when only supporting 24 and 32 bpp input formats 3) I do have an extension to the existing -vo gl that makes it (mostly) work with ES 1.1. The reason it is not committed is that calling the existing EGL implementations "utter shit" would be being too nice which so far made it impossible for me to finish it. In particular, I have seen the eglProcAddress function do any of - return NULL always - crash - return pointers to non-ES functions I have not found a working implementation however. In addition the Ubuntu/BeagleBoard combination hangs the system, requiring a hard reset, after about 3 seconds of using OpenGL ES - at least in combination with xvnc. Apart from that, calling exit_player from a vo is not acceptable. From Reimar.Doeffinger at gmx.de Wed Nov 23 20:35:39 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:35:39 +0100 Subject: [MPlayer-dev-eng] [PATCH] move check_events to after pageflip In-Reply-To: <20111123161857.A22903@localhost> References: <20111123161857.A22903@localhost> Message-ID: <20111123193539.GA3087@1und1.de> On Wed, Nov 23, 2011 at 01:33:07PM +0100, kirin_e at users.sourceforge.net wrote: > when resizing the output window the event is handled by the vo after drawing but before flipping. This means the vo has to redraw/resize the already drawn frame or end up showing an incorrect frame. Attached is a simple patch to mplayer.c that moves check_events to right after the pageflip, so the vo can start drawing the correct size right away instead. I expect that GUI_HANDLE_EVENTS should always be at the same place as the check_events call. From Reimar.Doeffinger at gmx.de Wed Nov 23 20:56:28 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 20:56:28 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111123192639.GB3021@1und1.de> References: <20111123154030.A22870@localhost> <20111123192639.GB3021@1und1.de> Message-ID: <20111123195628.GA9157@1und1.de> On Wed, Nov 23, 2011 at 08:26:39PM +0100, Reimar D?ffinger wrote: > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > I needed OpenGL ES X11 output for a device i have so i ended up writing a gles vo, here it is in case it's useful to others. Patch against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs support for npot textures. Any comments or improvements are welcome. > > Thanks, but I do not really like it for several reasons: > 1) It is only egl/X11 with no clear way forward > 2) It is only 1.1 which without shaders just isn't good performance-wise > and horrible for memory bandwidth, particularly when only supporting > 24 and 32 bpp input formats > 3) I do have an extension to the existing -vo gl that makes it (mostly) > work with ES 1.1. Here is what I have so far btw. I know it is an unfinished, crappy mess right now. However it would make it possible to both reuse features and at runtime chose between OpenGL implementations. It also misses the configure part, so you must define CONFIG_GL_EGL manually. I used this configure line to do all that: ./configure --disable-matrixview --extra-cflags="-mcpu=cortex-a8 -mfpu=neon -DCONFIG_GL_EGL=1" -------------- next part -------------- A non-text attachment was scrubbed... Name: gles.diff Type: text/x-diff Size: 17178 bytes Desc: not available URL: From onemda at gmail.com Wed Nov 23 21:18:29 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Wed, 23 Nov 2011 20:18:29 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: <20111123191357.GB2955@1und1.de> References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> Message-ID: On 11/23/11, Reimar Doeffinger wrote: > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: >> On 11/18/11, Reimar Doeffinger wrote: >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> >> + case CACA_KEY_F1: >> >> + case CACA_KEY_F2: >> >> + case CACA_KEY_F3: >> >> + case CACA_KEY_F4: >> >> + case CACA_KEY_F5: >> >> + case CACA_KEY_F6: >> >> + case CACA_KEY_F7: >> >> + case CACA_KEY_F8: >> >> + case CACA_KEY_F9: >> >> + case CACA_KEY_F10: >> >> + case CACA_KEY_F11: >> >> + case CACA_KEY_F12: >> >> + case CACA_KEY_F13: >> >> + case CACA_KEY_F14: >> >> + case CACA_KEY_F15: >> >> + mplayer_put_key(KEY_F + key - 0x119); >> > >> > Did you mean - CACA_KEY_F1? That hard-coded 0x119 >> > seems like a really bad idea. >> > Looks good to me otherwise, except that the issue that >> > at most one even is processed per check_events call still >> > remains. >> >> Fixed both issues. > > Please don't put large reindentations in the same patch as functional > changes, it is near impossible to figure out what changed. > Also IMHO '\0' is a pointlessly obfuscated way of writing 0. I nowhere see '\0' in first patch. I mentioned that second patch should be really ignored because I will add separate patch after first one is applied because they really should be in separate commit. Also second patch where you see '\0' is from original code and was not introduced by me in any way. From onemda at gmail.com Wed Nov 23 21:27:28 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Wed, 23 Nov 2011 20:27:28 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: <20111123191357.GB2955@1und1.de> References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> Message-ID: On 11/23/11, Reimar Doeffinger wrote: > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: >> On 11/18/11, Reimar Doeffinger wrote: >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> >> + case CACA_KEY_F1: >> >> + case CACA_KEY_F2: >> >> + case CACA_KEY_F3: >> >> + case CACA_KEY_F4: >> >> + case CACA_KEY_F5: >> >> + case CACA_KEY_F6: >> >> + case CACA_KEY_F7: >> >> + case CACA_KEY_F8: >> >> + case CACA_KEY_F9: >> >> + case CACA_KEY_F10: >> >> + case CACA_KEY_F11: >> >> + case CACA_KEY_F12: >> >> + case CACA_KEY_F13: >> >> + case CACA_KEY_F14: >> >> + case CACA_KEY_F15: >> >> + mplayer_put_key(KEY_F + key - 0x119); >> > >> > Did you mean - CACA_KEY_F1? That hard-coded 0x119 >> > seems like a really bad idea. >> > Looks good to me otherwise, except that the issue that >> > at most one even is processed per check_events call still >> > remains. >> >> Fixed both issues. > > Please don't put large reindentations in the same patch as functional > changes, it is near impossible to figure out what changed. > Also IMHO '\0' is a pointlessly obfuscated way of writing 0. Here is patch without reindentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: caca1.diff Type: application/octet-stream Size: 2664 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Wed Nov 23 21:51:47 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Wed, 23 Nov 2011 21:51:47 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> Message-ID: <20111123205147.GA11381@1und1.de> On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: > On 11/23/11, Reimar Doeffinger wrote: > > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: > >> On 11/18/11, Reimar Doeffinger wrote: > >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > >> >> + case CACA_KEY_F1: > >> >> + case CACA_KEY_F2: > >> >> + case CACA_KEY_F3: > >> >> + case CACA_KEY_F4: > >> >> + case CACA_KEY_F5: > >> >> + case CACA_KEY_F6: > >> >> + case CACA_KEY_F7: > >> >> + case CACA_KEY_F8: > >> >> + case CACA_KEY_F9: > >> >> + case CACA_KEY_F10: > >> >> + case CACA_KEY_F11: > >> >> + case CACA_KEY_F12: > >> >> + case CACA_KEY_F13: > >> >> + case CACA_KEY_F14: > >> >> + case CACA_KEY_F15: > >> >> + mplayer_put_key(KEY_F + key - 0x119); > >> > > >> > Did you mean - CACA_KEY_F1? That hard-coded 0x119 > >> > seems like a really bad idea. > >> > Looks good to me otherwise, except that the issue that > >> > at most one even is processed per check_events call still > >> > remains. > >> > >> Fixed both issues. > > > > Please don't put large reindentations in the same patch as functional > > changes, it is near impossible to figure out what changed. > > Also IMHO '\0' is a pointlessly obfuscated way of writing 0. > > Here is patch without reindentation. Why did you replace CACA_EVENT_KEY_RELEASE with CACA_EVENT_KEY_PRESS? All the mplayer_put_key calls in that case pass release events on, not press events. From onemda at gmail.com Wed Nov 23 22:05:20 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Wed, 23 Nov 2011 21:05:20 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: <20111123205147.GA11381@1und1.de> References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> <20111123205147.GA11381@1und1.de> Message-ID: On 11/23/11, Reimar Doeffinger wrote: > On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: >> On 11/23/11, Reimar Doeffinger wrote: >> > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: >> >> On 11/18/11, Reimar Doeffinger wrote: >> >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> >> >> + case CACA_KEY_F1: >> >> >> + case CACA_KEY_F2: >> >> >> + case CACA_KEY_F3: >> >> >> + case CACA_KEY_F4: >> >> >> + case CACA_KEY_F5: >> >> >> + case CACA_KEY_F6: >> >> >> + case CACA_KEY_F7: >> >> >> + case CACA_KEY_F8: >> >> >> + case CACA_KEY_F9: >> >> >> + case CACA_KEY_F10: >> >> >> + case CACA_KEY_F11: >> >> >> + case CACA_KEY_F12: >> >> >> + case CACA_KEY_F13: >> >> >> + case CACA_KEY_F14: >> >> >> + case CACA_KEY_F15: >> >> >> + mplayer_put_key(KEY_F + key - 0x119); >> >> > >> >> > Did you mean - CACA_KEY_F1? That hard-coded 0x119 >> >> > seems like a really bad idea. >> >> > Looks good to me otherwise, except that the issue that >> >> > at most one even is processed per check_events call still >> >> > remains. >> >> >> >> Fixed both issues. >> > >> > Please don't put large reindentations in the same patch as functional >> > changes, it is near impossible to figure out what changed. >> > Also IMHO '\0' is a pointlessly obfuscated way of writing 0. >> >> Here is patch without reindentation. > > Why did you replace CACA_EVENT_KEY_RELEASE with > CACA_EVENT_KEY_PRESS? > All the mplayer_put_key calls in that case pass release > events on, not press events. Really? New behavior mimics other VOs like aa, sdl, x11. From Reimar.Doeffinger at gmx.de Thu Nov 24 00:56:53 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Thu, 24 Nov 2011 00:56:53 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> <20111123205147.GA11381@1und1.de> Message-ID: <20111123235653.GA2233@1und1.de> On Wed, Nov 23, 2011 at 09:05:20PM +0000, Paul B. Mahol wrote: > On 11/23/11, Reimar Doeffinger wrote: > > On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: > >> On 11/23/11, Reimar Doeffinger wrote: > >> > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: > >> >> On 11/18/11, Reimar Doeffinger wrote: > >> >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > >> >> >> + case CACA_KEY_F1: > >> >> >> + case CACA_KEY_F2: > >> >> >> + case CACA_KEY_F3: > >> >> >> + case CACA_KEY_F4: > >> >> >> + case CACA_KEY_F5: > >> >> >> + case CACA_KEY_F6: > >> >> >> + case CACA_KEY_F7: > >> >> >> + case CACA_KEY_F8: > >> >> >> + case CACA_KEY_F9: > >> >> >> + case CACA_KEY_F10: > >> >> >> + case CACA_KEY_F11: > >> >> >> + case CACA_KEY_F12: > >> >> >> + case CACA_KEY_F13: > >> >> >> + case CACA_KEY_F14: > >> >> >> + case CACA_KEY_F15: > >> >> >> + mplayer_put_key(KEY_F + key - 0x119); > >> >> > > >> >> > Did you mean - CACA_KEY_F1? That hard-coded 0x119 > >> >> > seems like a really bad idea. > >> >> > Looks good to me otherwise, except that the issue that > >> >> > at most one even is processed per check_events call still > >> >> > remains. > >> >> > >> >> Fixed both issues. > >> > > >> > Please don't put large reindentations in the same patch as functional > >> > changes, it is near impossible to figure out what changed. > >> > Also IMHO '\0' is a pointlessly obfuscated way of writing 0. > >> > >> Here is patch without reindentation. > > > > Why did you replace CACA_EVENT_KEY_RELEASE with > > CACA_EVENT_KEY_PRESS? > > All the mplayer_put_key calls in that case pass release > > events on, not press events. > > Really? New behavior mimics other VOs like aa, sdl, x11. Hm, strange. Probably has something to do with key repeat only sending press events. Will apply shortly, in parts. From Reimar.Doeffinger at gmx.de Thu Nov 24 01:05:35 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Thu, 24 Nov 2011 01:05:35 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: improve mouse/keyboard handling In-Reply-To: References: <20111118171722.GC2343@1und1.de> <20111123191357.GB2955@1und1.de> Message-ID: <20111124000535.GB2233@1und1.de> On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: > On 11/23/11, Reimar Doeffinger wrote: > > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: > >> On 11/18/11, Reimar Doeffinger wrote: > >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > >> >> + case CACA_KEY_F1: > >> >> + case CACA_KEY_F2: > >> >> + case CACA_KEY_F3: > >> >> + case CACA_KEY_F4: > >> >> + case CACA_KEY_F5: > >> >> + case CACA_KEY_F6: > >> >> + case CACA_KEY_F7: > >> >> + case CACA_KEY_F8: > >> >> + case CACA_KEY_F9: > >> >> + case CACA_KEY_F10: > >> >> + case CACA_KEY_F11: > >> >> + case CACA_KEY_F12: > >> >> + case CACA_KEY_F13: > >> >> + case CACA_KEY_F14: > >> >> + case CACA_KEY_F15: > >> >> + mplayer_put_key(KEY_F + key - 0x119); I just realized (while reindenting) that that's a lot of case statements. IMO this really should be using lookup_keymap_table like x11/w32/sdl code does. From Dan.Oscarsson at tieto.com Thu Nov 24 12:40:09 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Thu, 24 Nov 2011 12:40:09 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1321208675.6469.23.camel@luna.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> Message-ID: <1322134809.30233.89.camel@valinor.malmo.kicore.net> s?n 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson: > Do not know if this patch was lost but it is needed to get h264 data in > mpeg_ts demuxed streams to work correctly. Without it the pts values are > not in order. I suspect that h264 encoded data in other demuxers would > also not be in order without it. Nobody interested in getting this fixed? Dan > > It works fine for me and a friend who watches a lot of DVB-T streams. > > If you want to split it into two parts, the if statement starting with: > + // if many incomplete frames, keep only delay values > + if (!got_picture && sh_video->num_buffered_pts >= delay) > > could be separate as it is to fix so a sequence of bad frames do not > result in oldest pts value used for first valid frame. This can happen > in a DVB-T h264 stream which starts with a lot of partial frames. > > If this is not good, we need to get pts values in order in some other > way to be able to play h264 in mpeg_ts good. From tempn at twmi.rr.com Thu Nov 24 13:33:57 2011 From: tempn at twmi.rr.com (compn) Date: Thu, 24 Nov 2011 07:33:57 -0500 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322134809.30233.89.camel@valinor.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> Message-ID: <20111124073357.1ece084d.tempn@twmi.rr.com> On Thu, 24 Nov 2011 12:40:09 +0100, Dan Oscarsson wrote: >s?n 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson: >> Do not know if this patch was lost but it is needed to get h264 data in >> mpeg_ts demuxed streams to work correctly. Without it the pts values are >> not in order. I suspect that h264 encoded data in other demuxers would >> also not be in order without it. > >Nobody interested in getting this fixed? i thought someone requested this to only happen for h264 in mpegts ? if thats the only type of stream that is having trouble, does it make sense to change the code for all other formats? only my opinion, i dont know the code, nor have i tested the patch. -compn From Reimar.Doeffinger at gmx.de Thu Nov 24 19:21:18 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Thu, 24 Nov 2011 19:21:18 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322134809.30233.89.camel@valinor.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> Message-ID: <20111124182118.GA2210@1und1.de> On Thu, Nov 24, 2011 at 12:40:09PM +0100, Dan Oscarsson wrote: > s?n 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson: > > Do not know if this patch was lost but it is needed to get h264 data in > > mpeg_ts demuxed streams to work correctly. Without it the pts values are > > not in order. I suspect that h264 encoded data in other demuxers would > > also not be in order without it. > > Nobody interested in getting this fixed? The point of -nocorrect-pts mode is to work with slightly incorrect pts value. Just fixing the timestamps for one specific problematic case is more hiding the issue than fixing it, even if it makes sense as an additional improvement to a real fix. From onemda at gmail.com Thu Nov 24 19:22:43 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Thu, 24 Nov 2011 18:22:43 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: use lookup_keymap_table() Message-ID: On 11/24/11, Reimar Doeffinger wrote: > On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: >> On 11/23/11, Reimar Doeffinger wrote: >> > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: >> >> On 11/18/11, Reimar Doeffinger wrote: >> >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> >> >> + case CACA_KEY_F1: >> >> >> + case CACA_KEY_F2: >> >> >> + case CACA_KEY_F3: >> >> >> + case CACA_KEY_F4: >> >> >> + case CACA_KEY_F5: >> >> >> + case CACA_KEY_F6: >> >> >> + case CACA_KEY_F7: >> >> >> + case CACA_KEY_F8: >> >> >> + case CACA_KEY_F9: >> >> >> + case CACA_KEY_F10: >> >> >> + case CACA_KEY_F11: >> >> >> + case CACA_KEY_F12: >> >> >> + case CACA_KEY_F13: >> >> >> + case CACA_KEY_F14: >> >> >> + case CACA_KEY_F15: >> >> >> + mplayer_put_key(KEY_F + key - 0x119); > > I just realized (while reindenting) that that's a lot of case > statements. > IMO this really should be using lookup_keymap_table like x11/w32/sdl > code does. Done. -------------- next part -------------- A non-text attachment was scrubbed... Name: caca3.diff Type: application/octet-stream Size: 3999 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Thu Nov 24 19:34:33 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Thu, 24 Nov 2011 19:34:33 +0100 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: use lookup_keymap_table() In-Reply-To: References: Message-ID: <20111124183433.GA2539@1und1.de> On Thu, Nov 24, 2011 at 06:22:43PM +0000, Paul B. Mahol wrote: > On 11/24/11, Reimar Doeffinger wrote: > > On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: > >> On 11/23/11, Reimar Doeffinger wrote: > >> > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: > >> >> On 11/18/11, Reimar Doeffinger wrote: > >> >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: > >> >> >> + case CACA_KEY_F1: > >> >> >> + case CACA_KEY_F2: > >> >> >> + case CACA_KEY_F3: > >> >> >> + case CACA_KEY_F4: > >> >> >> + case CACA_KEY_F5: > >> >> >> + case CACA_KEY_F6: > >> >> >> + case CACA_KEY_F7: > >> >> >> + case CACA_KEY_F8: > >> >> >> + case CACA_KEY_F9: > >> >> >> + case CACA_KEY_F10: > >> >> >> + case CACA_KEY_F11: > >> >> >> + case CACA_KEY_F12: > >> >> >> + case CACA_KEY_F13: > >> >> >> + case CACA_KEY_F14: > >> >> >> + case CACA_KEY_F15: > >> >> >> + mplayer_put_key(KEY_F + key - 0x119); > > > > I just realized (while reindenting) that that's a lot of case > > statements. > > IMO this really should be using lookup_keymap_table like x11/w32/sdl > > code does. > Done. Thanks, applied. I have to admit that the F key handling makes it a bit less nice than I had expected, though it's still an improvement IMO. Is there actually anyone with a keyboard with more than 12 F keys? (not that it matters, I was just kind of surprised, also you can't currently specify anything above F12 in the MPlayer config) From onemda at gmail.com Thu Nov 24 20:12:02 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Thu, 24 Nov 2011 19:12:02 +0000 Subject: [MPlayer-dev-eng] [PATCH]: vo_caca.c: use lookup_keymap_table() In-Reply-To: <20111124183433.GA2539@1und1.de> References: <20111124183433.GA2539@1und1.de> Message-ID: On 11/24/11, Reimar Doeffinger wrote: > On Thu, Nov 24, 2011 at 06:22:43PM +0000, Paul B. Mahol wrote: >> On 11/24/11, Reimar Doeffinger wrote: >> > On Wed, Nov 23, 2011 at 08:27:28PM +0000, Paul B. Mahol wrote: >> >> On 11/23/11, Reimar Doeffinger wrote: >> >> > On Fri, Nov 18, 2011 at 10:17:13PM +0000, Paul B. Mahol wrote: >> >> >> On 11/18/11, Reimar Doeffinger wrote: >> >> >> > On Thu, Nov 10, 2011 at 02:19:41AM +0000, Paul B. Mahol wrote: >> >> >> >> + case CACA_KEY_F1: >> >> >> >> + case CACA_KEY_F2: >> >> >> >> + case CACA_KEY_F3: >> >> >> >> + case CACA_KEY_F4: >> >> >> >> + case CACA_KEY_F5: >> >> >> >> + case CACA_KEY_F6: >> >> >> >> + case CACA_KEY_F7: >> >> >> >> + case CACA_KEY_F8: >> >> >> >> + case CACA_KEY_F9: >> >> >> >> + case CACA_KEY_F10: >> >> >> >> + case CACA_KEY_F11: >> >> >> >> + case CACA_KEY_F12: >> >> >> >> + case CACA_KEY_F13: >> >> >> >> + case CACA_KEY_F14: >> >> >> >> + case CACA_KEY_F15: >> >> >> >> + mplayer_put_key(KEY_F + key - 0x119); >> > >> > I just realized (while reindenting) that that's a lot of case >> > statements. >> > IMO this really should be using lookup_keymap_table like x11/w32/sdl >> > code does. >> Done. > > Thanks, applied. > I have to admit that the F key handling makes it a bit less nice > than I had expected, though it's still an improvement IMO. > Is there actually anyone with a keyboard with more than 12 F keys? > (not that it matters, I was just kind of surprised, also you can't > currently specify anything above F12 in the MPlayer config) Some keyboards have them more than 15. SDL supports up to F15 and X11 (looking in keysymdef.h) much more. From onemda at gmail.com Thu Nov 24 21:34:55 2011 From: onemda at gmail.com (Paul B. Mahol) Date: Thu, 24 Nov 2011 20:34:55 +0000 Subject: [MPlayer-dev-eng] [PATCH]: caca: stop pointless dither reallocation on resize Message-ID: Dither reallocation on resize is not needed at all. ================================================== diff --git a/libvo/vo_caca.c b/libvo/vo_caca.c index e9892a0..6b89dfe 100644 --- a/libvo/vo_caca.c +++ b/libvo/vo_caca.c @@ -62,11 +62,6 @@ static const char *dither_charset = "default"; static const char *dither_color = "default"; static const char *dither_algo = "none"; -/* image infos */ -static int image_format; -static int image_width; -static int image_height; - static int screen_w, screen_h; /* We want 24bpp always for now */ @@ -139,10 +134,18 @@ static int resize(void) screen_w = caca_get_canvas_width(canvas); screen_h = caca_get_canvas_height(canvas); - caca_free_dither(dither); + return 0; +} + +static int config(uint32_t width, uint32_t height, uint32_t d_width, + uint32_t d_height, uint32_t flags, char *title, + uint32_t format) +{ + showosdmessage = 0; + posbar[0] = '\0'; - dither = caca_create_dither(bpp, image_width, image_height, - depth * image_width, + caca_free_dither(dither); + dither = caca_create_dither(bpp, width, height, depth * width, rmask, gmask, bmask, amask); if (dither == NULL) { mp_msg(MSGT_VO, MSGL_FATAL, "vo_caca: caca_create_dither failed!\n"); @@ -155,20 +158,6 @@ static int resize(void) caca_set_dither_color(dither, dither_color); caca_set_dither_algorithm(dither, dither_algo); - return 0; -} - -static int config(uint32_t width, uint32_t height, uint32_t d_width, - uint32_t d_height, uint32_t flags, char *title, - uint32_t format) -{ - image_height = height; - image_width = width; - image_format = format; - - showosdmessage = 0; - posbar[0] = '\0'; - return resize(); } From diego at biurrun.de Thu Nov 24 22:13:39 2011 From: diego at biurrun.de (Diego Biurrun) Date: Thu, 24 Nov 2011 22:13:39 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111123191611.GA3021@1und1.de> References: <20111123154030.A22870@localhost> <20111123122256.GA11324@pool.informatik.rwth-aachen.de> <20111123191611.GA3021@1und1.de> Message-ID: <20111124211338.GA24468@pool.informatik.rwth-aachen.de> On Wed, Nov 23, 2011 at 08:16:11PM +0100, Reimar D?ffinger wrote: > On Wed, Nov 23, 2011 at 01:22:56PM +0100, Diego Biurrun wrote: > > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > > > > > I needed OpenGL ES X11 output for a device i have so i ended up > > > writing a gles vo, here it is in case it's useful to others. Patch > > > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs > > > support for npot textures. Any comments or improvements are welcome. > > > > > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 > > > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 > > > @@ -0,0 +1,480 @@ > > > +/* > > > + * This file is part of MPlayer. > > > + * > > > + * MPlayer is free software; you can redistribute it and/or modify > > > + * it under the terms of the GNU General Public License as published by > > > + * the Free Software Foundation; either version 2 of the License, or > > > + * (at your option) any later version. > > > + * > > > + * MPlayer is distributed in the hope that it will be useful, > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > + * GNU General Public License for more details. > > > + * > > > + * You should have received a copy of the GNU General Public License along > > > + * with MPlayer; if not, write to the Free Software Foundation, Inc., > > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > > + * > > > + * You can alternatively redistribute this file and/or > > > + * modify it under the terms of the GNU Lesser General Public > > > + * License as published by the Free Software Foundation; either > > > + * version 2.1 of the License, or (at your option) any later version. > > > + */ > > > > This is pointless, read the LGPL ?3 :) > > > > You can always upgrade LGPL to any GPL version. So just place this > > file under LGPL 2.1 to achieve what you want to. > > Yes, but he can't place MPlayer under LGPL, which is what the text would > claim if you replaced the whole header the LGPL variant. > Which is why vo gl uses this convoluted text. I disagree; LGPLing a file does not LGPL MPlayer nor claim it would. The boilerplates all just apply to single files. IMO the convoluted text is just redundant. Diego From Reimar.Doeffinger at gmx.de Thu Nov 24 23:26:49 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Thu, 24 Nov 2011 23:26:49 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111124211338.GA24468@pool.informatik.rwth-aachen.de> References: <20111123154030.A22870@localhost> <20111123122256.GA11324@pool.informatik.rwth-aachen.de> <20111123191611.GA3021@1und1.de> <20111124211338.GA24468@pool.informatik.rwth-aachen.de> Message-ID: <20111124222649.GA2190@1und1.de> On Thu, Nov 24, 2011 at 10:13:39PM +0100, Diego Biurrun wrote: > On Wed, Nov 23, 2011 at 08:16:11PM +0100, Reimar D?ffinger wrote: > > On Wed, Nov 23, 2011 at 01:22:56PM +0100, Diego Biurrun wrote: > > > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > > > > > > > I needed OpenGL ES X11 output for a device i have so i ended up > > > > writing a gles vo, here it is in case it's useful to others. Patch > > > > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs > > > > support for npot textures. Any comments or improvements are welcome. > > > > > > > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 > > > > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 > > > > @@ -0,0 +1,480 @@ > > > > +/* > > > > + * This file is part of MPlayer. > > > > + * > > > > + * MPlayer is free software; you can redistribute it and/or modify > > > > + * it under the terms of the GNU General Public License as published by > > > > + * the Free Software Foundation; either version 2 of the License, or > > > > + * (at your option) any later version. > > > > + * > > > > + * MPlayer is distributed in the hope that it will be useful, > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > > + * GNU General Public License for more details. > > > > + * > > > > + * You should have received a copy of the GNU General Public License along > > > > + * with MPlayer; if not, write to the Free Software Foundation, Inc., > > > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > > > + * > > > > + * You can alternatively redistribute this file and/or > > > > + * modify it under the terms of the GNU Lesser General Public > > > > + * License as published by the Free Software Foundation; either > > > > + * version 2.1 of the License, or (at your option) any later version. > > > > + */ > > > > > > This is pointless, read the LGPL ?3 :) > > > > > > You can always upgrade LGPL to any GPL version. So just place this > > > file under LGPL 2.1 to achieve what you want to. > > > > Yes, but he can't place MPlayer under LGPL, which is what the text would > > claim if you replaced the whole header the LGPL variant. > > Which is why vo gl uses this convoluted text. > > I disagree; LGPLing a file does not LGPL MPlayer nor claim it would. If the text ends up saying MPlayer is free software; you can redistribute it and/or modify it under the terms of the LGPL It sure as hell claims that MPlayer is LGPL, and not just that file. it probably is quite irrelevant legally but I am not fine with having nonsense in the license boilerplate, that kind of defeats the purpose of having them in the first place (and IMHO is a lot worse than just not having them at all). From diego at biurrun.de Fri Nov 25 00:22:57 2011 From: diego at biurrun.de (Diego Biurrun) Date: Fri, 25 Nov 2011 00:22:57 +0100 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111124222649.GA2190@1und1.de> References: <20111123154030.A22870@localhost> <20111123122256.GA11324@pool.informatik.rwth-aachen.de> <20111123191611.GA3021@1und1.de> <20111124211338.GA24468@pool.informatik.rwth-aachen.de> <20111124222649.GA2190@1und1.de> Message-ID: <20111124232256.GB24468@pool.informatik.rwth-aachen.de> On Thu, Nov 24, 2011 at 11:26:49PM +0100, Reimar D?ffinger wrote: > On Thu, Nov 24, 2011 at 10:13:39PM +0100, Diego Biurrun wrote: > > On Wed, Nov 23, 2011 at 08:16:11PM +0100, Reimar D?ffinger wrote: > > > On Wed, Nov 23, 2011 at 01:22:56PM +0100, Diego Biurrun wrote: > > > > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: > > > > > > > > > > I needed OpenGL ES X11 output for a device i have so i ended up > > > > > writing a gles vo, here it is in case it's useful to others. Patch > > > > > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs > > > > > support for npot textures. Any comments or improvements are welcome. > > > > > > > > > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 > > > > > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 > > > > > @@ -0,0 +1,480 @@ > > > > > +/* > > > > > + * This file is part of MPlayer. > > > > > + * > > > > > + * MPlayer is free software; you can redistribute it and/or modify > > > > > + * it under the terms of the GNU General Public License as published by > > > > > + * the Free Software Foundation; either version 2 of the License, or > > > > > + * (at your option) any later version. > > > > > + * > > > > > + * MPlayer is distributed in the hope that it will be useful, > > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > > > > + * GNU General Public License for more details. > > > > > + * > > > > > + * You should have received a copy of the GNU General Public License along > > > > > + * with MPlayer; if not, write to the Free Software Foundation, Inc., > > > > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > > > > > + * > > > > > + * You can alternatively redistribute this file and/or > > > > > + * modify it under the terms of the GNU Lesser General Public > > > > > + * License as published by the Free Software Foundation; either > > > > > + * version 2.1 of the License, or (at your option) any later version. > > > > > + */ > > > > > > > > This is pointless, read the LGPL ?3 :) > > > > > > > > You can always upgrade LGPL to any GPL version. So just place this > > > > file under LGPL 2.1 to achieve what you want to. > > > > > > Yes, but he can't place MPlayer under LGPL, which is what the text would > > > claim if you replaced the whole header the LGPL variant. > > > Which is why vo gl uses this convoluted text. > > > > I disagree; LGPLing a file does not LGPL MPlayer nor claim it would. > > If the text ends up saying > MPlayer is free software; you can redistribute it and/or modify > it under the terms of the LGPL > It sure as hell claims that MPlayer is LGPL, and not just that file. > it probably is quite irrelevant legally but I am not fine with having > nonsense in the license boilerplate, that kind of defeats the purpose > of having them in the first place (and IMHO is a lot worse than just > not having them at all). FWIW, we are already in that situation due to some v2-only code, while the boilerplates claim v2+. Diego From tempn at twmi.rr.com Fri Nov 25 00:43:28 2011 From: tempn at twmi.rr.com (compn) Date: Thu, 24 Nov 2011 18:43:28 -0500 Subject: [MPlayer-dev-eng] [PATCH] add Opengl ES vo In-Reply-To: <20111124232256.GB24468@pool.informatik.rwth-aachen.de> References: <20111123154030.A22870@localhost> <20111123122256.GA11324@pool.informatik.rwth-aachen.de> <20111123191611.GA3021@1und1.de> <20111124211338.GA24468@pool.informatik.rwth-aachen.de> <20111124222649.GA2190@1und1.de> <20111124232256.GB24468@pool.informatik.rwth-aachen.de> Message-ID: <20111124184328.bd160b8b.tempn@twmi.rr.com> On Fri, 25 Nov 2011 00:22:57 +0100, Diego Biurrun wrote: >On Thu, Nov 24, 2011 at 11:26:49PM +0100, Reimar D?ffinger wrote: >> On Thu, Nov 24, 2011 at 10:13:39PM +0100, Diego Biurrun wrote: >> > On Wed, Nov 23, 2011 at 08:16:11PM +0100, Reimar D?ffinger wrote: >> > > On Wed, Nov 23, 2011 at 01:22:56PM +0100, Diego Biurrun wrote: >> > > > On Wed, Nov 23, 2011 at 01:02:43PM +0100, kirin_e at users.sourceforge.net wrote: >> > > > > >> > > > > I needed OpenGL ES X11 output for a device i have so i ended up >> > > > > writing a gles vo, here it is in case it's useful to others. Patch >> > > > > against snapshot 2011-10-31, uses OpenGL ES 1.1 and currently needs >> > > > > support for npot textures. Any comments or improvements are welcome. >> > > > > >> > > > > --- org/mplayer-export-2011-10-31/libvo/vo_gles.c 1970-01-01 01:00:00.000000000 +0100 >> > > > > +++ mplayer-export-2011-10-31/libvo/vo_gles.c 2011-11-23 03:52:53.000000000 +0100 >> > > > > @@ -0,0 +1,480 @@ >> > > > > +/* >> > > > > + * This file is part of MPlayer. >> > > > > + * >> > > > > + * MPlayer is free software; you can redistribute it and/or modify >> > > > > + * it under the terms of the GNU General Public License as published by >> > > > > + * the Free Software Foundation; either version 2 of the License, or >> > > > > + * (at your option) any later version. >> > > > > + * >> > > > > + * MPlayer is distributed in the hope that it will be useful, >> > > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> > > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> > > > > + * GNU General Public License for more details. >> > > > > + * >> > > > > + * You should have received a copy of the GNU General Public License along >> > > > > + * with MPlayer; if not, write to the Free Software Foundation, Inc., >> > > > > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. >> > > > > + * >> > > > > + * You can alternatively redistribute this file and/or >> > > > > + * modify it under the terms of the GNU Lesser General Public >> > > > > + * License as published by the Free Software Foundation; either >> > > > > + * version 2.1 of the License, or (at your option) any later version. >> > > > > + */ >> > > > >> > > > This is pointless, read the LGPL ?3 :) >> > > > >> > > > You can always upgrade LGPL to any GPL version. So just place this >> > > > file under LGPL 2.1 to achieve what you want to. >> > > >> > > Yes, but he can't place MPlayer under LGPL, which is what the text would >> > > claim if you replaced the whole header the LGPL variant. >> > > Which is why vo gl uses this convoluted text. >> > >> > I disagree; LGPLing a file does not LGPL MPlayer nor claim it would. >> >> If the text ends up saying >> MPlayer is free software; you can redistribute it and/or modify >> it under the terms of the LGPL >> It sure as hell claims that MPlayer is LGPL, and not just that file. >> it probably is quite irrelevant legally but I am not fine with having >> nonsense in the license boilerplate, that kind of defeats the purpose >> of having them in the first place (and IMHO is a lot worse than just >> not having them at all). > >FWIW, we are already in that situation due to some v2-only code, while >the boilerplates claim v2+. could just change it to 'this file is licensed under lgpl v2 only' ... -compn From vseryakov at gmail.com Fri Nov 25 05:53:53 2011 From: vseryakov at gmail.com (Vlad Seryakov) Date: Thu, 24 Nov 2011 23:53:53 -0500 Subject: [MPlayer-dev-eng] [RFC] Playing growing file Message-ID: Hi, This is just some crazy idea i am thinking about while trying to figure out how to play MPEG TS recordings with mplayer. Really this is not full timeshift solution and never be, player is just a player but supporting growing file may be very useful. I decided to try with adding one function to stream_file.c which will handle pipe:// urls and just use different fill_buffer function which indefinitely reads from file but process events to avoid hangs. Just wondetng what other think about this solution. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: stream_file.c Type: application/octet-stream Size: 6371 bytes Desc: not available URL: From vseryakov at gmail.com Fri Nov 25 05:57:32 2011 From: vseryakov at gmail.com (Vlad Seryakov) Date: Thu, 24 Nov 2011 23:57:32 -0500 Subject: [MPlayer-dev-eng] [RFC] Playing growing file Message-ID: <04FAF4E5-1B46-484B-B913-D228627BD8B4@gmail.com> Oops, sorry, sent wrong file. This is the correct one with copy of the whole message: Hi, This is just some crazy idea i am thinking about while trying to figure out how to play MPEG TS recordings with mplayer. Really this is not full timeshift solution and never be, player is just a player but supporting growing file may be very useful. I decided to try with adding one function to stream_file.c which will handle pipe:// urls and just use different fill_buffer function which indefinitely reads from file but process events to avoid hangs. Just wondetng what other think about this solution. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: stream_file.c Type: application/octet-stream Size: 6370 bytes Desc: not available URL: From tempn at twmi.rr.com Fri Nov 25 06:37:22 2011 From: tempn at twmi.rr.com (compn) Date: Fri, 25 Nov 2011 00:37:22 -0500 Subject: [MPlayer-dev-eng] [RFC] Playing growing file In-Reply-To: References: Message-ID: <20111125003722.7f2f2379.tempn@twmi.rr.com> On Thu, 24 Nov 2011 23:53:53 -0500, Vlad Seryakov wrote: >Just wondetng what other think about this solution. awesome. lots of people want the ability to play growing files. i dont know the code so i cant review. thanks for posting. -compn From Dan.Oscarsson at tieto.com Fri Nov 25 08:07:06 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Fri, 25 Nov 2011 08:07:06 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111124182118.GA2210@1und1.de> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> Message-ID: <1322204826.30233.110.camel@valinor.malmo.kicore.net> tor 2011-11-24 klockan 19:21 +0100 skrev Reimar D?ffinger: > On Thu, Nov 24, 2011 at 12:40:09PM +0100, Dan Oscarsson wrote: > > s?n 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson: > > > Do not know if this patch was lost but it is needed to get h264 data in > > > mpeg_ts demuxed streams to work correctly. Without it the pts values are > > > not in order. I suspect that h264 encoded data in other demuxers would > > > also not be in order without it. > > > > Nobody interested in getting this fixed? > > The point of -nocorrect-pts mode is to work with slightly incorrect pts > value. When pts values are out of order it is not slight. > Just fixing the timestamps for one specific problematic case is more > hiding the issue than fixing it, even if it makes sense as an additional > improvement to a real fix. I have the feeling that nobody is going to fix the bad demux_* demuxers so they do "correct_pts". From my experience, the demuxer I have used that do not set correct_pts generate good enough pts values execpt those that do not have pts values in order. In my own patches I have code reduces the error in the slightly bad pts values (and the errors in the so called correct_pts demuxers) but I cannot fix out of order pts values that easy. Doing that is probably easiest at the place of this patch. Dan From Dan.Oscarsson at tieto.com Sat Nov 26 17:00:29 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sat, 26 Nov 2011 17:00:29 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322204826.30233.110.camel@valinor.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> Message-ID: <1322323229.7101.6.camel@luna.malmo.kicore.net> fre 2011-11-25 klockan 08:07 +0100 skrev Dan Oscarsson: > tor 2011-11-24 klockan 19:21 +0100 skrev Reimar D?ffinger: > > Just fixing the timestamps for one specific problematic case is more > > hiding the issue than fixing it, even if it makes sense as an additional > > improvement to a real fix. Looking at the code I see that MP_IMGTYPE_INCOMPLETE is only used for h264 decoding by ffmpeg, so my code might just fix the h264 case. Though I am not sure exactly what cases different demuxer/decoders return value for the reorder routine to use. Mostly what I have done is to enable reorder for more cases then just correct_pts. Attached is an alternativ way to do the patch that may look a bit cleaner. I think it could be even simpler by allowing MP_NOPTS_VALUE to be reordered and I suspect the limiting to delay values in the end could be replaced by simpler code in the beginning. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: reorder-alt.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: From Dan.Oscarsson at tieto.com Sat Nov 26 19:41:00 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sat, 26 Nov 2011 19:41:00 +0100 Subject: [MPlayer-dev-eng] threaded cache Message-ID: <1322332860.7101.9.camel@luna.malmo.kicore.net> Attached is a patch to use pthreads instead of fork when pthread is available. Timing on my machine gives faster response for calls to cache_do_control. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: threaded-cache.patch Type: text/x-patch Size: 2927 bytes Desc: not available URL: From mosgalin at VM10124.spb.edu Sun Nov 27 01:10:21 2011 From: mosgalin at VM10124.spb.edu (Vladimir Mosgalin) Date: Sun, 27 Nov 2011 04:10:21 +0400 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322332860.7101.9.camel@luna.malmo.kicore.net> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> Message-ID: <20111127001021.GA6250@VM10124.spb.edu> Hi Dan Oscarsson! On 2011.11.26 at 19:41:00 +0100, Dan Oscarsson wrote next: > > Attached is a patch to use pthreads instead of fork when pthread is > available. Timing on my machine gives faster response for calls to > cache_do_control. > This is quite interesting (as I understand, it also should fix "hanged mplayer process" problem? I have this often, when mplayer crashes there is another process left behind which hangs until killed manually). However, it doesn't compile as it is, at least on Fedora 16. When linking, there is error: /usr/bin/ld: stream/cache2.o: undefined reference to symbol 'clock_gettime@@GLIBC_2.2.5' /usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO /lib64/librt.so.1 so try adding it to the linker command line /lib64/librt.so.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status make: *** [mencoder] ?????? 1 make: *** ???????? ?????????? ???????... /usr/bin/ld: stream/cache2.o: undefined reference to symbol 'clock_gettime@@GLIBC_2.2.5' /usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO /lib64/librt.so.1 so try adding it to the linker command line /lib64/librt.so.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status make: *** [mplayer] ?????? 1 Adding -lrt to EXTRALIBS in config.mak fixes it. -- Vladimir From rjiejie at gmail.com Sun Nov 27 02:47:09 2011 From: rjiejie at gmail.com (jojo) Date: Sun, 27 Nov 2011 09:47:09 +0800 Subject: [MPlayer-dev-eng] (no subject) Message-ID: unsubscribe B.R -- jojo From auerswal at unix-ag.uni-kl.de Sun Nov 27 13:56:40 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 27 Nov 2011 13:56:40 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322332860.7101.9.camel@luna.malmo.kicore.net> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> Message-ID: <4ED23388.4070102@unix-ag.uni-kl.de> Hi Dan, On 11/26/2011 07:41 PM, Dan Oscarsson wrote: > Attached is a patch to use pthreads instead of fork when pthread is > available. Timing on my machine gives faster response for calls to > cache_do_control. I have tested your patch with DVB, DVD, and HD MKV videos, as well as MP3 music (streaming via HTTP and files). I did not notice any differences (besides only one mplayer process). How can I check for the faster cache response you mentioned? Regards, Erik From Dan.Oscarsson at tieto.com Sun Nov 27 14:59:19 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sun, 27 Nov 2011 14:59:19 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <4ED23388.4070102@unix-ag.uni-kl.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <4ED23388.4070102@unix-ag.uni-kl.de> Message-ID: <1322402359.8465.3.camel@luna.malmo.kicore.net> s?n 2011-11-27 klockan 13:56 +0100 skrev Erik Auerswald: > Hi Dan, > > On 11/26/2011 07:41 PM, Dan Oscarsson wrote: > > Attached is a patch to use pthreads instead of fork when pthread is > > available. Timing on my machine gives faster response for calls to > > cache_do_control. > > I have tested your patch with DVB, DVD, and HD MKV videos, as well as > MP3 music (streaming via HTTP and files). I did not notice any > differences (besides only one mplayer process). > > How can I check for the faster cache response you mentioned? My measurements was on cache_do_control and you will probably not notice the difference as in all my cases they were below 50 milliseconds. And for most files cache_do_control is only called at beginning and end of playing, a few also calls it on seek. But still, even the fork version is to quick for most people to notice any delay. The only difference most will see is that there is only one mplayer process. Dan From Reimar.Doeffinger at gmx.de Sun Nov 27 16:03:26 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:03:26 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322204826.30233.110.camel@valinor.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> Message-ID: <20111127150326.GA2154@1und1.de> On Fri, Nov 25, 2011 at 08:07:06AM +0100, Dan Oscarsson wrote: > tor 2011-11-24 klockan 19:21 +0100 skrev Reimar D?ffinger: > > On Thu, Nov 24, 2011 at 12:40:09PM +0100, Dan Oscarsson wrote: > > > s?n 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson: > > > > Do not know if this patch was lost but it is needed to get h264 data in > > > > mpeg_ts demuxed streams to work correctly. Without it the pts values are > > > > not in order. I suspect that h264 encoded data in other demuxers would > > > > also not be in order without it. > > > > > > Nobody interested in getting this fixed? > > > > The point of -nocorrect-pts mode is to work with slightly incorrect pts > > value. > > When pts values are out of order it is not slight. It is at most one consecutive PTS value that is wrong and it's only by a few frame times. Compared to some possibly really corrupt streams that is minimal. Particularly since we would usually have one or more following PTS values. > > Just fixing the timestamps for one specific problematic case is more > > hiding the issue than fixing it, even if it makes sense as an additional > > improvement to a real fix. > > I have the feeling that nobody is going to fix the bad demux_* demuxers > so they do "correct_pts". From my experience, the demuxer I have used > that do not set correct_pts generate good enough pts values execpt those > that do not have pts values in order. In my own patches I have code > reduces the error in the slightly bad pts values (and the errors in the > so called correct_pts demuxers) but I cannot fix out of order pts values > that easy. What do you consider "slightly bad" when out of order doesn't qualify? If it can handle actually corrupted pts values I'd expect it should handle reordering as well, at most hierarchical B might cause problems. From Reimar.Doeffinger at gmx.de Sun Nov 27 16:12:00 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:12:00 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322332860.7101.9.camel@luna.malmo.kicore.net> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> Message-ID: <20111127151200.GB2154@1und1.de> On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > +#if defined(PTHREAD_CACHE) > + pthread_mutex_lock(&s->go_ahead_mutex); > + clock_gettime(CLOCK_REALTIME, &ts); > + ts.tv_nsec += sleep_time*1000; > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); Operating systems do not have to provide (and some, including older Linux do not) provide a monotonous clock. I very strongly dislike usage of such inherently unportable stuff (I blame pthreads for relying on absolute timeouts (which is reasonable) without providing for a time source). From Reimar.Doeffinger at gmx.de Sun Nov 27 16:15:20 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:15:20 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127151200.GB2154@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> Message-ID: <20111127151520.GA2812@1und1.de> On Sun, Nov 27, 2011 at 04:12:00PM +0100, Reimar D?ffinger wrote: > On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > > +#if defined(PTHREAD_CACHE) > > + pthread_mutex_lock(&s->go_ahead_mutex); > > + clock_gettime(CLOCK_REALTIME, &ts); > > + ts.tv_nsec += sleep_time*1000; > > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); > > Operating systems do not have to provide (and some, including older > Linux do not) provide a monotonous clock. > I very strongly dislike usage of such inherently unportable stuff > (I blame pthreads for relying on absolute timeouts (which is reasonable) > without providing for a time source). Ha, they actually did think of that: pthread_get_expiration_np Except for "Note: This function is not portable." *facepalm* WTF is the point of it then? Hey, we saw there's a portability issue with our API. Let's add a non-portable API to solve it! From Reimar.Doeffinger at gmx.de Sun Nov 27 16:31:29 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:31:29 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322332860.7101.9.camel@luna.malmo.kicore.net> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> Message-ID: <20111127153129.GA2860@1und1.de> On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > +#if defined(PTHREAD_CACHE) Just use #ifdef > +#if defined(PTHREAD_CACHE) > + if (pthread_mutex_init(&s->go_ahead_mutex, NULL) || pthread_cond_init(&s->go_ahead, NULL)) { > + shared_free(s->buffer, s->buffer_size); > + shared_free(s, sizeof(cache_vars_t)); TO be pedantic if only thread init fails you'd have to destroy the mutex. > + return NULL; Might be too much effort but in principle it would be nice if it could fall-back, both to pthreads without mutex/condition and to forked thread. Not really important though. Also, shouldn't cache_uninit already be called and handle this? Also, cache_uninit NULLs these after freeing them. > @@ -383,10 +402,14 @@ > */ > static void cache_mainloop(cache_vars_t *s) { > int sleep_count = 0; > + int sleep_time; > #if FORKED_CACHE > struct sigaction sa = { .sa_handler = SIG_IGN }; > sigaction(SIGUSR1, &sa, NULL); > #endif > +#if defined(PTHREAD_CACHE) > + struct timespec ts; > +#endif I prefer declarations to be in the innermost block they can be, it tends to make it easier to follow the data flow and also to refactor into new functions. > @@ -398,9 +421,18 @@ > #endif > if (sleep_count < INITIAL_FILL_USLEEP_COUNT) { > sleep_count++; > - usec_sleep(INITIAL_FILL_USLEEP_TIME); > + sleep_time = INITIAL_FILL_USLEEP_TIME; > } else > - usec_sleep(FILL_USLEEP_TIME); // idle > + sleep_time = FILL_USLEEP_TIME; // idle > +#if defined(PTHREAD_CACHE) > + pthread_mutex_lock(&s->go_ahead_mutex); > + clock_gettime(CLOCK_REALTIME, &ts); > + ts.tv_nsec += sleep_time*1000; > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); > + pthread_mutex_unlock(&s->go_ahead_mutex); > +#else > + usec_sleep(sleep_time); > +#endif I'd expect that the latency for command-handling is more relevant than here - under normal operation we should never get into this loop (ok, except for seeking, but there it should never really matter among other delays). The problem is that the critical wait is "hidden" inside stream_check_interrupt. > --- configure.org 2011-11-05 18:04:43.207091149 +0100 > +++ configure 2011-11-20 13:13:20.626348701 +0100 > @@ -3590,14 +3590,12 @@ > fi > echores "$_pthreads" > > -if cygwin ; then > if test "$_pthreads" = yes ; then > def_pthread_cache="#define PTHREAD_CACHE 1" > else > _stream_cache=no > def_stream_cache="#undef CONFIG_STREAM_CACHE" > fi > -fi That is wrong, cache shouldn't be disabled completely when pthreads are not available, only when cygwin _and_ pthreads not available, your code will disable thread-based cache on Windows and possibly also cache on other OS. From Reimar.Doeffinger at gmx.de Sun Nov 27 16:35:12 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:35:12 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127153129.GA2860@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127153129.GA2860@1und1.de> Message-ID: <20111127153512.GA2946@1und1.de> On Sun, Nov 27, 2011 at 04:31:29PM +0100, Reimar D?ffinger wrote: > On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > > @@ -398,9 +421,18 @@ > > #endif > > if (sleep_count < INITIAL_FILL_USLEEP_COUNT) { > > sleep_count++; > > - usec_sleep(INITIAL_FILL_USLEEP_TIME); > > + sleep_time = INITIAL_FILL_USLEEP_TIME; > > } else > > - usec_sleep(FILL_USLEEP_TIME); // idle > > + sleep_time = FILL_USLEEP_TIME; // idle > > +#if defined(PTHREAD_CACHE) > > + pthread_mutex_lock(&s->go_ahead_mutex); > > + clock_gettime(CLOCK_REALTIME, &ts); > > + ts.tv_nsec += sleep_time*1000; > > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); > > + pthread_mutex_unlock(&s->go_ahead_mutex); > > +#else > > + usec_sleep(sleep_time); > > +#endif > > I'd expect that the latency for command-handling is more relevant than > here - under normal operation we should never get into this loop (ok, > except for seeking, but there it should never really matter among other > delays). > The problem is that the critical wait is "hidden" inside > stream_check_interrupt. Please ignore that part, I misremembered who wakes up whom. From Reimar.Doeffinger at gmx.de Sun Nov 27 16:56:31 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 16:56:31 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127151520.GA2812@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> Message-ID: <20111127155631.GA3087@1und1.de> On Sun, Nov 27, 2011 at 04:15:20PM +0100, Reimar D?ffinger wrote: > On Sun, Nov 27, 2011 at 04:12:00PM +0100, Reimar D?ffinger wrote: > > On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > > > +#if defined(PTHREAD_CACHE) > > > + pthread_mutex_lock(&s->go_ahead_mutex); > > > + clock_gettime(CLOCK_REALTIME, &ts); > > > + ts.tv_nsec += sleep_time*1000; > > > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); > > > > Operating systems do not have to provide (and some, including older > > Linux do not) provide a monotonous clock. > > I very strongly dislike usage of such inherently unportable stuff > > (I blame pthreads for relying on absolute timeouts (which is reasonable) > > without providing for a time source). > > Ha, they actually did think of that: > pthread_get_expiration_np > Except for "Note: This function is not portable." *facepalm* WTF is the > point of it then? Hey, we saw there's a portability issue with our API. > Let's add a non-portable API to solve it! I read about everything I could find about it. My conclusion is that pthread_cond_timedwait is full of race conditions, even on systems that _do_ support a monotonic clock that it is completely unusable if you actually need to rely on the timeout. Or to write it in bold: THERE IS NO WAY TO USE pthread_cond_timedwait CORRECTLY. From Reimar.Doeffinger at gmx.de Sun Nov 27 17:11:01 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 17:11:01 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127155631.GA3087@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> Message-ID: <20111127161101.GA3222@1und1.de> On Sun, Nov 27, 2011 at 04:56:31PM +0100, Reimar D?ffinger wrote: > On Sun, Nov 27, 2011 at 04:15:20PM +0100, Reimar D?ffinger wrote: > > On Sun, Nov 27, 2011 at 04:12:00PM +0100, Reimar D?ffinger wrote: > > > On Sat, Nov 26, 2011 at 07:41:00PM +0100, Dan Oscarsson wrote: > > > > +#if defined(PTHREAD_CACHE) > > > > + pthread_mutex_lock(&s->go_ahead_mutex); > > > > + clock_gettime(CLOCK_REALTIME, &ts); > > > > + ts.tv_nsec += sleep_time*1000; > > > > + pthread_cond_timedwait(&s->go_ahead, &s->go_ahead_mutex, &ts); > > > > > > Operating systems do not have to provide (and some, including older > > > Linux do not) provide a monotonous clock. > > > I very strongly dislike usage of such inherently unportable stuff > > > (I blame pthreads for relying on absolute timeouts (which is reasonable) > > > without providing for a time source). > > > > Ha, they actually did think of that: > > pthread_get_expiration_np > > Except for "Note: This function is not portable." *facepalm* WTF is the > > point of it then? Hey, we saw there's a portability issue with our API. > > Let's add a non-portable API to solve it! > > I read about everything I could find about it. > My conclusion is that pthread_cond_timedwait is full of race conditions, > even on systems that _do_ support a monotonic clock that it is > completely unusable if you actually need to rely on the timeout. > Or to write it in bold: > THERE IS NO WAY TO USE pthread_cond_timedwait CORRECTLY. Sorry for the mail SPAM. Using pthread_condattr_setclock to select the monotonic clock might actually work. However note that glibc pthreads depending on which kernel it was compiled against might silently ignore it by what I can tell - in which case using it you get guaranteed breakage instead of a race condition. Even ignoring that you are deep, deep into non-portable territory when using CLOCK_MONOTONIC. I also admit that MPlayer currently won't behave fully correctly with system clock changes anyway, however I think it at least will not hang completely (which maybe it would when pthread_cond_timedwait does not work correctly here - not sure, the main thread might just end up waking it up as soon as the user attempts a seek operation or something, not sure it always will). From andrej at rep.kiev.ua Sun Nov 27 17:20:12 2011 From: andrej at rep.kiev.ua (Andrej N. Gritsenko) Date: Sun, 27 Nov 2011 18:20:12 +0200 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127155631.GA3087@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> Message-ID: <20111127162012.GC21024@rep.kiev.ua> Hello! On Sun, Nov 27, 2011, around 17:56, Reimar D?ffinger wrote: >I read about everything I could find about it. >My conclusion is that pthread_cond_timedwait is full of race conditions, >even on systems that _do_ support a monotonic clock that it is >completely unusable if you actually need to rely on the timeout. >Or to write it in bold: >THERE IS NO WAY TO USE pthread_cond_timedwait CORRECTLY. Just my 5 cents. I don't know what exactly you've read but I use that POSIX function pthread_cond_timedwait() in application with multiple streams and I have no problems with it as time isn't main its purpose at all, only usage of the time flow in such function is to return from it after some period of time but main purpose of it is to wait for external event (such as cache request). In many cases it is possible to replace pthread_cond_timedwait with pthread_cond_wait. It's absolutely irrelevant to any realtime or monotonic clock is what I mean. :) With best wishes. Andriy. From Reimar.Doeffinger at gmx.de Sun Nov 27 17:29:41 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 17:29:41 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127162012.GC21024@rep.kiev.ua> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127162012.GC21024@rep.kiev.ua> Message-ID: <20111127162941.GA3654@1und1.de> On Sun, Nov 27, 2011 at 06:20:12PM +0200, Andrej N. Gritsenko wrote: > On Sun, Nov 27, 2011, around 17:56, Reimar D?ffinger wrote: > >I read about everything I could find about it. > >My conclusion is that pthread_cond_timedwait is full of race conditions, > >even on systems that _do_ support a monotonic clock that it is > >completely unusable if you actually need to rely on the timeout. > >Or to write it in bold: > >THERE IS NO WAY TO USE pthread_cond_timedwait CORRECTLY. > > Just my 5 cents. > > I don't know what exactly you've read but I use that POSIX function > pthread_cond_timedwait() in application with multiple streams and I have > no problems with it as time isn't main its purpose at all, only usage of > the time flow in such function is to return from it after some period of > time but main purpose of it is to wait for external event (such as cache > request). In many cases it is possible to replace pthread_cond_timedwait > with pthread_cond_wait. It's absolutely irrelevant to any realtime or > monotonic clock is what I mean. :) The usage here is quite opposite: It is absolutely critical it will return within the given interval, the only purpose of the condition is to make it return earlier. From andrej at rep.kiev.ua Sun Nov 27 17:32:03 2011 From: andrej at rep.kiev.ua (Andrej N. Gritsenko) Date: Sun, 27 Nov 2011 18:32:03 +0200 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127161101.GA3222@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> Message-ID: <20111127163203.GD21024@rep.kiev.ua> Hello! >I also admit that MPlayer currently won't behave fully correctly with >system clock changes anyway, however I think it at least will not hang >completely (which maybe it would when pthread_cond_timedwait does not >work correctly here - not sure, the main thread might just end up waking >it up as soon as the user attempts a seek operation or something, not >sure it always will). I have my application (which I mentioned earlier) running on the system where time clock is very unstable (and it's not Linux BTW but OpenIndiana variation of Solaris OS) and I have no problems with waking up from the pthread_cond_timedwait in all cases (positive and negative drifts) so don't worry, it always will. :) With best wishes. Andriy. From Reimar.Doeffinger at gmx.de Sun Nov 27 17:37:33 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 17:37:33 +0100 Subject: [MPlayer-dev-eng] [PATCH] make cache process exit when parent died Message-ID: <20111127163733.GA3719@1und1.de> Hello, a few people (including me) have been quite annoyed with MPlayer leaving its cache process around if it crashes in a way the signal handler cannot handle. Attached is a patch that makes the cache process check its parent process ID, and if it changed it terminates itself, assuming the main process somehow was terminated. There is a small race condition which might cause the error message to be printed even when MPlayer exits normally, but I think that's OK and better than never printing anything. Comments, testers? Reimar -------------- next part -------------- A non-text attachment was scrubbed... Name: cache_exit.diff Type: text/x-diff Size: 1178 bytes Desc: not available URL: From Reimar.Doeffinger at gmx.de Sun Nov 27 17:41:17 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 17:41:17 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127163203.GD21024@rep.kiev.ua> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> Message-ID: <20111127164117.GA3869@1und1.de> On Sun, Nov 27, 2011 at 06:32:03PM +0200, Andrej N. Gritsenko wrote: > Hello! > > >I also admit that MPlayer currently won't behave fully correctly with > >system clock changes anyway, however I think it at least will not hang > >completely (which maybe it would when pthread_cond_timedwait does not > >work correctly here - not sure, the main thread might just end up waking > >it up as soon as the user attempts a seek operation or something, not > >sure it always will). > > I have my application (which I mentioned earlier) running on the > system where time clock is very unstable (and it's not Linux BTW but > OpenIndiana variation of Solaris OS) and I have no problems with waking > up from the pthread_cond_timedwait in all cases (positive and negative > drifts) so don't worry, it always will. :) If you look at the glibc pthread implementation you see it won't. If you set the clock from 2100 to 2011 somewhen in-between the point where you calculate the timeout and when you call pthread_cond_timedwait it will wake up in 2100. Yes, you are right it will wake up _somewhen_. However 2100 might be a bit late for most of our users. From andrej at rep.kiev.ua Sun Nov 27 17:51:20 2011 From: andrej at rep.kiev.ua (Andrej N. Gritsenko) Date: Sun, 27 Nov 2011 18:51:20 +0200 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127164117.GA3869@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> Message-ID: <20111127165120.GE21024@rep.kiev.ua> Hello! On Sun, Nov 27, 2011, around 18:41, I've received: >If you look at the glibc pthread implementation you see it won't. >If you set the clock from 2100 to 2011 somewhen in-between the point >where you calculate the timeout and when you call pthread_cond_timedwait >it will wake up in 2100. >Yes, you are right it will wake up _somewhen_. However 2100 might be a bit >late for most of our users. Ah, I see the point. But that condwait used in cache filler, isn't it? So I think that main thread which using the cache can always signal the filler to wake up if it have used up the cache and that may happen even in case if time flow is ideal - if that is peak of stream usage. Am I right? With best wishes. Andriy. From tempn at twmi.rr.com Sun Nov 27 17:56:20 2011 From: tempn at twmi.rr.com (compn) Date: Sun, 27 Nov 2011 11:56:20 -0500 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127164117.GA3869@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> Message-ID: <20111127115620.82f82c2c.tempn@twmi.rr.com> On Sun, 27 Nov 2011 17:41:17 +0100, Reimar D?ffinger wrote: >On Sun, Nov 27, 2011 at 06:32:03PM +0200, Andrej N. Gritsenko wrote: >late for most of our users. some users want to only have one process. maybe it can be compile time option ? i dont care one way or the other, just trying not to bikeshed. -compn From Reimar.Doeffinger at gmx.de Sun Nov 27 18:10:51 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 18:10:51 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127115620.82f82c2c.tempn@twmi.rr.com> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <20111127115620.82f82c2c.tempn@twmi.rr.com> Message-ID: <20111127171051.GA4599@1und1.de> On Sun, Nov 27, 2011 at 11:56:20AM -0500, compn wrote: > On Sun, 27 Nov 2011 17:41:17 +0100, Reimar D?ffinger wrote: > >On Sun, Nov 27, 2011 at 06:32:03PM +0200, Andrej N. Gritsenko wrote: > >late for most of our users. > > some users want to only have one process. Why? Also that is already possible by only changing configure. It just will have worse performance than the current default implementation without this patch. > maybe it can be compile time option ? I have no objections at all to adding a option to control PTHREAD_CACHE directly, it should already work. Though currently IMO more speaks against than for making it the default. > i dont care one way or the other, just trying not to bikeshed. Maybe someone can come up with a better idea. Explicitly doing a wakeup when reaching the end of cache or similar should also reduce the issues. I just can't understand why they came up with such a broken API. Absolute timeouts have advantages, but if your implementation means that timeouts _never_ work reliably (at least not portably) it's quite irrelevant how many advantages they have in theory. From Dan.Oscarsson at tieto.com Sun Nov 27 18:13:44 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sun, 27 Nov 2011 18:13:44 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111127150326.GA2154@1und1.de> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> Message-ID: <1322414024.8465.13.camel@luna.malmo.kicore.net> s?n 2011-11-27 klockan 16:03 +0100 skrev Reimar D?ffinger: > What do you consider "slightly bad" when out of order doesn't qualify? The pts value is off by some milliseconds from correct value. Like some demuxers/decoders do, for example som combinations of .avi and mp3 audio where pts values goes + some time, and then - some time, around correct value. That I can correct or reduce so mplayer do not have to move display of frame forward/backward from correct time, all the time to compensate for drifting pts values. When pts values are out of order, they can jump around 100 ms or more. > If it can handle actually corrupted pts values I'd expect it should > handle reordering as well, at most hierarchical B might cause problems. It is difficult to know if it is a corrupt pts value or a change in the stream where a new sequence of pts value occur, so my code cannot correct if the pts values jump around with big value changes (and by big I mean about 70-100 ms or more. Dan From Reimar.Doeffinger at gmx.de Sun Nov 27 18:20:33 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 18:20:33 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322414024.8465.13.camel@luna.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> Message-ID: <20111127172033.GA4797@1und1.de> On Sun, Nov 27, 2011 at 06:13:44PM +0100, Dan Oscarsson wrote: > s?n 2011-11-27 klockan 16:03 +0100 skrev Reimar D?ffinger: > > What do you consider "slightly bad" when out of order doesn't qualify? > > The pts value is off by some milliseconds from correct value. Like some > demuxers/decoders do, for example som combinations of .avi and mp3 audio > where pts values goes + some time, and then - some time, around correct > value. That I can correct or reduce so mplayer do not have to move > display of frame forward/backward from correct time, all the time to > compensate for drifting pts values. > When pts values are out of order, they can jump around 100 ms or more. > > > If it can handle actually corrupted pts values I'd expect it should > > handle reordering as well, at most hierarchical B might cause problems. > > It is difficult to know if it is a corrupt pts value or a change in the > stream where a new sequence of pts value occur, so my code cannot > correct if the pts values jump around with big value changes (and by big > I mean about 70-100 ms or more. First, I do not see where the difference here is between big and small value changes, you don't know in either case whether the jump (differing from 1/fps) is an error or intended. The only difference I see is how much the user notices if you guess wrong. Also you can be fairly certain if either 1) you check the following PTS 2) you apply "large" changes with 1 frame delay (where I'd consider anything < 0.5/fps or > 1.5/fps as large) The point of -nocorrect-pts mode is to be based on FPS first of all, the fact that single incorrect pts matter so much seems to indicate that for some reason it no longer properly fulfills that point. I guess this is caused in part by the code removal but also in combination with a higher default -mc value. From Dan.Oscarsson at tieto.com Sun Nov 27 19:02:43 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Sun, 27 Nov 2011 19:02:43 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111127172033.GA4797@1und1.de> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> Message-ID: <1322416963.8465.24.camel@luna.malmo.kicore.net> s?n 2011-11-27 klockan 18:20 +0100 skrev Reimar D?ffinger: > The point of -nocorrect-pts mode is to be based on FPS first of all, > the fact that single incorrect pts matter so much seems to indicate > that for some reason it no longer properly fulfills that point. I have additional code that aligns video frame display with vsyncs. This allows me to play 24Hz movies on my 24HZ lcd tv without frame drops or judder. If the pts values are not in order, there will be missed vsyncs or fram drops to compensate giving bad viewing on tv. I would expect decode_video to return correct pts for each frame. If the intention of -nocorrect-pts mode is for decode_video to return wrong pts for a given frame - then that is not what I would have expected. To return a somewhat incorrect value - yes, but to return the pts of another frame - no. I assumed -nocorrect-pts mode is the old way to do it. But now when we mix old demuxers and new decoders mplayer have to change so that works too. I think demuxer lavf plus h264 works (gives pts in order), but demux_ts + h264 does not as decode_video do not do the reordering it should. I would not be surprised if there are other cases where reordering is not done - but needed to get the rights pts values for each frame. Dan From Reimar.Doeffinger at gmx.de Sun Nov 27 19:33:54 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 19:33:54 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322416963.8465.24.camel@luna.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> Message-ID: <20111127183354.GA23479@1und1.de> On Sun, Nov 27, 2011 at 07:02:43PM +0100, Dan Oscarsson wrote: > s?n 2011-11-27 klockan 18:20 +0100 skrev Reimar D?ffinger: > > > The point of -nocorrect-pts mode is to be based on FPS first of all, > > the fact that single incorrect pts matter so much seems to indicate > > that for some reason it no longer properly fulfills that point. > > I have additional code that aligns video frame display with vsyncs. This > allows me to play 24Hz movies on my 24HZ lcd tv without frame drops or > judder. If the pts values are not in order, there will be missed vsyncs > or fram drops to compensate giving bad viewing on tv. > > I would expect decode_video to return correct pts for each frame. If the > intention of -nocorrect-pts mode is for decode_video to return wrong pts > for a given frame - then that is not what I would have expected. To > return a somewhat incorrect value - yes, but to return the pts of > another frame - no. Uh, and what would be the difference between these? A "somewhat incorrect value" most often is "none at all". But it might also be one that is way of like, 0, 1, 2, 100000, 4, ... e.g. due to stream corruption. In general they might also be completely jumbled, e.g. due to pts/dts mixup and a few re-encodes after that (common when AVI was used as intermediate format). > I assumed -nocorrect-pts mode is the old way to do it. That too. But I don't consider that a good enough justification to redefine -nocorrect-pts to "only works with correct PTS values just like -correct-pts, except for some bugs that cancel out against some demuxer bugs". > I would not be surprised if there are other cases where > reordering is not done - but needed to get the rights pts values for > each frame. The point is not whether reordering is required to get the correct PTS but why the code should be allowed to break when the PTS are not correct. But I don't seem to convince anyone so I guess I'll try to find time to do it myself, probably trying to fix that code we removed instead of just removing it. From auerswal at unix-ag.uni-kl.de Sun Nov 27 20:06:27 2011 From: auerswal at unix-ag.uni-kl.de (Erik Auerswald) Date: Sun, 27 Nov 2011 20:06:27 +0100 Subject: [MPlayer-dev-eng] [PATCH] make cache process exit when parent died In-Reply-To: <20111127163733.GA3719@1und1.de> References: <20111127163733.GA3719@1und1.de> Message-ID: <4ED28A33.9000403@unix-ag.uni-kl.de> Hello Reimar, On 11/27/2011 05:37 PM, Reimar D?ffinger wrote: > a few people (including me) have been quite annoyed with MPlayer leaving its > cache process around if it crashes in a way the signal handler cannot > handle. One could do without the occasional mplayer cache process left behind. ;-) > Attached is a patch that makes the cache process check its parent > process ID, and if it changed it terminates itself, assuming the > main process somehow was terminated. The feature worked as advertised in my testing (sending SIGKILL to the main process). > There is a small race condition which might cause the error message to > be printed even when MPlayer exits normally, but I think that's OK > and better than never printing anything. Printing a message when something went wrong seems more important than never printing it when exiting normally. Regards, Erik From scowl at wballphotos.com Sun Nov 27 20:16:54 2011 From: scowl at wballphotos.com (Scott W. Larson) Date: Sun, 27 Nov 2011 11:16:54 -0800 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127164117.GA3869@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> Message-ID: <1322421414.15767.60.camel@scowl2> On Sun, 2011-11-27 at 17:41 +0100, Reimar D?ffinger wrote: > If you set the clock from 2100 to 2011 somewhen in-between the point > where you calculate the timeout and when you call pthread_cond_timedwait > it will wake up in 2100. Does this problem only happen when someone changes the clock? From Reimar.Doeffinger at gmx.de Sun Nov 27 20:52:29 2011 From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=) Date: Sun, 27 Nov 2011 20:52:29 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322421414.15767.60.camel@scowl2> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <1322421414.15767.60.camel@scowl2> Message-ID: On 27 Nov 2011, at 20:16, "Scott W. Larson" wrote: > On Sun, 2011-11-27 at 17:41 +0100, Reimar D?ffinger wrote: >> If you set the clock from 2100 to 2011 somewhen in-between the point >> where you calculate the timeout and when you call pthread_cond_timedwait >> it will wake up in 2100. > > Does this problem only happen when someone changes the clock? Yes. Adjustments by NTP or similar have of course the same effect if they cannot/are not done via temporary clock speed changes. No idea if you could come up with something crazy like an overflow in the time struct that would cause it too, but that's probably too far fetched to care about. From scowl at wballphotos.com Sun Nov 27 21:23:09 2011 From: scowl at wballphotos.com (Scott W. Larson) Date: Sun, 27 Nov 2011 12:23:09 -0800 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <1322421414.15767.60.camel@scowl2> Message-ID: <1322425389.15767.72.camel@scowl2> On Sun, 2011-11-27 at 20:52 +0100, Reimar D?ffinger wrote: > On 27 Nov 2011, at 20:16, "Scott W. Larson" wrote: > > On Sun, 2011-11-27 at 17:41 +0100, Reimar D?ffinger wrote: > >> If you set the clock from 2100 to 2011 somewhen in-between the point > >> where you calculate the timeout and when you call pthread_cond_timedwait > >> it will wake up in 2100. > > > > Does this problem only happen when someone changes the clock? > > Yes. Adjustments by NTP or similar have of course the same effect if they cannot/are not done via temporary clock speed changes. No idea if you could come up with something crazy like an overflow in the time struct that would cause it too, but that's probably too far fetched to care about. That's a relief. Changing the clock on our customers' systems will have far worse consequences than threads not timing out. Jobs won't be scheduled correctly. Parts won't be ordered. Accounting will probably not balance at the end of the month. Nightmare! A lot of real-word business applications demand a monotonous clock. That's why on our customers' systems changing the clock manually is as forbidden as opening up the computer while the power is on. From Reimar.Doeffinger at gmx.de Sun Nov 27 21:39:14 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Sun, 27 Nov 2011 21:39:14 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322425389.15767.72.camel@scowl2> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <1322421414.15767.60.camel@scowl2> <1322425389.15767.72.camel@scowl2> Message-ID: <20111127203914.GA2196@1und1.de> On Sun, Nov 27, 2011 at 12:23:09PM -0800, Scott W. Larson wrote: > On Sun, 2011-11-27 at 20:52 +0100, Reimar D?ffinger wrote: > > On 27 Nov 2011, at 20:16, "Scott W. Larson" wrote: > > > On Sun, 2011-11-27 at 17:41 +0100, Reimar D?ffinger wrote: > > >> If you set the clock from 2100 to 2011 somewhen in-between the point > > >> where you calculate the timeout and when you call pthread_cond_timedwait > > >> it will wake up in 2100. > > > > > > Does this problem only happen when someone changes the clock? > > > > Yes. Adjustments by NTP or similar have of course the same effect if they cannot/are not done via temporary clock speed changes. No idea if you could come up with something crazy like an overflow in the time struct that would cause it too, but that's probably too far fetched to care about. > > That's a relief. Changing the clock on our customers' systems will have > far worse consequences than threads not timing out. Jobs won't be > scheduled correctly. Parts won't be ordered. Accounting will probably > not balance at the end of the month. Nightmare! > > A lot of real-word business applications demand a monotonous clock. > That's why on our customers' systems changing the clock manually is as > forbidden as opening up the computer while the power is on. Yes, a lot of systems are coded like that (sometimes with good reason, sometimes not) which is why Linux introduced a method to make minor clock adjustments by speeding it up/slowing it down to avoid any skips that might cause issues. On desktop systems the most frequent issue is actually suspend/resume, which does not (or should not) cause issues in this case. I guess on Windows the automatic summer/winter time adjustment is also relevant. Still, I've tried to make sure that most code in MPlayer should handle it fine enough, and I don't like adding this kind of issue when the benefit isn't all that convincing. I still think there should be some better solution to this, or does everyone just accept that pthreads + timeouts = non-portable, fragile, ...? Unfortunately that is nothing I know much about, the closest I have in real experience is that the L4 microkernel supports both relative and absolute timeouts for that reason... From Dan.Oscarsson at tieto.com Mon Nov 28 10:07:14 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Mon, 28 Nov 2011 10:07:14 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <20111127203914.GA2196@1und1.de> References: <1322332860.7101.9.camel@luna.malmo.kicore.net> <20111127151200.GB2154@1und1.de> <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <1322421414.15767.60.camel@scowl2> <1322425389.15767.72.camel@scowl2> <20111127203914.GA2196@1und1.de> Message-ID: <1322471234.28776.17.camel@valinor.malmo.kicore.net> s?n 2011-11-27 klockan 21:39 +0100 skrev Reimar D?ffinger: > I still think there should be some better solution to this, or does > everyone just accept that pthreads + timeouts = non-portable, fragile, > ....? > Unfortunately that is nothing I know much about, the closest I have > in real experience is that the L4 microkernel supports both relative > and absolute timeouts for that reason... >From what I have seen most set clocks to use CLOCK_MONOTONIC if you want to be sure it works even when clock jumps. Though it would seldom matter for mplayer as there are enough other things that can make playing uneven. For example timing_sleep in mplayer.c may make wrong sleep time if clock jumps. Where do you read that pthread_cond_timedwait is full of race conditions? In my patch is is just there to be able to singla the thread to continue before sleep times out. Even if it sleeps a little to long it should not matter more then other delays in the system. I have timed mplayer for frame displaying and seen that sometimes the Linux scheduler delays the mplayer process (probably to handle i/o or other things) outside sleeps making all timing in mplayer fail. The code will work with just the usleep code, but will then not start processing a control request as quickly as now. And you could remove the timed wait and use queues of commands instead but then you need to move input into a thread instead of polling is as is done today. Dan From Dan.Oscarsson at tieto.com Mon Nov 28 10:36:10 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Mon, 28 Nov 2011 10:36:10 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111127183354.GA23479@1und1.de> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> <20111127183354.GA23479@1und1.de> Message-ID: <1322472970.28776.20.camel@valinor.malmo.kicore.net> s?n 2011-11-27 klockan 19:33 +0100 skrev Reimar D?ffinger: > The point is not whether reordering is required to get the correct > PTS but why the code should be allowed to break when the PTS are > not correct. > But I don't seem to convince anyone so I guess I'll try to find time > to do it myself, probably trying to fix that code we removed instead > of just removing it. >From my point there are two different cases: 1) pts are out of order in some cases 2) broken streams can result in bad pts values The code we removed could be used to fix 2). But 1) I do not see as broken stream data, instead it is a failure in demuxer/decoder to not provide correct pts with correct frame. Dan From Reimar.Doeffinger at gmx.de Mon Nov 28 19:23:01 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 28 Nov 2011 19:23:01 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322472970.28776.20.camel@valinor.malmo.kicore.net> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> <20111127183354.GA23479@1und1.de> <1322472970.28776.20.camel@valinor.malmo.kicore.net> Message-ID: <20111128182301.GA2955@1und1.de> On Mon, Nov 28, 2011 at 10:36:10AM +0100, Dan Oscarsson wrote: > s?n 2011-11-27 klockan 19:33 +0100 skrev Reimar D?ffinger: > > The point is not whether reordering is required to get the correct > > PTS but why the code should be allowed to break when the PTS are > > not correct. > > But I don't seem to convince anyone so I guess I'll try to find time > > to do it myself, probably trying to fix that code we removed instead > > of just removing it. > > From my point there are two different cases: > 1) pts are out of order in some cases > 2) broken streams can result in bad pts values > > The code we removed could be used to fix 2). > But 1) I do not see as broken stream data, instead it is a failure in > demuxer/decoder to not provide correct pts with correct frame. Any remotely reasonable fix for 2) would fix 1). The point of -nocorrect-pts is to handle 2). By fixing instead 1) you fix one specific symptom of the bug while leaving the real bug untouched. From Reimar.Doeffinger at gmx.de Mon Nov 28 19:45:50 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Mon, 28 Nov 2011 19:45:50 +0100 Subject: [MPlayer-dev-eng] threaded cache In-Reply-To: <1322471234.28776.17.camel@valinor.malmo.kicore.net> References: <20111127151520.GA2812@1und1.de> <20111127155631.GA3087@1und1.de> <20111127161101.GA3222@1und1.de> <20111127163203.GD21024@rep.kiev.ua> <20111127164117.GA3869@1und1.de> <1322421414.15767.60.camel@scowl2> <1322425389.15767.72.camel@scowl2> <20111127203914.GA2196@1und1.de> <1322471234.28776.17.camel@valinor.malmo.kicore.net> Message-ID: <20111128183919.GB2955@1und1.de> On Mon, Nov 28, 2011 at 10:07:14AM +0100, Dan Oscarsson wrote: > s?n 2011-11-27 klockan 21:39 +0100 skrev Reimar D?ffinger: > > > I still think there should be some better solution to this, or does > > everyone just accept that pthreads + timeouts = non-portable, fragile, > > ....? > > Unfortunately that is nothing I know much about, the closest I have > > in real experience is that the L4 microkernel supports both relative > > and absolute timeouts for that reason... > > From what I have seen most set clocks to use CLOCK_MONOTONIC if you want > to be sure it works even when clock jumps. Does it work on BSD? Does it work with MinGW pthreads? Solaris? > Though it would seldom matter > for mplayer as there are enough other things that can make playing > uneven. For example timing_sleep in mplayer.c may make wrong sleep time > if clock jumps. Sleeping until the year 2100 as in my example is not just "playing uneven". I admit it hardly happens for normal cases, but it is still brittle code. > Where do you read that pthread_cond_timedwait is full of race > conditions? To do a relative sleep the suggested method is to add the offset to the current time to get an absolute value. pthreads then subtracts the current time from that value again. This leaves a race conditions for when the time changes in-between these. Worse, it will also silently fall back from clock_gettime to gettimeofday (both when either the kernel does not support it or when glibc was compiled against older kernel headers) - no idea if and how that is possible to detect. > In my patch is is just there to be able to singla the thread > to continue before sleep times out. Even if it sleeps a little to long > it should not matter more then other delays in the system. What other delays can be anything from milliseconds to years? > The code will work with just the usleep code, but will then not start > processing a control request as quickly as now. And you could remove the > timed wait and use queues of commands instead but then you need to move > input into a thread instead of polling is as is done today. Huh? A thread for a thread for the main thread? I am not sure what you are thinking of. The much better solution I can see (for POSIX systems, I don't think it will be easy to get to work for Windows) would be using pipes and select (which at least does offer a proper relative timeout). You wouldn't even have to send the actual data through the pipe, just misusing it as a wakeup signal should work. I still don't particularly like it, it sounds like it would be not the cleanest code. From deron at pagestream.org Mon Nov 28 23:52:18 2011 From: deron at pagestream.org (Deron Kazmaier) Date: Mon, 28 Nov 2011 15:52:18 -0700 Subject: [MPlayer-dev-eng] Question about FPS Message-ID: <4ED410A2.30209@pagestream.org> I'm (slowly) tweaking the Blackmagic Decklink patch and I'm wondering if there is some kind of global frame timing in use when outputting wmv files (vc1 encoded in this case). Since the decklink requires a fixed fps based on the output/display mode selected, I use a simply accumulator to track when a frame should be output (possible skipped, or output twice etc). That doesn't work so hot when vo_fps is 1000 :-) If some other output device deals with that, it would be handy to know so i can look for reference. Otherwise, where would I find a list of available globals etc? Thanks! Deron From Dan.Oscarsson at tieto.com Tue Nov 29 08:14:30 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Tue, 29 Nov 2011 08:14:30 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111128182301.GA2955@1und1.de> References: <1321208675.6469.23.camel@luna.malmo.kicore.net> <1322134809.30233.89.camel@valinor.malmo.kicore.net> <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> <20111127183354.GA23479@1und1.de> <1322472970.28776.20.camel@valinor.malmo.kicore.net> <20111128182301.GA2955@1und1.de> Message-ID: <1322550870.28776.30.camel@valinor.malmo.kicore.net> m?n 2011-11-28 klockan 19:23 +0100 skrev Reimar D?ffinger: > > From my point there are two different cases: > > 1) pts are out of order in some cases > > 2) broken streams can result in bad pts values > > > > The code we removed could be used to fix 2). > > But 1) I do not see as broken stream data, instead it is a failure in > > demuxer/decoder to not provide correct pts with correct frame. > > Any remotely reasonable fix for 2) would fix 1). > The point of -nocorrect-pts is to handle 2). Why is correct_pts enabled for some demuxers and not for others? Even streams in those setting correct_pts to true can have bad streams. If -nocorrect-pts is for handling broken streams, it should either be off for all or on for all, as a default. Streams from demux_avi are not more broken then streams from demux_lavf. Dan From Reimar.Doeffinger at gmx.de Tue Nov 29 19:18:05 2011 From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=) Date: Tue, 29 Nov 2011 19:18:05 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <1322550870.28776.30.camel@valinor.malmo.kicore.net> References: <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> <20111127183354.GA23479@1und1.de> <1322472970.28776.20.camel@valinor.malmo.kicore.net> <20111128182301.GA2955@1und1.de> <1322550870.28776.30.camel@valinor.malmo.kicore.net> Message-ID: <20111129181805.GC2151@1und1.de> On Tue, Nov 29, 2011 at 08:14:30AM +0100, Dan Oscarsson wrote: > m?n 2011-11-28 klockan 19:23 +0100 skrev Reimar D?ffinger: > > > From my point there are two different cases: > > > 1) pts are out of order in some cases > > > 2) broken streams can result in bad pts values > > > > > > The code we removed could be used to fix 2). > > > But 1) I do not see as broken stream data, instead it is a failure in > > > demuxer/decoder to not provide correct pts with correct frame. > > > > Any remotely reasonable fix for 2) would fix 1). > > The point of -nocorrect-pts is to handle 2). > > Why is correct_pts enabled for some demuxers and not for others? Even > streams in those setting correct_pts to true can have bad streams. If > -nocorrect-pts is for handling broken streams, it should either be off > for all or on for all, as a default. Streams from demux_avi are not more > broken then streams from demux_lavf. Well, AVI files generally are more broken, and we do not use lavf for AVI. Also lavf does its own tricks to beat the pts values to make sense. In addition broken pts does not necessarily come from the streams, it can also come from a broken demuxer. And for example our RM demuxer IIRC misses some timestamp trickery so it will produce more broken ones. Lastly I also have been slightly redefining the _purpose_ of -nocorrect-pts based on what it used to handle better more for historical reasons. One point to also keep in mind is that -fps does not work with -correct-pts. I once hacked it to automatically switch the mode if -fps was specified but I think it somehow is broken again. From Dan.Oscarsson at tieto.com Wed Nov 30 10:28:06 2011 From: Dan.Oscarsson at tieto.com (Dan Oscarsson) Date: Wed, 30 Nov 2011 10:28:06 +0100 Subject: [MPlayer-dev-eng] [PATCH] reorder pts when needed In-Reply-To: <20111129181805.GC2151@1und1.de> References: <20111124182118.GA2210@1und1.de> <1322204826.30233.110.camel@valinor.malmo.kicore.net> <20111127150326.GA2154@1und1.de> <1322414024.8465.13.camel@luna.malmo.kicore.net> <20111127172033.GA4797@1und1.de> <1322416963.8465.24.camel@luna.malmo.kicore.net> <20111127183354.GA23479@1und1.de> <1322472970.28776.20.camel@valinor.malmo.kicore.net> <20111128182301.GA2955@1und1.de> <1322550870.28776.30.camel@valinor.malmo.kicore.net> <20111129181805.GC2151@1und1.de> Message-ID: <1322645286.9987.16.camel@valinor.malmo.kicore.net> tis 2011-11-29 klockan 19:18 +0100 skrev Reimar D?ffinger: > Lastly I also have been slightly redefining the _purpose_ of > -nocorrect-pts based on what it used to handle better more for > historical reasons. OK. In my addition code I have code to handle bad audio pts, not to fix broken video pts. During the last 3 years when I have been running my vsync matching code, audio pts have been the problem. Video pts have mostly been very good (except when I get the video pts out of order) so I have not felt any need to fix broken video pts as I have nearly never seen any. Dan From hlprasu at gmail.com Thu Nov 3 20:52:07 2011 From: hlprasu at gmail.com (Prasad H. L.) Date: Thu, 03 Nov 2011 19:52:07 -0000 Subject: [MPlayer-dev-eng] Add support for a new codec in Mencoder Message-ID: Hi, Could somebody please point towards the steps needed to be follows to add support for an encoder of new format in mencoder? I have the encoder for the format I am experimenting on. How do I add support for encoding with it in mencoder? Regards, Prasad From AnnieLiu at viatech.com.cn Fri Nov 25 13:02:39 2011 From: AnnieLiu at viatech.com.cn (AnnieLiu at viatech.com.cn) Date: Fri, 25 Nov 2011 12:02:39 -0000 Subject: [MPlayer-dev-eng] playing AC3 through HDMI abnormal sound issue Message-ID: Dear All I am Annie Liu from VIA Technology. I met an issue when play ac3 through HDMI by mplayer and need your help. I added the codec patch into alsa-driver to support our HDMI audio and I declared it as ?HDA_PCM_TYPE_HDMI?. It works fine when play wav file. Now, I met an issue when playing audio with AC3 format through HDMI. If I use VLC (A52->S/PDIF), the sound is Okay, and the audio format displayed on amplifier is ?D? (Dolby) as well. But I use mplayer with option ?-ac hwac3?, the audio sounds abnormal, although the amplifier display ?D? (Dolby). I tried mplayer with ?-ac a52?, but I found it decode AC3 to PCM. On the contrary, if I try ?-ac hwac3? on a ?digital codec? in our SB which declared as ?HDA_PCM_TYPE_SPDIF?, the sound is fine; but if I use VLC (A52->S/PDIF) no sound outputted. In VLC, I also found some a52 libraries: /usr/lib/vlc/plugins/codec/liba52_plugin.so /usr/lib/vlc/plugins/audio_filter/liba52tospdif_plugin.so I wonder how I can play ac3 by mplayer through HDMI in Dolby? I tried to declare my HDMI as ?HDA_PCM_TYPE_SPDIF? in codec patch, the abnormal issue happened as well. (Playing PCM is Okay). I wonder if the audio data encoded by hwac3 is compatible with HDMI. I searched a lot of topics related to playing ac3 through HDMI, and found someone said I should set AES0 as 0x02. I did it by iecset, it works. But when I play ac3 by mplayer, it always reports ?[AO-ALSA] alsa-lib: pcm.c:2208: (snd_pcm_open_noupdate) Unknown PCM hw:0,3,AES0=6?. I don?t know why it happens. Could anyone give me favor on it? Thanks a lot in advance! Thanks a lot. BR//Annie Annie Liu ????? ----------------------------------------------------------------- Software Team, 5th Floor, VIA Technologies (China) Inc., Ltd. VIA Building, Tsinghua Science Park building No.7 No.1 Zhongguancun East Road, Haidian District, Beijing, 100084 Tel: 86-10-59852288 ext. 3865 E-mail: annieliu at viatech.com.cn ----------------------------------------------------------------- ???????????1??7?? ??????? 5????? ??? 100084 -----------------------------------------------------------------