From: VDR User user.vdr@gmail.com Subject: Re: [vdr] PVRINPUT plugin and "black/cinema bars"
I am pretty sure that your TV station broadcasts analogue TV not anamorphic, which means it "delivers" the black bars to prevent the aspect ?ratio of a 16:9 content.
The 'black bars' are called letterboxing. It's used to _preserve_ the aspect ratio of widescreen content on 4:3 displays, not prevent it as you've suggested.
I meant that. Sorry for the mistake, english is not my native language.
Unfortunately there is no way to detect the incoming signal (Tuner or extern). Therefore it is not possible to automatically choose the right setting.
Sure there is, just look in the mpeg headers. If for some reason that flag isn't set correctly, you can also use the resolution along with some simple math to calculate the aspect ratio.
The mpeg is not delivered by the broadcaster, it is generated by the encoder. The content of the header is a result of the V4L2_CID_MPEG_VIDEO_ASPECT setting done by the application.
Any ideas how to remove these?
The driver does not support clipping/cropping. We will always encode the whole capture size. If there is already a bar, it will also be in the encoded stream. You could try to use the zoom mode of your TV.
You _could_ write some functions to detect and remove letterboxing, though I don't know anyone motivated enough to actually do it.
The main goal of the pvrinput-plugin is to use the hardware encoder.I think it is a bad idea to do software-based on-the-fly-recoding.
Simon, which output device do you use? Maybe the xine- or xineliboutput-Plugin can do the needed zoom for you. (?)
Greets, Martin
On Mon, Apr 26, 2010 at 12:42 PM, Martin Dauskardt md001@gmx.de wrote:
The mpeg is not delivered by the broadcaster, it is generated by the encoder. The content of the header is a result of the V4L2_CID_MPEG_VIDEO_ASPECT setting done by the application.
If the aspect ratio flag is unreliable, again, you can always just use the resolution and calculate it.
You _could_ write some functions to detect and remove letterboxing, though I don't know anyone motivated enough to actually do it.
The main goal of the pvrinput-plugin is to use the hardware encoder.I think it is a bad idea to do software-based on-the-fly-recoding.
If you want to limit the plugin to using only the hardware then I agree. However, if you want to provide capabilities beyond what the hardware is capable of then software is the only other place to do it. This is perfectly fine, although it probably means the user wasted his money on a hardware decoder if he's just going to do software decoding anyways. It doesn't hurt to put more consideration into what you want/need before pouring money into hardware. I know guys that threw a lot of money at hardware decoders only to replace them with cheap vdpau-capable video cards. To each his own I suppose. :)
Cheers
On Mon, Apr 26, 2010 at 12:42 PM, Martin Dauskardt md001@gmx.de wrote:
The mpeg is not delivered by the broadcaster, it is generated by the encoder. The content of the header is a result of the V4L2_CID_MPEG_VIDEO_ASPECT setting done by the application.
If the aspect ratio flag is unreliable, again, you can always just use the resolution and calculate it.
You _could_ write some functions to detect and remove letterboxing, though I don't know anyone motivated enough to actually do it.
The main goal of the pvrinput-plugin is to use the hardware encoder.I think it is a bad idea to do software-based on-the-fly-recoding.
If you want to limit the plugin to using only the hardware then I agree. However, if you want to provide capabilities beyond what the hardware is capable of then software is the only other place to do it. This is perfectly fine, although it probably means the user wasted his money on a hardware decoder if he's just going to do software decoding anyways. It doesn't hurt to put more consideration into what you want/need before pouring money into hardware. I know guys that threw a lot of money at hardware decoders only to replace them with cheap vdpau-capable video cards. To each his own I suppose. :)
Cheers
Except this is an input device, not an output device. It converts an analogue signal to mpeg2, as such, it needs to make guesses about what it's going to find..
On Mon, Apr 26, 2010 at 1:56 PM, Rob Davis rob@davis-family.info wrote:
Except this is an input device, not an output device. It converts an analogue signal to mpeg2, as such, it needs to make guesses about what it's going to find..
Ahh, analog source & encoding. There won't be any mpeg headers and so on from that. :) I wouldn't bother trying to address this problem at input to be honest. It makes much more sense to me to do it at output anyways.
Cheers
If you want to limit the plugin to using only the hardware then I agree. However, if you want to provide capabilities beyond what the hardware is capable of then software is the only other place to do it. This is perfectly fine, although it probably means the user wasted his money on a hardware decoder if he's just going to do software decoding anyways. It doesn't hurt to put more consideration into what you want/need before pouring money into hardware. I know guys that threw a lot of money at hardware decoders only to replace them with cheap vdpau-capable video cards. To each his own I suppose. :)
I think Martin's talking about the PVR-500 encoding aspect, not hardware-vs-software decoders.
I have no qualms about recoding - my production box is dual core 64-bit and sits mostly idle anyway :)
You _could_ write some functions to detect and remove letterboxing, though I don't know anyone motivated enough to actually do it.
The main goal of the pvrinput-plugin is to use the hardware encoder.I think it is a bad idea to do software-based on-the-fly-recoding.
Simon, which output device do you use? Maybe the xine- or xineliboutput-Plugin can do the needed zoom for you. (?)
I'm using vdr-xine, but as I have 2x DVB-C cards also there's only about 5 channels which I receive via the PVR-500. I could change the aspect in xine, but it would change it for ALL channels wouldn't it?
Is there a flag I can send xine to crop only _some_ channels?
I could also enable a remote key to switch aspect in xine, but I'm currently using vdr's lirc interface so would need to switch to xine's lirc (which can send lirc messages to vdr). Don't really want to do this - if possible.
Or is there another way around this?
I demand that Simon Baxter may or may not have written...
[snip]
I'm using vdr-xine, but as I have 2x DVB-C cards also there's only about 5 channels which I receive via the PVR-500. I could change the aspect in xine, but it would change it for ALL channels wouldn't it?
For DVB, http://xine-lib.alioth.debian.org/patches-1.1/AFD_support.patch may help. Otherwise, you're into auto-crop territory; the "expand" video output plugin will help.
[snip]
-
Darren Salt -
Martin Dauskardt -
Rob Davis -
Simon Baxter -
VDR User