On Tue, 8 Sep 2009, Carsten Meier wrote: > Am Tue, 8 Sep 2009 10:37:23 -0500 (CDT) > schrieb Mike Isely <[email protected]>: > > > On Tue, 8 Sep 2009, Carsten Meier wrote: > > > > > Am Mon, 07 Sep 2009 22:51:14 +0200 > > > schrieb Bernhard Geier <[email protected]>: > > > > > > > [email protected] schrieb: > > > > > Here below is a patch for the setup: > > > > > Linux 2.6.29.6, 24xxx device, cx25840 decoder, firmware > > > > > 2.06.039. > > > > Works! Thank you! > > > > > > > > This settings elimiate the black borders at top & bottom: > > > > > > > > echo "16x9" > ctl_video_aspect/cur_val > > > > echo 428 > ctl_crop_height/cur_val > > > > echo 72 > ctl_crop_top/cur_val > > > > > > > > Bernhard > > > > > > > > > > I don't have the ability to test it yet, because I'm currently > > > connected to a satelite dish, but shouldn't the aspect-ratio of the > > > stream be automatically calculated from the cropping settings? > > > > The driver does not internally attempt to set that control, and I > > seriously doubt that the mpeg encoder would do that on its own > > either. > > > > -Mike > > > > The video aspect control should not change, because it specifies the > aspect ratio of the input signal, which remains constant. But the aspect > ratio of the MPEG stream should be adapted accordingly to preserve pixel > dimensions. E.g.: A 4:3 letterboxed TV broadcast (with square pixels) > contains an 2:1 image with black bars at the top and the bottom. If I > set the crop-controls to remove the black bars, shouldn't the MPEG > stream have an aspect ratio of 2:1? (A value that is not even settable > through controls, because of the enum) Otherwise the square pixels get > streched.
If I understand what you are saying here, then you are suggesting that: 1. The driver always assumes that the incoming video frame is 4:3 2. The driver calculates the apparent effect on the aspect ratio from any cropping operation. 3. Based on the calculation from (2), then the driver should SET video_aspect by itself. I have three problems with that: First, I don't think it's fair for the driver to assume that the incoming video is always 4:3. That reality really depends on how the device is being used. One obvious case I can come up with is if someone were using this to capture anamorphic video (from, say, a DVD player). Second, any such calculation is extra magic that I don't think belongs in the driver (though I could probably be swayed on this point). Third, the mpeg encoder does not allow for arbitrary setting of the aspect ratio value. The reason why you don't see 2:1 as one of the choices is because that enumerated set of values is due entirely to the mpeg encoder's own internal API. It really is an enumeration on the inside. We simply don't have any other choices besides the ones that are listed. Thus what is the driver supposed to do now if the calculated aspect ratio doesn't match one of the choices? Pick the closest? Define "closest" (remember, we're dealing with 2 dimensions so it isn't a linear relation). And if the driver's idea of closest isn't liked by the user, then what? What the driver does right now is that it makes no assumptions about the incoming aspect ratio; after all, to assume something here would really be just "making up" additional input information out of nothing. The driver does provide a knob that userspace can twiddle to set the *output* aspect ratio (i.e. video_aspect). Given that (1) userspace is in control of the cropping, (2) userspace is in control of the setting of the aspect ratio, and (3) only the user *really* knows what the aspect ratio is of the incoming signal, then any such calculation and adjustment probably really belongs in userspace. Then again, perhaps I'm not following you here?... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
