From: Roman S. <rvs@Sun.COM> - 2004-01-31 03:48:29
|
On Thu, Jan 29, 2004 at 09:55:59PM +0100, Andraz Tori wrote: > Na 1075402390, 2004-01-29 ob 19:53, je Roman Shaposhnick napisal(a): > > On Wed, Jan 28, 2004 at 11:09:40PM +0100, Andraz Tori wrote: > > > some time ago there were speed comparisons regarding ffmpeg's dv > > > decoding and libdv's one. > > > > > > if i remember correctly it was said that ffmpeg's is faster. > > > > > > I have tried to use it instead of libdv, but i actually see a speed > > > decrese (while on the other hand using it inside mplayer showed speed > > > improvements over libdv) > > > > > > so my question is if mplayer is using any trick or something? i am using > > > ffmpeg 0.4.8. > > > > No tricks, just CVS ;-) 0.4.8 is quite old. Plus there's this question > > of conversion speed/quality. > > CVS is faster? ... i went trough some ffmpegs dv.c cvs logs and seen > nothing that would indicate speed increse? Well since I put them there after 0.4.8 they should be there, shouldn't they? > Well libdv has a function > dv_decode_full_frame(dv_decoder_t *dv, const uint8_t *buffer, > dv_color_space_t color_space, uint8_t **pixels, int *pitches); > > where color_space can be: > typedef enum color_space_e { > e_dv_color_yuv, > e_dv_color_rgb, > e_dv_color_bgr0, > } dv_color_space_t; > > When e_dv_color_rgb is specified... libdv delivers RGB888 material... All it does it performs some additional color-space conversions. Once again, I don't know if for sure but it seems to me that mplayer's color-space coversion is not only faster it's better in terms of quality. > By my personal testing, this is faster than rendering to yuv42x and then > converting to RGB888. Maybe just due to inplace conversion and no need > for memory copying (so accessing memory twice is not needed), but it is > faster. Maybe just due to my color conversion rutines being slow. I > don't know... Exactly. And mplayer's ones being faster. > > > so about ffmpeg's dv decoding... is it possible to get yuv888 or rgb888 > > > directly from it? > > > > No. Neither it is possible to get it from libdv. There always *is* a > > coversion. > > yes, but inplace conversion is faster than doing it afterwards. No. > > > doing after-conversion from YUV422P/YUV420P etc... takes cpu time, which > > > i don't want to waste :) > > > > You're always doing it, no matter what. Now, ffmpeg is known to be slower > > than mplayer in that arena, so that could explain your speed degradation. > > Also, even though I don't have objective criteria, several people indicated > > that mplayer has much better colorspace-conversion code in terms of quality, > > so I'd be using it. > > Actually my current tests are with libquicktime color conversion > rutines, i'll try ffmpeg's now... > cca. 2h later : > ffmpeg rutines indeed work faster for converting to RGB888, > unfortunately ffmpeg does not provide converting to other formats i need > (YUV888, YUVA888, YUV161616 ... a lot of them) I never heard of such formats, so they must be aliases for some well-established names (of course they could be new ones, which means I can learn something today, but I doubt it ;-)). On the other hand, nobody has ever complained about lack of color spaces in ffmpeg(libavcodec). Please explain what do you mean by YUV888, YUVA888, YUV161616. > Now overall for decoding to rgb888 i got it from 30msec with libdv > decoding to rgb888, and 25msec with ffmpeg. Unfortunately for other > color modes, ffmpeg is slower... Others being what exactly ? > Also i have a problem with ffmpeg's decode which doesn't want to match > output line size with width (while width is correctly 720, linesize of > the picture is 752). It's internal size with padding, just don't pay attention to it. Use 720 pixels from there. > > > btw: i still didn't get the answer about libdv's support for directly > > > decoding to lower resolutions ? > > > > You did get my answer for ffmpeg. It's possible to support it. The question > > is -- how badly do you want it ;-) > > Well :)) > I have to draw thumbnails... small ones.. like 32x32 of dv material on > every track. if i have two tracks, and each is approx screen wide... > let's say 900 pixels, this comes to rendering 56 dv frames. every dv > frame needs around 30msec on my machine... this comes to almost a second > and a half ... and that while doing work is definitely costly :) even > cutting it in half would be a good thing. > > Otoh, i don't want it so bad, that i am willing to spent time learning > how to decode dv ... or how to optimize it for SSE2 or something. > But on the other hand i am willing to learn any api that would make a > speed inprovement or invest my time in helping getting it implemented... Again -- I can provide it via libavcodec. But let's talk about aforementioned details first. Thanks, Roman. |