Re: Re[2]: [Mplayer-dev-eng] plans ?
Hi, Felix Bьnemann! On 2001-07-10 23:40:27 you wrote:
What are the plans for the 0.18 release ? I thought it was to have it out as soon as possible. But at the moment it looks like more and more new features get in. An example is the ffmpeg divx codec. I like it very much but I would have waited for the next release.
NK> Yes, since Arpi have added libavcodec - release should be NK> delayed. I plan to add some optimizations to new stuff. NK> They should be tested. I guess that 0.18-pre.5 must NK> have enabled ffmepg-divx codec by default for better NK> testing. good idea, but imo we'll get loads of mails from users complaining bout mplayer being slower (cause they don't neccessarily get it's new codec).
Are you sure? I've found that new codec is much faster of M$. With M$ stuffs mplayer lose frames on my HW but with new codec I have 0 frames lost (according to mplayer indicators per 2000 frames). So this question is very disputable. Yes, there were reports that new stuffs is slower on P1-MMX but I already have done some optimization which speedups mplayer on 8-9% on my CPU. And there is possibility to speedup decoding more. But Gerald Lantau prefers "C" optimization against MMX. So I can wait while such optimization will be developed before I start to code MMX routines. Anyway this question should be discussed. Best regards! Nick (2001-07-11 13:30:22) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
What are the plans for the 0.18 release ? I thought it was to have it out as soon as possible. But at the moment it looks like more and more new features get in. An example is the ffmpeg divx codec. I like it very much but I would have waited for the next release.
NK> Yes, since Arpi have added libavcodec - release should be NK> delayed. I plan to add some optimizations to new stuff. NK> They should be tested. I guess that 0.18-pre.5 must NK> have enabled ffmepg-divx codec by default for better NK> testing. good idea, but imo we'll get loads of mails from users complaining bout mplayer being slower (cause they don't neccessarily get it's new codec).
NK> Are you sure? I've found that new codec is much faster of M$. NK> With M$ stuffs mplayer lose frames on my HW but with new codec NK> I have 0 frames lost (according to mplayer indicators per 2000 frames). NK> So this question is very disputable. NK> Yes, there were reports that new stuffs is slower on P1-MMX but I already NK> have done some optimization which speedups mplayer on 8-9% on my CPU. NK> And there is possibility to speedup decoding more. NK> But Gerald Lantau prefers "C" optimization against MMX. So I can wait NK> while such optimization will be developed before I start to code MMX routines. NK> Anyway this question should be discussed. hmm yesterday I checked and ffdivx was indeed faster, but I'll have to check that with more highres/higher bps files first. And you should also care that ffdivx might get LGPL according to Gerald's mail forwarded by Arpi, so it's not even for sure we'll keep it (or get his latest code, as current code is GPL we can go on with that code after
Hello Nick, Wednesday, July 11, 2001, 3:40:19 PM, you wrote: NK> Hi, Felix Bьnemann! NK> On 2001-07-10 23:40:27 you wrote: license is changed...) Btw. codec not dropping frame is on your system more likely to be due to YV12 format, as your video card is quite slow and not your CPU, so decreased bandwidth for the graphics card makes up less dropped frames (or am I wrong?). NK> Best regards! Nick (2001-07-11 13:30:22) -- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
hmm yesterday I checked and ffdivx was indeed faster, but I'll have to check that with more highres/higher bps files first. And you should i'm interested in the results.
also care that ffdivx might get LGPL according to Gerald's mail forwarded by Arpi, so it's not even for sure we'll keep it (or get his latest code, as current code is GPL we can go on with that code after license is changed...) yes, it will be surely change, to LGPL or something else special. btw currently it's GPL, so we can fork, and continue developing/optimizing current GPL version, independent from possible new LPGL/??? ffmpeg.
btw projectmayo guys will release their closed-source divx and opendivx codec for linux, in library form. i've got a beta, but can't test it now :( (yes, they have divx 3.11 compatible codec too, but it was secret until today) btw i still prefer ffmpeg stuff, than projectmayos closedsource stuff.
Btw. codec not dropping frame is on your system more likely to be due to YV12 format, as your video card is quite slow and not your CPU, so agree.
decreased bandwidth for the graphics card makes up less dropped frames (or am I wrong?). no. you're right.
YV12 will help for most users with bandwith problems (amd users). it transfers 12 bit for each pixels, instad of 16 bits/pixel of YUY2. and teh codec don't have to convert YV12->YUY2 internally. A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
On Wednesday, 11. July 2001 20:29, you wrote:
Hi,
hmm yesterday I checked and ffdivx was indeed faster, but I'll have to check that with more highres/higher bps files first. And you should
i'm interested in the results.
here they are, tested with Coyote Ugly clip I've did from the movie and it's available on mphq under MPlayer/incoming/ffmpeg/ if I remember correct: first divxds: BENCHMARKs: V: 20.790s VO: 4.539s A: 0.000s Sys: 10.789s = 36.117s BENCHMARK%: V: 57.5613% VO: 12.5676% A: 0.0000% Sys: 29.8710% = 100.0000% ffdivx: BENCHMARKs: V: 27.039s VO: 3.551s A: 0.000s Sys: 10.489s = 41.079s BENCHMARK%: V: 65.8225% VO: 8.6447% A: 0.0000% Sys: 25.5328% = 100.0000% so ffdivx still suffers here. Btw. this clip has black bars above and below image encoded with the video, which needs quite some decoding time and video bandwidth, how about adding some sort of detection (or manual specification) to ffmpeg decoder to decode only part of the image? I don't know much about mpeg4, but it should work on block boundary, shouldn't it? If that works one could also crop image from widescreen to 4:3 and stuff. [snip]
A'rpi / Astral & ESP-team
-- mailto:arpi@thot.banki.hu http://esp-team.scene.hu
-- Best Regards, Felix _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
yes, it will be surely change, to LGPL or something else special.
why?
Btw. codec not dropping frame is on your system more likely to be due to YV12 format, as your video card is quite slow and not your CPU, so agree. decreased bandwidth for the graphics card makes up less dropped frames (or am I wrong?). no. you're right. YV12 will help for most users with bandwith problems (amd users). it transfers 12 bit for each pixels, instad of 16 bits/pixel of YUY2. and teh codec don't have to convert YV12->YUY2 internally.
YV12 will help for most users, but not for me :( See my test results: MPlayer 0.17cvs-010711-15:14 VIDEO: [DIV3] 384x288 24bpp 29.97 fps 996.1 kbps (121.6 kbyte/s) [V] filefmt:3 fourcc:0x33564944 size:384x288 fps:29.97 ftime:=0.0334 Trying to force video codec driver family 4 ... Detected video codec: [divxds] drv:4 (DivX ;-) (MS MPEG-4 v3)) vo: X11 running at 800x600 depth: 32 (":0.0" => local display) VO: [dga] 384x288 => 384x288 BGR 32-bit BENCHMARKs: V: 13.522s VO: 17.148s A: 0.000s Sys: 0.428s = 31.099s Trying to force video codec driver family 2 ... Detected video codec: [divx] drv:2 (DivX ;-) (MS MPEG-4 v3)) BENCHMARKs: V: 13.268s VO: 17.152s A: 0.000s Sys: 0.388s = 30.808s Trying to force video codec driver family 5 ... Detected video codec: [ffdivx] drv:5 (FFmpeg DivX ;-) (MS MPEG-4 v3)) VO: [dga] 384x288 => 384x288 Planar YV12 BENCHMARKs: V: 15.668s VO: 4.025s A: 0.000s Sys: 0.310s = 20.003s ^^^^^^ This is the only case, when ff wins. ^^^^^^^ still not acceptable for 16.6 seconds of a movie if still in 32 bpp but using -bpp 24 Trying to force video codec driver family 4 ... Detected video codec: [divxds] drv:4 (DivX ;-) (MS MPEG-4 v3)) vo: X11 running at 800x600 depth: 32 (":0.0" => local display) VO: [dga] 384x288 => 384x288 BGR 24-bit BENCHMARKs: V: 12.554s VO: 3.886s A: 0.000s Sys: 0.374s = 16.813s Trying to force video codec driver family 2 ... Detected video codec: [divx] drv:2 (DivX ;-) (MS MPEG-4 v3)) BENCHMARKs: V: 12.524s VO: 3.853s A: 0.000s Sys: 0.380s = 16.757s Trying to force video codec driver family 5 ... Detected video codec: [ffdivx] drv:5 (FFmpeg DivX ;-) (MS MPEG-4 v3)) VO: [dga] 384x288 => 384x288 Planar YV12 BENCHMARKs: V: 15.739s VO: 4.034s A: 0.000s Sys: 0.302s = 20.075s ^^^^^^ now it's slower (yes, not too much difference) (and same as above ff) things get worse in real 24 bpp well, my time is up and I saw, that jkeil commited some optimization to libavcodec, so I'll recompile mplayer, rerun my tests and after weekend I'll publish them :) Bye Tibcu and have a nice weekend at Balaton, Arpi! :) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Balazs, Friday, July 13, 2001, 7:03:57 PM, you wrote:
yes, it will be surely change, to LGPL or something else special.
BT> why?
Btw. codec not dropping frame is on your system more likely to be due to YV12 format, as your video card is quite slow and not your CPU, so agree. decreased bandwidth for the graphics card makes up less dropped frames (or am I wrong?). no. you're right. YV12 will help for most users with bandwith problems (amd users). it transfers 12 bit for each pixels, instad of 16 bits/pixel of YUY2. and teh codec don't have to convert YV12->YUY2 internally.
BT> YV12 will help for most users, but not for me :( BT> See my test results: [results not of much relevance] arg you don't quite get it, YV12 memory bandwidth of course only is lower when you directly diplay in YV12, this means with XVideo, all other stuff gets direct bgr from codec (divxds/divx) or has to do YV12 to BGR conversion (ffdivx), so of xourse you won't gain performance through that then (-bpp 15 would be lowest memory badwidth then and when using ffdivx -bpp 16 should be fastest, cause it has MMX conversion, whereas 15bpp hasn't). BT> well, my time is up and I saw, that jkeil commited some optimization to BT> libavcodec, so I'll recompile mplayer, rerun my tests and after weekend BT> I'll publish them :) BT> Bye BT> Tibcu BT> and have a nice weekend at Balaton, Arpi! :) yes, he truly deserves. -- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
BT> YV12 will help for most users, but not for me :( arg you don't quite get it, YV12 memory bandwidth of course only is
yes, there's nothing in -v output, from wich it should turn out vo_debug: query(Planar YV12) returned 0x7 vo_debug1: out_fmt=Planar YV12 o_debug2: out_fmt=Planar YV12 VO: [dga] 384x288 => 384x288 Planar YV12 VO: Description: DGA ( Direct Graphic Access V1.0+XF86VidModeExtension ) video_out->init(384x288->384x288,flags=0,'MPlayer',0x32315659) vo_debug3: out_fmt=Planar YV12 vo_dga: Using mplayer depth 32 for YV12
lower when you directly diplay in YV12, this means with XVideo, all
I've got no Xv :( And I didn't know it.
other stuff gets direct bgr from codec (divxds/divx) or has to do YV12 to BGR conversion (ffdivx), so of xourse you won't gain performance
yes, dshow codec sais: VO: [dga] 384x288 => 384x288 BGR 32-bit here is BGR, but not when I use ffdivx, so???
through that then (-bpp 15 would be lowest memory badwidth then and
yes, I've done tests for all bpps
when using ffdivx -bpp 16 should be fastest, cause it has MMX conversion, whereas 15bpp hasn't).
Yes, I noticed.
BT> and have a nice weekend at Balaton, Arpi! :) yes, he truly deserves.
YES! and all of you, who are working on this great project Tibcu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Tibor (<-- sorry forgot to change last time), Monday, July 16, 2001, 7:07:56 PM, you wrote:
BT> YV12 will help for most users, but not for me :( arg you don't quite get it, YV12 memory bandwidth of course only is
yes, there's nothing in -v output, from wich it should turn out
vo_debug: query(Planar YV12) returned 0x7 vo_debug1: out_fmt=Planar YV12 o_debug2: out_fmt=Planar YV12 VO: [dga] 384x288 =>> 384x288 Planar YV12 VO: Description: DGA ( Direct Graphic Access V1.0+XF86VidModeExtension ) video_out->>init(384x288->384x288,flags=0,'MPlayer',0x32315659) vo_debug3: out_fmt=Planar YV12 vo_dga: Using mplayer depth 32 for YV12
lower when you directly diplay in YV12, this means with XVideo, all
I've got no Xv :( And I didn't know it.
other stuff gets direct bgr from codec (divxds/divx) or has to do YV12 to BGR conversion (ffdivx), so of xourse you won't gain performance
yes, dshow codec sais: VO: [dga] 384x288 =>> 384x288 BGR 32-bit here is BGR, but not when I use ffdivx, so??? yea, cause divx codec can deliver BGR (in-codec conversion from YUV), but libavcodec currently only does YV12 so mplayer does the YUV->RGB conversion (actually I saw in ffmpeg changelog that there was a patch to get bgr 24 output from libavcodec, but I don't think mplayer is ready for it).
through that then (-bpp 15 would be lowest memory badwidth then and
yes, I've done tests for all bpps
when using ffdivx -bpp 16 should be fastest, cause it has MMX conversion, whereas 15bpp hasn't).
Yes, I noticed.
BT> and have a nice weekend at Balaton, Arpi! :) yes, he truly deserves.
YES! and all of you, who are working on this great project
Tibcu
-- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Tibor (<-- sorry forgot to change last time),
thx :)
lower when you directly diplay in YV12, this means with XVideo, all
from vo_dga.c : if( format==IMGFMT_YV12 ){ yuv2rgb_init(... does that mean, that if image format is YV12, like the one ffdivx produces, vo_dga.c uses an YUV to RGB converter, in order to be able to display the image? then I have no question :)
other stuff gets direct bgr from codec (divxds/divx) or has to do YV12 to BGR conversion (ffdivx), so of xourse you won't gain performance
:-(( (szegény embert az ág is húzza)
yea, cause divx codec can deliver BGR (in-codec conversion from YUV), but libavcodec currently only does YV12 so mplayer does the YUV->RGB ^^^ and who does YV12-YUV?? :)
Well, so you say, when mplayer prints out Using MMX for colorspace transform, it means, it will use software conversion, because YV12 couldn't directly used on my hardware?
conversion (actually I saw in ffmpeg changelog that there was a patch to get bgr 24 output from libavcodec, but I don't think mplayer is ready for it).
Tibcu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
lower when you directly diplay in YV12, this means with XVideo, all
from vo_dga.c :
if( format==IMGFMT_YV12 ){ yuv2rgb_init(...
does that mean, that if image format is YV12, like the one ffdivx produces, vo_dga.c uses an YUV to RGB converter, in order to be able to display the image? yes.
then I have no question :) great! :)
other stuff gets direct bgr from codec (divxds/divx) or has to do YV12 to BGR conversion (ffdivx), so of xourse you won't gain performance
:-(( (szegény embert az ág is húzza) english please...
yea, cause divx codec can deliver BGR (in-codec conversion from YUV), but libavcodec currently only does YV12 so mplayer does the YUV->RGB ^^^ and who does YV12-YUV?? :) YV12 is the fourcc of the 12-bit planar YUV format.
Well, so you say, when mplayer prints out Using MMX for colorspace transform, it means, it will use software conversion, because YV12 couldn't directly used on my hardware? yes.
conversion (actually I saw in ffmpeg changelog that there was a patch to get bgr 24 output from libavcodec, but I don't think mplayer is ready for it). it has no use for us. we already have YV12->BGR/RGB converters. and all mpegs use YV12, so you can't get BGR without conversion. ^^^ (yes, in theory/standard exists 4:2:2 planar 16-bit YUV too, but i've never seen such file, nor decoder supporting this except DVDview)
A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
:-(( (szegény embert az ág is húzza) english please... "even the branch pulls the poor man" ;))))
thanks, but I don't think, it's the correct Englishism :) Ticbu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
yes, it will be surely change, to LGPL or something else special.
why? because he develops this stuff for his company... and they want to sell this stuff for money, without releaseing the
Hi, source of the whole product... (LGPL allows this, GPL does not)
Btw. codec not dropping frame is on your system more likely to be due to YV12 format, as your video card is quite slow and not your CPU, so agree. decreased bandwidth for the graphics card makes up less dropped frames (or am I wrong?). no. you're right. YV12 will help for most users with bandwith problems (amd users). it transfers 12 bit for each pixels, instad of 16 bits/pixel of YUY2. and teh codec don't have to convert YV12->YUY2 internally.
YV12 will help for most users, but not for me :( your 486 is quite slooow :)
if still in 32 bpp but using -bpp 24 it's a fallback, then it uses very slooow 24->32 conversion... not recommended.
and have a nice weekend at Balaton, Arpi! :)
only 16 and 32 bpp are MMX accelerated for YV12. thanx :) A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
because he develops this stuff for his company...
but then why was it GPL till now?
and they want to sell this stuff for money, without releaseing the source of the whole product... (LGPL allows this, GPL does not)
YV12 will help for most users, but not for me :( your 486 is quite slooow :)
:)) and it has no MMX but my tests were made on my P200MMX!
if still in 32 bpp but using -bpp 24 it's a fallback, then it uses very slooow 24->32 conversion... not recommended.
YOU ARE NOT PAYING ATTENTION TO THE NUMBERS for me, -bpp 24 in 32bpp X with dga WAS a lot FASTER than -bpp 32
only 16 and 32 bpp are MMX accelerated for YV12.
but the above is for dshow and vfw codecs!!! Ticbu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Balazs, Monday, July 16, 2001, 7:10:47 PM, you wrote:
because he develops this stuff for his company...
but then why was it GPL till now?
and they want to sell this stuff for money, without releaseing the source of the whole product... (LGPL allows this, GPL does not)
YV12 will help for most users, but not for me :( your 486 is quite slooow :)
:)) and it has no MMX
but my tests were made on my P200MMX!
if still in 32 bpp but using -bpp 24 it's a fallback, then it uses very slooow 24->32 conversion... not recommended. 32bpp only has additional alpha bits soconversion 24->32 should be quite fast, IMHO. YOU ARE NOT PAYING ATTENTION TO THE NUMBERS
for me, -bpp 24 in 32bpp X with dga WAS a lot FASTER than -bpp 32
only 16 and 32 bpp are MMX accelerated for YV12.
but the above is for dshow and vfw codecs!!!
btw. libavcodec got faster now I have 42sec ffmpeg to 39sec with divxds and 38sec with high bitrate divx, so we're getting nearer, to were we wanna be (tested with Coyote Ugly sample clip from mphq MPlayer/incoming/ffmpeg on PIII 850, 128MB, S3 Savage MX with vo xv).
Ticbu
-- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Balazs, Monday, July 16, 2001, 7:10:47 PM, you wrote:
because he develops this stuff for his company...
but then why was it GPL till now?
and they want to sell this stuff for money, without releaseing the source of the whole product... (LGPL allows this, GPL does not) [spamming the ml]
But imo it's possible to ship software under different licenses, so there could be a GPL and LGPL version for example (I've seen progs with (BSD?) Artisitc license and other License for example).
Ticbu
-- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
because he develops this stuff for his company...
but then why was it GPL till now?
and they want to sell this stuff for money, without releaseing the source of the whole product... (LGPL allows this, GPL does not) [spamming the ml]
But imo it's possible to ship software under different licenses, so there could be a GPL and LGPL version for example (I've seen progs with (BSD?) Artisitc license and other License for example).
yes, this is what we are doing now... the GPL version is hosted at MPlayer CVS, and the other version with special license (not decided yet) at Gerard's harddisk (he doesn't uses CVS). we are porting changes between the 2 versions... it means extra work just for license issues. :( A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
participants (7)
-
Arpi -
Balazs Tibor -
Felix Buenemann -
Felix Bünemann
-
Felix Bьnemann
-
Gabucino -
Nick Kurshev