[vdr] How does VDR handle AFD?

[Christian Gmeiner]

Klaus Schmidinger wrote:

> Reinhard Nissl wrote:
>
>> Hi,
>>
>> Christian Gmeiner wrote:
>>
>>> i am currently interested in this topic and wanted to know how VDR 
>>> does handle this. If you dont know what AFD is:
>>> http://www.pjdaniel.org.uk/afd/index.html
>>> http://www.dtg.org.uk/publications/books/afd.pdf
>>>
>>> I think that VDR needs a menuentry where the user must specify what 
>>> kind of tv-set he owns (4:3 or 16:9).
>>> If we add this we could make use of the AFD header in VDR. Maybe i 
>>> am wrong and AFD is allready supported by VDR.
>>
>>
>>
>> Well, I've added extracting AFD information in xine. But so far, I do 
>> nothing more than storing this information as stream info.
>>
>> As far as I can tell, VDR doesn't extract any AFD information from 
>> video streams. But it should not be too complicated to add this to 
>> cRemux::ScanVideoPacket(), due to the repacking of cVideoRepacker.
>>
>> AFD information appears in the video stream after user data 
>> startcodes (0x000001B2) and these appear before picture start codes 
>> (0x00000100). Typically, there are only a few bytes between those 
>> startcodes. And as cVideoRepacker ensures a new PES packet for each 
>> picture, AFD information should be in the same 2048 byte block where 
>> ScanVideoPacket() finds the picture start code.
>>
>> The next few lines are from xine-lib/src/libmpeg2/decode.c:
>>
>> /* check Active Format Description ETSI TS 101 154 V1.5.1 */
>> else if (buffer[0] == 0x44 && buffer[1] == 0x54 && buffer[2] == 0x47 
>> && buffer[3] == 0x31)
>> {
>>   int afd = (buffer[4] & 0x40) ? (buffer[5] & 0x0f) : -1;
>>   _x_stream_info_set(mpeg2dec->stream, XINE_STREAM_INFO_VIDEO_AFD, afd);
>> }
>>
>> And these are from xine-lib/include/xine.h:
>>
>> /* possible values for XINE_STREAM_INFO_VIDEO_AFD */
>> #define XINE_VIDEO_AFD_NOT_PRESENT         -1
>> #define XINE_VIDEO_AFD_RESERVED_0          0
>> #define XINE_VIDEO_AFD_RESERVED_1          1
>> #define XINE_VIDEO_AFD_BOX_16_9_TOP        2
>> #define XINE_VIDEO_AFD_BOX_14_9_TOP        3
>> #define XINE_VIDEO_AFD_BOX_GT_16_9_CENTRE  4
>> #define XINE_VIDEO_AFD_RESERVED_5          5
>> #define XINE_VIDEO_AFD_RESERVED_6          6
>> #define XINE_VIDEO_AFD_RESERVED_7          7
>> #define XINE_VIDEO_AFD_SAME_AS_FRAME       8
>> #define XINE_VIDEO_AFD_4_3_CENTRE          9
>> #define XINE_VIDEO_AFD_16_9_CENTRE         10
>> #define XINE_VIDEO_AFD_14_9_CENTRE         11
>> #define XINE_VIDEO_AFD_RESERVED_12         12
>> #define XINE_VIDEO_AFD_4_3_PROTECT_14_9    13
>> #define XINE_VIDEO_AFD_16_9_PROTECT_14_9   14
>> #define XINE_VIDEO_AFD_16_9_PROTECT_4_3    15
>>
>> But don't expect this feature to be part of VDR-1.4.
>
>
> I wouldn't expect it to be part of _any_ VDR version.
> This is something the actual _player_device_ would have to do.
> Since VDR doesn't parse the video data in live mode, this would only
> work for recordings or Transfer Mode. cRemux with all this new cRepacker
> stuff is overloaded to the max as it is already...

Ok.. so will add afd stuff to dxr3 driver & plugin.
Thanks,
Christian

>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Christian Gmeiner
Developer for Rockbox (http://www.rockbox.org)
Maintainer of the DXR3-Plugin for VDR: http://sourceforge.net/projects/dxr3plugin/
Maintainer of VDR-Ebuilds at Gentoo.de