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