147 replies to this topic

[malakudi]

It's the video decoder code and algorithm in the broadcom chips that is worse in my opinion. Input is digital, output is digital, but you are not forwarding the digital content to the tv set for decoding. STB chip decodes MPEG2 or H.264 data and converts it to HDMI signal, this convertion is worse in broadcom chipsets in my opinion. I see saturated reds for example in all broadcom chipsets, from old DM800 to latest BCM7413 found in VU+ Ultimo and ET9200. Colors on STi seems much more "correct". When I do tests for picture quality I usually use prerecorded material, 1080i, so scaling and deinterlacing is not in the equation.

Video DECODING is a lossless operation. If two decoders yield different bitstreams, then at least one of them is faulty. This clearly as opposed to video ENCODING. There is only one lossy step in the whole chain and that is at the encoder at the provider, after that, everything (including beaming up and reception) is lossless.

I believe this is incorrect, decoding is not a lossless operation, every decoder produces different output. The algorithm used allows specific optimizations to improve quality. At least this was the case for MPEG2 decoders, don't know if this has changed in H.264.

[malakudi]

OK, but this still cannot explain my below quote. I followed Ripper while he is porting the E2 to Azbox, and I remember that he told he used Sigma's API's for scaling/deinterlacing, if I'm not wrong. But the results are very different from the original firmware. Katherin users report exactly the same. So I think this problem is hardware independent and malakudi's explanation seems more logical to me. I think all developers preparing drivers to E2 use some common code (may be just for cheap and easy e2 compability ) which make the picture quality terrible.

About STi, the problem is the drivers used in enigma2 images. The code in them is derived from an unsupported project. STi chips are not well supported in the leaked code, STi doesn't support this in order to be improved and 3rd party developers don't have the skill or the knowledge of the chip specifications to improve the drivers.

I think something similar is happening for Azbox, drivers for E2 are not the same that are used in original software.

[buyukbang]

Mate, I'm using HDMI connection and be sure that this are really not that easy. There is a really very big picture quality difference between the referred boxes and e2 boxes. I accept the this should be related with e2 driver, but still don't think it's simly hardware related as I described in my above message.

Enigma2 doesn't do any video rendering whatsoever, so it's the chipset and the drivers that do all the work. If you are using a HDMI connection, there should be no difference at all, regardless of what you're using. If there is a difference in the digital stream from one receiver to another, that would indicate a plain bug, not a "quality" issue. Of course, assuming that the receivers aren't doing any postprocessing (e.g. scaling, deinterlacing) but you should let the TV do that anyway.

[buyukbang]

I think malakudi is right here, again. Decoders apply some assumptions to improve decoding performance, but they lost from the quality side.This differentiates picture quality among the decoders.

It's the video decoder code and algorithm in the broadcom chips that is worse in my opinion. Input is digital, output is digital, but you are not forwarding the digital content to the tv set for decoding. STB chip decodes MPEG2 or H.264 data and converts it to HDMI signal, this convertion is worse in broadcom chipsets in my opinion. I see saturated reds for example in all broadcom chipsets, from old DM800 to latest BCM7413 found in VU+ Ultimo and ET9200. Colors on STi seems much more "correct". When I do tests for picture quality I usually use prerecorded material, 1080i, so scaling and deinterlacing is not in the equation.

Video DECODING is a lossless operation. If two decoders yield different bitstreams, then at least one of them is faulty. This clearly as opposed to video ENCODING. There is only one lossy step in the whole chain and that is at the encoder at the provider, after that, everything (including beaming up and reception) is lossless.

I believe this is incorrect, decoding is not a lossless operation, every decoder produces different output. The algorithm used allows specific optimizations to improve quality. At least this was the case for MPEG2 decoders, don't know if this has changed in H.264.

Edited by buyukbang, 6 March 2012 - 17:33.

[Erik Slagter]

My point is that as far as I understand the Vu+ duo does not support 1080/50p output, only 1080/50i. Wouldnt this mean that the actual interlacing in the source material (576/50i) differs from the interlacing in the medium between STB and TV? In other words, when the STB does the process you described (576/50i->576/50p->1080/60p->1080/50i), the combing lines do not match the interleaved lines, thus making it more difficult for the TV to properly do the deinterlacing.

Not a single STB can output 1080p50. That is partly because no single service exists that broadcasts in 1080p50 (yet). If I want to see 1080p50, I need to use my own video camera and play it back on the PS3.

The issue you describe is actually exactly the reason why it is implemented this way. If you scale images without any processing, the interlacing will be "wrong". Every e.g. three adjacent lines will come from one original line, so you get even-even-even-odd-odd-odd-even-even-even etc. In practise it's even more complex, but this is the crux. If you apply a deinterlacer (on STB, TV or software) on this frame, it can't do any good, it won't work.

So that is why the frames are pseudo-deinterlaced first. I say "pseudo" because the process does get rid of combing effects like deinterlacing does, but because the frame rate is doubled, no motion ("temporal") information is lost at any stage. So before any scaling takes place, all interlacing issues have already been dealt with, the result is "true" 50p frames. These frames are scaled and then converted to 50i again. Works like a charm.

If you want to know how good it works, put your box in 25p mode for a while and note the difference when the frames are REALLY deinterlaced (50i -> 25p). There is no option to achieve that, you must telnet to the box and type:

cd /proc/stb/video
echo 1080p25 >| videomode
echo 1080p25 >| videomode_50hz

If you're done, simply restart the box and all will be reset to 1080i50 (or whatever).

[Erik Slagter]

I believe this is incorrect, decoding is not a lossless operation, every decoder produces different output. The algorithm used allows specific optimizations to improve quality. At least this was the case for MPEG2 decoders, don't know if this has changed in H.264.

Decoding is a very lightweight operation compared to encoding. Surely years back one could select shortcuts in decoding to be able to play e.g. HD on a light processor (skip b frames, decode to 1/2 or 1/4 resolution). There is no reason why a hardware implementation would need these shortcuts anyway. A complete, functioning decoder must produce the same bitstream as the reference decoder does.

Anyway this academic, because taking shortcuts in the decoding would not lead to "inferior" colours or "hazy" images, it would lead to blocky artifacts or stuttering image.

[Erik Slagter]

Mate, I'm using HDMI connection and be sure that this are really not that easy. There is a really very big picture quality difference between the referred boxes and e2 boxes. I accept the this should be related with e2 driver, but still don't think it's simly hardware related as I described in my above message.

Whatever you like to assume...

The only thing I object to is the word "quality" in this context. Quality is something objective that can be measured. What you are talking about is a difference in image, the one you like best, may or may not be the one that is actually closest to the original (= valid measurement of quality).

[malakudi]

Anyway this academic, because taking shortcuts in the decoding would not lead to "inferior" colours or "hazy" images, it would lead to blocky artifacts or stuttering image.

Then I don't know how to explain it, I definitely can see saturated red which affects flesh colors (all seem more red than natural) in all Broadcom boxes (and I've tried a lot since I review them for a Greek magazine). STi boxes seem to have more correct colors for me. Maybe the "neutral" color options in Broadcom are not so neutral? I haven't tried to play with video enchancement options to try fix what I am experiencing.

[Kers]

Not a single STB can output 1080p50. That is partly because no single service exists that broadcasts in 1080p50 (yet). If I want to see 1080p50, I need to use my own video camera and play it back on the PS3.

<clip>

Azbox does output 1080/50p/60p, maybe this has something to do with the perceived better SD picture quality.

[Gennar1]

I believe this is incorrect, decoding is not a lossless operation, every decoder produces different output. The algorithm used allows specific optimizations to improve quality. At least this was the case for MPEG2 decoders, don't know if this has changed in H.264.

You are right about MPEG2: this standard used a real DCT transform, which required some approximation to be computed on hardware without a FPU. The MPEG2 specification defined the maximum error tolerated to be compliant to the standard, but different implementations could produce different results.

With H.264 this is completely solved using only integer transforms that need no FPU calculation, so they can be computed with no approximation using only integer math. So every H.264 decoder produces exactly the same output. There is no room for shortcuts: if an H.264 decoder produced a different output than the reference decoder, it is not compliant to the specs so it cannot be called an "H.264" decoder.

[Calico]

There is no need all to use autoresolution, did I ever mention that? If you simply leave all settings to their defaults, it will bob+weave, scale, interleave as I described above.

When you say "there is no need all to use autoresolution", you mean that it has no effect with the deinterlace process ? or no effect if you use it to force the native resolution for both SD and HD channels ?
I thought that letting your AV receiver (if it's a good one) or your TV do the upscale would produce better results ? Am I wrong ?

Edited by Calico, 7 March 2012 - 07:54.

[Erik Slagter]

Then I don't know how to explain it, I definitely can see saturated red which affects flesh colors (all seem more red than natural) in all Broadcom boxes (and I've tried a lot since I review them for a Greek magazine). STi boxes seem to have more correct colors for me. Maybe the "neutral" color options in Broadcom are not so neutral? I haven't tried to play with video enchancement options to try fix what I am experiencing.

There probably exists a mapping at some stage to allow for video finetuning. Maybe the default mapping for broadcom SoC's is different than Sigma SoC's, that's perfectly possible. It can also be that enigma doesn't use the correct values for transparent mapping because the driver expect other values than on other platforms. This is for example the case for the "scaler sharpness"; the "neutral" value for that is on ET boxes other than on DMM boxes, due to driver implementation.

[Erik Slagter]

Azbox does output 1080/50p/60p, maybe this has something to do with the perceived better SD picture quality.

That may or may not be the case.

A quick search on specs for the Azbox does not give any hints it actually supports 1080p50, it just may be 1080p25 as far as I am concerned, and in that case it doesn't make it better than any other stb.

If it truly supports 1080p50 and your television set supports it as well (...) then there is the possibility to do the bob+weave step (no deinterlacing!) at the stb itself, indeed, without loss of data. But then, again, the stb has to have functionality for that. The end result would be similar to having the stb do the bob+weave step, but the implementation might differ in details.

[Erik Slagter]

When you say "there is no need all to use autoresolution", you mean that it has no effect with the deinterlace process ? or no effect if you use it to force the native resolution for both SD and HD channels ?

There is no need to use autoresolution to use the bob+weave process instead of deinterlacing, that is what I am saying, it's the default operation. Using autoresolution you can specify what process to use, no processing at all, bob+weave or deinterlacing (or "auto"). The option "deinterlace" should never be necessary.

I thought that letting your AV receiver (if it's a good one) or your TV do the upscale would produce better results ? Am I wrong ?

Some people prefer their TV scalar to the SoC's one, that's true. In that case you need to use autoresolution indeed. The original frames without any modification are sent to the television, so it needs to do both the scaling and "deinterlacing" (bob+weave, actually).

[Kers]

Azbox does output 1080/50p/60p, maybe this has something to do with the perceived better SD picture quality.

That may or may not be the case.

A quick search on specs for the Azbox does not give any hints it actually supports 1080p50, it just may be 1080p25 as far as I am concerned, and in that case it doesn't make it better than any other stb.

If it truly supports 1080p50 and your television set supports it as well (...) then there is the possibility to do the bob+weave step (no deinterlacing!) at the stb itself, indeed, without loss of data. But then, again, the stb has to have functionality for that. The end result would be similar to having the stb do the bob+weave step, but the implementation might differ in details.

Why so sceptical
Yes, it actually does support it as a and so does my TV which reports 50p refresh rate, the same as with PS3 in this mode. Azbox uses Sigma SMP8634 SoC, you can check its specs too.

[buyukbang]

BTW,

Now 3.x core is being used by Vu+ and CT. AFAIK 3.x should help to use more drivers. Isn't it possible to find a better driver for the embedded tuner or a usb dvb card with a better driver?
If not, may be our only option is openPLiPC for a better PQ?

[Erik Slagter]

Why so sceptical
Yes, it actually does support it as a and so does my TV which reports 50p refresh rate, the same as with PS3 in this mode. Azbox uses Sigma SMP8634 SoC, you can check its specs too.

I am sceptical because people tend to mix up 25p and 50p and manufacturers like to keep it that way

Anyway, this would not explain, by concept, the difference in picture perception.

My money is on the default mapping configuration.

[Erik Slagter]

Now 3.x core is being used by Vu+ and CT. AFAIK 3.x should help to use more drivers. Isn't it possible to find a better driver for the embedded tuner or a usb dvb card with a better driver?

The driver for the tuner has NO RELATION whatsoever to picture quality. Besides that, it's closed source and taken 1:1 from the manufacturer.

[buyukbang]

Sorry, I'm just trying to understand what you said : (As a summary) So you say that the only thing that effects picture quality on an e2 box is the hardware, not e2 itself, not tuner, not tuner driver, or not any part of software? Could you please correct me if wrong?

Now 3.x core is being used by Vu+ and CT. AFAIK 3.x should help to use more drivers. Isn't it possible to find a better driver for the embedded tuner or a usb dvb card with a better driver?

The driver for the tuner has NO RELATION whatsoever to picture quality. Besides that, it's closed source and taken 1:1 from the manufacturer.

[Erik Slagter]

Yep, you got it completely! The only thing that can make any difference (on HDMI/DVI output) is the scaler (for non-HD) and default mappings for "picture improvement", both are in hardware and controlled by non-open drivers.