In the UK on Sky HD movie channels, noticeable microblocking on dark scenes appears frequently. Microblocking also occurs on Sky Sports HD as well as Sky One HD but is much less prevelant on BBC HD which uses very high bit rates. In the US which uses MPEG2 instead of MPEG4, microblocking on HD movie channels seldom occurs at very low average bit rates of 9.5 mb/s to 12 mb/s. On Sky HD, the bit rates should be fairly high since only 3 HD channels are on one 46 mb/s transponder.
Since MPEG4 hardware encoders and STAT-MUXES are very new technology, it is assumed that the problems are due to design bugs but no one is quite sure.
Has anyone watched HD on other European HD channels (especially German Premiere HD movies since that transponder is configured similar to Sky HD) and experienced similar problems?
Viser resultater 1 til 17 av 17
Tråd: HD Microblocking
09-09-2006, 21:44 #1UregistrertGuest
09-10-2006, 13:13 #2
Sound to me like a hardware decoder/encoder problem. One of the main advantages of mpeg-4 is that a low bitrate stream should results in a blurred picture without blocking, becouse of deblocking filters.
09-10-2006, 21:38 #3UregistrertGuestOpprinnelig postet av no12
09-10-2006, 21:57 #4
One problem with efficient compression is that it could be more vulnerable to transmission errors.I dont know what profiles and features are used for DVB-S2 transmission, but I recon it is well suited to the channel?
09-10-2006, 23:09 #5UregistrertGuestOpprinnelig postet av knutinh
Some people refer to microblocking as pixelization.
09-10-2006, 23:19 #6
microblocking is a new term to me. However, "blocking" is used by someone to describe the effect observed when there is to few bits (high Qp) to match the individual DCT blocks together, getting very visible discontinuities. Is this what you mean?
Macroblocks is the 16x16 pixel set of (typically) 4 luma blocks and 1 block of each croma difference. Is this what you mean?
09-10-2006, 23:57 #7UregistrertGuest
Microblocking is the primary term used in the US to describe the condition. Bocking, pixelization, and other terms are also used. Typically whether MPEG2 or MPEG4, the format method used is 4:2:0 for final transmission basically meaning that 4 adjoing pixels all have the same chroma. One of the optimization features of an encoder when bit rate starved is to combine more adjoining pixels with similar chroma.
In my understanding STAT-MUXES (which are primarily rate shaping equipment) will usually first eliminates null packets and then perform requantization and possibly transrating which could cause similar visual problems if overdriven. I'm not exactly sure which technologies are currently being used with STAT-MUXES.
So blocking problems can either be caused by the encoder or the STAT-MUX.
Combining chromas of adjoining pixels reduces the amount of entries required required in the stream.
09-11-2006, 10:21 #8
I do not know the term STAT-MUX but what you describes sound like regular transcoding. Normaly transcoding to a lower bitrate will use the existing IBP and GOP framestructure of the original stream and replace least used macroblocks with closest match. With mpeg-4 this can be a problem becouse deblocking filtering has been performed on the original macroblocks.
Taking a wild guess I would speculate that becouse of this, 1. gen mpeg-4 hardware will use a simpler mpeg-4 profile not performing all optimizations like deblocking. Combined with low-bitrate this would explain why you have more blocking then with mpeg-2 streams. Becouse you are infact watching something closer to mpeg-2 then mpeg-4 but at a much lower bitrate then normaly used for mpeg-2.
09-11-2006, 11:38 #9UregistrertGuest
STAT-MUX means Statistical Time Division Multiplexing. This is a fairly new technology as pertaining to broadcasting.
Prior to STAT-MUXES, broadcasters used CBR (Constant Bit Rate Multiplexers). For example when using CBR muxes, all 3 encoders using a 46 mb/s transponder would be set to output a constant bit rate of 15.3 mb/s.
A STAT-MUX allows streams to exceed the 15.3 mb/s by borrowing bit rate from the other streams on the multiplexer. The only requirement is that the total bit rate of all streams cannot exceed 46 mb/s. When the total bit rate exceeds 46 mb/s, the STAT-MUX will first eliminate null packets to to try to reduce the bit rate below 46 mb/s. If that still does not get the total bit rate below 46 mb/s, then it starts to perform rate shaping (on the fly packet manipulation) on the streams to reduce the bit rate.
STAT-MUXES are suppose to work fairly well if you have the correct content mix on the transponder (eg. 1 Sport channel, 1 movie channel, 1 nature channel). This is what both Sky HD and German Premiere HD have on their transponders (1 Sport channel, 1 movie channel, and Discovery HD) and both use a STAT-MUX. They should never put 2 sports channels on the same transponder that is using a STAT-MUX as this can easily overdrive the STAT-MUX causing a very poor quality picture.
When using a STAT-MUX it is important that the maximum bit rate of each encoder be set. If maximum bit rate of the encoders were set to 25 mb/s, all 3 channels could be outputing 25 mb/s causing the STAT-MUX to possibly produce a very low quality picture by requiring the STAT-MUX to rate shape the combined streams to eliminate 24 mb/s. Therefore each of the broadcasters must determine what will be the maximum bit rate of each of the encoders (eg. 16, 17, 18, 19, 20, 21 mb/s). STAT-MUXES are supposed to be very good at reducing the bit rate when only small amounts have to be rate shaped. If a large amount of bit rate has to be reduced, the encoder does a much better job than the STAT-MUX.
09-11-2006, 11:44 #10
So a stat-mux is really a poor-mans transcoder for adapting multiple channels to a singel mux, exploiting statistical differences between the channels.
An optimum solution would probably be a real "multichannel encoder" that produce M videostreams from M high-rate sources into a fixed total bandwidth B where the individual allocated bandwidth for each channel is perfectly perceptually weighted against the others.
09-11-2006, 11:53 #11UregistrertGuest
The problem is that there is no such thing as a realtime "mulitchannel encoder". Since everything has to be done in realtime, there isn't any other solution. It is difficult enough to get one channel to work with an encoder in realtime.
If someone can develop a multichannel realtime encoder, they should have a very large market to sell to.
09-11-2006, 11:58 #12UregistrertGuest
In fact the easiest way to solve the problem would be to have the mux just notify the encoders to again encode at the designated bit rate. However, hardware encoders have already used up the time and don't have time to encode again.
09-11-2006, 12:11 #13
Perhaps encoders could use "enhancement layers", effectively splitting the encoded stream into "important" vs "less important" data. Then the mux would have an easier job switching between for instance 8, 15 and 20mbit versions of the stream. Then the choices would really be a 3x3 matrix of 3 channels at 3 different individual rates.
I expect that as hardware and algos improve, realtime multichannel encoders will just as common as realtime consumer MPEG2 encoders are today?
09-11-2006, 12:13 #14
If a 1 second delay is tolerated I suspect that it is enough "look-ahead" to have a feedback from encoder 1, 2 and 3 back into the rate-controls of encoders 1, 2 and 3. If these are upto realtime individual channel encoding of VBR, some granularity could be achieved in global bit budget optimisation?
09-11-2006, 12:16 #15UregistrertGuest
I don't believe multichannel encoders would be the best way to go since there could be anywhere between 2 and 12 channels on one transponder (SD as well as HD).
09-11-2006, 21:36 #16UregistrertGuest
In the US, MPEG4 hardware encoders are used sparingly and only as endpoint encoders (source, backhaul, and distribution encoders are still MPEG2). The few MPEG4 encoders that are used are used by SAT providers for regional broadcasts (feeds from local FOX, NBC, CBS, and ABC affiliates) and have not had significant microblocking problems that are experienced by Sky HD (in the US, the hard work had already been done by the MPEG2 encoders and the MPEG4 encoders only have to reduce the bit rate slightly to fit on the transponder). Although significant microblocking has not occurred, the MPEG4 encoders have been more problematic than the MPEG2 encoders.
So there is no real comparision between MPEG2 and MPEG4 encoders when comparing the UK and US.
09-29-2006, 07:50 #17UregistrertGuest
It appears that Sky has given up waiting for the manufacturer of the MPEG4 hardware encoders to fix the problem. Last week they moved one of the channels off the transponder that contained Sky Movies 9 and Sky Sports HD1 and the problems on those two channels have disappeared. Now each of those channels have an average bit rate of 23 mb/s.
In the near future they are also planning to move a channel off the transponder that is carrying Sky Movies 10 and Sky One which will raise those bit rates to about 23 mb/s also.
Those 4 channels are the main channels that customers were concerned about so most people will be happy. The other 6 channels will all be on transponders with three channels giving them each an average 15.3 mb/s so problems may still occur on those channels.
I believe that Sky was planning to use the two slots that were available on the transponders for new channels that they wanted to add in the near future. So it appears that Sky will either be delay adding new HD channels or will lease another transponders for about US $1.5m per year.
I expect that Sky probably purchased MPEG4 encoders from different manufacturers to try to solve the problems but couldn't find any that worked any better. Fortunately for UK customers, Sky didn't try to take the cheap way out and start broadcasting HD Lite (1440x1080i). Once a company starts broadcasting HD Lite they seldom return to the full 1080i (1920x1080).