Hi all,
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.
Greets, Christian
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.
Bye.
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
Reinhard Nissl wrote:
AFD information appears in the video stream after user data startcodes (0x000001B2) and these appear before picture start codes (0x00000100).
User data and thus AFD can be in other places, too (in theory, I have no practical experience). Described in the MPEG-2 video spec.
/* check Active Format Description ETSI TS 101 154 V1.5.1 */
Yeah, that's the spec.
AFAIK AFD is only used in the UK.
Johannes
On Thu, 2005-09-15 at 01:07 +0200, Johannes Stezenbach wrote:
Reinhard Nissl wrote:
AFD information appears in the video stream after user data startcodes (0x000001B2) and these appear before picture start codes (0x00000100).
User data and thus AFD can be in other places, too (in theory, I have no practical experience). Described in the MPEG-2 video spec.
/* check Active Format Description ETSI TS 101 154 V1.5.1 */
Yeah, that's the spec.
AFAIK AFD is only used in the UK.
I think AFD is in use on one channel here in Australia.
I have tried the AFD patches for the dxr3 plugin, but the annoying thing is that when I switch from an AFD channel to a non-AFD channel the framesize/aspect ratio is not reset.
Johannes
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I think AFD is in use on one channel here in Australia.
I have tried the AFD patches for the dxr3 plugin, but the annoying thing is that when I switch from an AFD channel to a non-AFD channel the framesize/aspect ratio is not reset.
What channel? I also thought there was AFD data in at least some of the ausy channels, but I found a unix test tool dvbsnoop (http://dvbsnoop.sourceforge.net/) which apprantly can tell me if there is AFD data in a stream. I found none in the particular channel which was giving visual artifacts (10) which convonced me I was barking up the wrong tree... I ended up writing a filter to block the artifacts in xine (still testing.., it's half way working).
Did the dxr3 patches work as expected? I'd love for AFD to be there..
Mick
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
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Thu, 15 Sep 2005 15:57:23 +0000 Christian Gmeiner christian@visual-page.de wrote:
Ok.. so will add afd stuff to dxr3 driver & plugin. Thanks, Christian
Did you already take a look at the patch mentioned before: http://www.jburgess.uklinux.net/afd/
-- Niko Mikkilä
Niko Mikkila wrote:
On Thu, 15 Sep 2005 15:57:23 +0000 Christian Gmeiner christian@visual-page.de wrote:
Ok.. so will add afd stuff to dxr3 driver & plugin. Thanks, Christian
Did you already take a look at the patch mentioned before: http://www.jburgess.uklinux.net/afd/
Sure... but i think i will write my own stuff.. and a better em8300 driver patch.
-- Niko Mikkilä
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Johannes Stezenbach wrote:
AFD information appears in the video stream after user data startcodes (0x000001B2) and these appear before picture start codes (0x00000100).
User data and thus AFD can be in other places, too (in theory, I have no practical experience). Described in the MPEG-2 video spec.
You are right, there are 3 places for user data: user data 0 is in front of a group start code, user data 1 appears in front of the picture start code and user data 2 is before the first slice start code.
But all of them should typically be within 2048 bytes when cVideoRepacker starts a new PES packet just after the last slice of a picture.
Bye.
On Thursday 15 September 2005 15:55, Niko Mikkila wrote:
On Thu, 15 Sep 2005 15:57:23 +0000
Christian Gmeiner christian@visual-page.de wrote:
Ok.. so will add afd stuff to dxr3 driver & plugin. Thanks, Christian
Did you already take a look at the patch mentioned before: http://www.jburgess.uklinux.net/afd/
I can vouch for these patches work well for me in the UK for DVB-T with a dxr3.
Cheers,
Laz
Laz wrote:
On Thursday 15 September 2005 15:55, Niko Mikkila wrote:
On Thu, 15 Sep 2005 15:57:23 +0000
Christian Gmeiner christian@visual-page.de wrote:
Ok.. so will add afd stuff to dxr3 driver & plugin. Thanks, Christian
Did you already take a look at the patch mentioned before: http://www.jburgess.uklinux.net/afd/
I can vouch for these patches work well for me in the UK for DVB-T with a dxr3.
AFD support will be in cvs... later... when my new demuxer and av-syncer is ready.
Greets
-
Christian Gmeiner -
Johannes Stezenbach -
Klaus Schmidinger -
Laz -
Malcolm Caldwell -
mike lewis -
Niko Mikkila -
Reinhard Nissl