Raspberry Pi for XBMC, some myths and truths
#59
(2013-01-24, 21:39)wejones Wrote:
(2013-01-24, 18:56)Vertigo Wrote: I dont even know what 4.2.2 is, but if you can point me to a sample video, I can try it for you.

edit: scratch that, I dont have an mpeg2 license. Maybe Ill order one..

.....

Didn't see the edit soon enough. I uploaded a very short 15 sec MPEG2 clip of a 4.2.2 network show that I just recorded.
http://www.eskerridge.com/bj/sat/test4.2.2b.mpg
I'll leave it there or a day, and if you ever get the license you can try it if nobody else knows for sure if it will work.
I don't know much about exactly what the 4.2.2 is, but most video is 4.2.0. It's supposed to be the chroma info, and the numbers relate somehow to how many frames of different types of color info are sent, so 4.2.2 has more color info than 4.2.0.
CBS uses 4.2.2 in their feeds to the stations, and some of the other networks do too. Programs like VLC can do it, but most sat receivers don't.

If I can remember where I've seen it, I'll try to find a clip of MPEG4 4.2.2 . It's not as common as the MPEG2 version.

4:2:2 is the standard format used within broadcasters. It means that for every 4 Y (luminance) samples in a line there are 2 Cr (R-Y chroma difference) and 2 Cb (B-Y chroma difference) samples. This means that the chrominance has the same vertical resolution as the luminance and half the horizontal resolution.

4:2:0 is the standard format used for the final leg of broadcasting to the home (DVB, ATSC, ISDB all use it) and for Blu-ray, DVD etc. It means that for every 4 Y samples there are 2 Cr samples on one line, and 2 Cb samples on the next line (i.e. you only get Cr or Cb samples on alternate lines). This means that the chrominance has half the horizontal AND half the vertical resolution of the luminance.

Consumer hardware used to be 4:2:0 only - however I noticed that my WDTV live is fine with 4:2:2 MPEG2 stuff recorded from satellite (though not 4:2:2 H264 stuff).

(2013-01-24, 20:41)RealDealNeil Wrote: As I understand it, 1080i is interlaced so that it alternates between sending even and odd rows in each frame. Therefore, only 540 lines are sent each frame but it is so fast that the illusion of 1080 lines is there.
Kind of. For static and slow moving information - where there is no movement between the two 1080i fields - decent de-interlacers should deliver vertical resolution closer to 1080p (though most interlaced cameras use a clever frame-line-offset line-pairing algorithm to derive their 540line fields from their source 1080p - or in some cases 4320p - sensors) Only on fast motion does the vertical resolution drop to that of a 540p system.

However on all motion the horizontal resolution should be 1920 (compared to 1280 for 720p) - though some transmission systems use 1440x1080 or even 1280x1080 to save bandwith.

Quote:Whereas 720p sends 720 rows in every frame (better for sports with fast motion). This would make 720p more heavy to render than 1080i.

Nope :
1920x540 = 1036800 luma samples
1280x720 = 921600 luma samples

So there are still more samples to render with a 1080i field than a 720p frame. So if you are comparing 1080/60i with 720/60p you still have more samples/pixels to render with 1080i.

If you are also de-interlacing 1080i then you need even more grunt to do a decent job.

720p is lighter to render as it has fewer pixels/samples and no de-interlacing requiremnt.
Reply


Messages In This Thread
RE: Raspberry Pi for XBMC, some myths and truths - by noggin - 2013-01-25, 14:25
Logout Mark Read Team Forum Stats Members Help
Raspberry Pi for XBMC, some myths and truths 4