Steve Longerbeam <slongerbeam@xxxxxxxxx> writes: >> but it should be possible for the user to explicitly request the field >> order on CSI output (I can make a patch I guess). > > If you think that is the correct behavior, I will remove the override > code. I suppose it makes sense to allow user to select field order even > if that order does not make sense given the input standard. I'm fine > either way, Philipp what is your opinion? I'll go with the popular vote :) I think it should be up to the user. Actually, PAL and NTSC aren't valid names in the digital world. Their meaning ends in the ADV7180 (or equivalent). I don't know if PAL and/or NTSC specify the field order in the analog frame (meaningful when someone hooks a camera with progressive sensor and analog, interlaced output), but the digital YUV422 from ADV to CSI isn't NTSC/PAL anymore. It's just WxH @ framerate + possible interlacing, sequential fields, top-bottom or otherwise, etc. The analog standard names could be used here but just as defaults. If we were strict (and we don't want to force it), then we should set NTSC/PAL thing on ADV7180 input, 720x480@29.97i (or 720x576@50i, or 704x... etc) on the input parts of the CSI/IPU (where there are no video frames yet), and 720x480@29.97i B-T or T-B (or default, or separate fields - whatever suits the user) on the output from CSI. I remember the reversed field order was sometimes needed - for example, PAL DV (the casette camcorder thing) produced B-T frames (same as NTSC), and to avoid (slight) additional quality loss one had to process it (up to e.g. .MP4, DVD, and then to HDMI, SCART etc) as B-T. It wasn't a problem in otherwise-PAL-centric environment. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
