How does VDR handle AFD?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thats a good beginning...

>
> 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 dont expect it, but i think it might be very usefull. I come to this 
topic, becuase
there is an patch for the dxr3 plugin and dxr3 driver, which includes 
such afd header
support, but i dont think its the best way to it this way.

Also i dont know how dvb driver support such stuff. If they support it, 
we have a fine base
to start wokring on this topic.

Greets

-- 
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



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux