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