[linux-dvb] TT-3200 DVB-S2 Patch for Kernel 2.6.22

[Thomas Kernen]

Joerg Knitter wrote:
> Ulrich schrieb:
>> Hi,
>>
>>
>> P. van Gaans wrote:
>>> What HDTV do you expect to enjoy exactly? BBC HD doesn't require DVB-S2, most other channels use PAFF interlacing which isn't supported
>> AFAIK, most films originally produced for the big-screen are broadcasted
>> non-interlaced.
>>
>> At least, there were some downloadable, short recordings from films
>> aired on Pro-7, and I could play them in MPlayer without any problem.
>>
>> And as you said, there seems to be some progress with ffmpeg and PAFF,
>> >from what I've heard.
> 
> Maybe I have to correct myself believing, everything would be interlaced 
> as it was in SD land. I found the following on the net:
> 
> "
> PAFF means "Picture Adaptive Field Frame", MBAFF means "MacroBlock 
> Adaptive Field Frame".
> * PAFF allows to decide, on a frame basis, whether to encode each frame 
> as a frame or as two fields. When encoded as two fields, it's as if you 
> would have done a separatefields() on the frame.
> * MBAFF allows to decide, on a macroblock basis, whether to encode as 
> field or frame. Actually, it works on vertical pairs of macroblocks, so 
> on 16x32 areas. You can easily put two frame macroblocks ( on under the 
> other ), or two field ones ( one with the top lines, the other with the 
> bottom lines ).
> "
> 
> So, there is still a difference between the interlaced flag being set 
> and not being set, but if it is set, there might also be some kind of 
> progressive frames:
> 
> "
> Like Manao said only if the encoder does it well, it will never encode 
> anything interlaced from a progressive source, Tandberg H.264 encoder 
> seems to think otherwise.
> 
> ... Now something about PAFF, again using bond's thread:
> 
> ASTRA.HD.Demokanal.H.264.001.ts = paff progressive (1080p)
> mb_adaptive_frame_field_flag: 0
> frame_mbs_only_flag: 0
> field_pic_flag: 0
> field_pic_flag: 1 <-- not found
> 
> sky-hd.sample.ts = paff progressive (1080p)
> mb_adaptive_frame_field_flag: 0
> frame_mbs_only_flag
> field_pic_flag: 0
> field_pic_flag: 1 <-- not found
> 
> In the above 2 samples all frames are encoded progressive, so the result 
> can be called: 1080p
> 
> All H.264 HD channels, except BBC-HD, all broadcast PAFF-progressive 
> video (according to the log files created by h264_parse)
> "
> 
> The author of this information has added:
> 
> "
> BC-HD (MBAFF) 1440x1080 uses the Grass Valley H.264 solution:
> http://www.thomsongrassvalley.com/pr...oder_mpeg4_hd/
> 
> And most other H.264 (PAFF) channels, like for example Sky-HD 1920x1080, 
> use the Tandberg H.264 solution:
> http://www.tandberg.net/our_story/h264.jsp
> 
> LUXE HD on Eutelsat 7 east uses 1280x1080 MBAFF by Ateme, the quality is 
> superb!
> 
> I guess now there are 4 players on the H.264 Satellite market:
> 
> grass valley, ViBE H.264: 
> http://www.thomsongrassvalley.com/pr...oder_mpeg4_hd/
> scientific atlanta, H.264: 
> http://www.scientificatlanta.com/cus...ce/7006554.pdf
> tandberg, H.264: http://www.tandberg.net/our_story/h264.jsp
> ateme, H.264: http://www.ateme.com/BB_HD_4Chip.php
> "
> 
> Maybe this information clears it up a little bit more - or even confuses 
> more :)
> 

Do keep in mind that you can also have PAFF and MBAFF used together in a 
video stream. One field can be encoded using PAFF whilst the other used 
MBAFF. As for the SPS.field_pic_flag, they don't always seem to be 
properly set (AFAIK).

Thomas