• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 30
XBMP has better video quality than XBMC?
#16
please post some good comparative screenshots of xbmc vs. xbmp that clearly show the degradation in quality, or post a clip of a video that clearly shows these issues along with the versions of xbmp and xbmc that show the issues, including your screen setup (pal/ntsc/hdtv etc., postprocessing options, soften options etc. etc.)

thanks.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#17
how can i take a screenshot with xbmp?

i have a pal xbox (pal60 or ntsc modes don't change the video quality), all postprocessing options off (with options on the quality is even worst), soften disabled. as i said before all xbmc versions since the beginning had worst video quality than xbmp with all the videos i've tried. i know this is a very vague bug report and very hard to track (i should have taken a screenshot when xbmc worked fine Sad )

many thanks
#18
you can't take a screenshot of video playing with xbmp as it uses overlays.

please identify a video in which it is easy to see the difference in quality, and then post which version (and options) of xbmp to compare the latest xbmc with.

that will allow the devs to view the video for ourselves and compare.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#19
Star 
i don't know if i just don't care or if my tv is too small or whatsoever... but my video looks just perfectly fine under xmbc!

anyways... good luck
#20
here is a short video. it's the scene from the screenshots i made some days ago. look at the background, there are ugly artefacts.

http://packleds.host.sk/xbmc-test.avi

test settings: see my earlier posts. btw filtering was set to linear and anisotropic

cu
#21
played around with xbmp and xbmc today and i can say this, xbmc has video better quality. however, xbmp seems to do some sort of 16-bit dithering that will apear to have better quality on tvs with low dynamic range. xbmc on the other had apears to perform everything in a 32-bit color space but tvs that can handle the color appear to band (viewed on a 32" sony wega with componet inputs). the ouput (screenshot) of xbmc however looks almost identical to the source when viewed in virtualdub.

edit: never mind there is banding the the virtual dub video also.
#22
i've uploaded some files to the xbmc upload area:

a600_video.avi (video sample - sound removed)
a600_screeshots.zip (3 screenshots, the zone that shows the very noticiable artifacts is marked with a red circle)
a600_xbmc_settings.zip (xmbc config files - settings.xml - calibration.xml)

with xbmp the artifacts are almost inappreciable (post processing #1, #2 and soften enabled)

xbmc - 04/24 build
xbmp - 09/24 build

i have a pal xbox 1.1 and use an rgb monitor plugged with the scart cable. i've tried all possible filter/pal/ntsc combinations with xbmc but never got good results but i know that xmbc has better video quality because i've seen it with my eyes as i said in my previous posts.


btw, can someone post the xmbc config files - settings.xml - calibration.xml (e:\tdata\0face008)? maybe that helps me.

many thanks.
#23
did a little comparison between xbmc and ffdshow (http://www.free-codecs.com based on ffmpeg).

http://www.telusplanet.net/public/abrooks/comp/

as you can see in it's current form xbmc is pretty accurate for what should be expected from an mplayer based player. however it might be good to add the ability to have no filter (what i suspect causes the differences and causes some unwanted banding, even a color shift it seems) and a constant resolution (in this case 640 by 256 which is hard to achieve in xbmc as it is, pixel ratio of 1.000 left x coord=41 right x coord = 40 y= most anything).

i can't really coment on what made xbmp look better, i was never able to be screenshots to work with video. but i do think there was either some 16-bit dithering or post-processing apart from the players options.
#24
some or all of the differences there are probably caused by the hardware colour space conversion. the pixel shader only maintains 8-bits of accuracy which means there may be some single bit errors in pixel values.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#25
right some thoughts on colour conversion:

first off you should be aware of how yuv colour space works, i'll briefly cover this.
in rgb a pixel is stored as red, green and blue compontents, each from 0-255 in value. this makes filtering when scaling and such nice and easy.
yuv is slightly different - the y component is luminance and has a valid range of 0-1, it is mapped to the range 16-235 when encoded in a byte on pcs. u and v are red and blue chrominance and have a range of -1 to 1, they are mapped to the range 16-239 when encoded in bytes on pcs.
the hardware converter i wrote handles conversion from these ranges and conversion to rgb fine. the issue arises when resizing is required. because the ranges are not based on 0, and because the "zero-point" of the chrominace gamut is at 128 filtering on yuv colours can lead to some fairly serious artifacts. it's more pronounced with the quincunx and gaussian as they tend to dim the image slightly. this can lead to values falling outside the valid range, if that happens they are clamped to the end point - resulting in banding.
to add to these problems is the issue that yv12 has only half the uv resolution of the y resolution. this means that the u and v require either doubling up or scaling with a filter to match the y resolution.

so anyway this leads me to a number of solutions:

1. do the colour space conversion without any resizing (uv doubled up) then to render the resulting rgb image to the screen with filtered scaling. this should work quite well, but has some memory overhead for storing the rgb converted images.
2. switch the xbox output hardware to yuv and write a scaling pixel shader that runs in yuv. i'm not sure how feasible this is, but it could potentially provide the best results.
3. basically do what xbmp and earlier versions of xbmc did and do a yv12->yuy2 conversion then render the yuy2 images using hardware overlays. this should also give good results, however it will disable screenshots. there's also the memory overhead of storing the yuy2 images in addition to the yv12 images. the yv12->yuy2 could be written using a pixel shader to avoid the earlier issues with software conversion.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#26
2. isn't feasible as i can't pull in sufficient colour data.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#27
methods 1 or 3 will use basically the same amount of memory right? (basically need to store an extra texture the size of the video).

i'm wondering how well the different hardware filters apply to the different formats (rgb vs yuy2). does the xbox apply the standard filters to hardware overlays, or does it use a fixed filter (linear??)

either or would be fine imo, although because of the extra memory overhead, it may pay to keep the current rendering method available for those wishing to play large videos at high resolutions.

pity option 2 is not feasible Sad if you have a bit of spare time, could you email me and elaborate on the infeasibility?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#28
memory overhead: it's twice as large with rgb as yuy2 as rgb is a 32 bit format (8 bits of each and 8 bits wasted), whereas yuy2 is 16 bits (8 bits of y per pixel and 4 of u and v). the overhead is an extra buffer or two the size of the source resolution. i'm not certain it would be an issue even at high res - we generally seem to run out of cpu power well before memory.

rgb filtering is done through the standard texture filters. that basically means you get the choice of linear, quincunx or gaussian cubic.
yuv filtering seems to go through a specific hardware yuv filter which avoids the filtering issues we get when using the yv12->rgb converter. i'm not sure extactly what their sampling algorithm is.

in terms of compatibility with existing setup, method 1 definitely has the edge. also yv12->rgb is actually easier than yv12->yuy2. Image
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#29
dont know about the technical stuff
but using my eyes i can confirm that xbmp video quality is better than xbmc
that why i still prefer to play old xvid with xbmp
#30
new video output code is in, hopefully you should see a quality improvement.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 30

Logout Mark Read Team Forum Stats Members Help
XBMP has better video quality than XBMC?0
This forum uses Lukasz Tkacz MyBB addons.