Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset

From: Andy Walls <awalls@md.metrocast.net>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Tomasz Stanislawski <t.stanislaws@samsung.com>,
	linux-media@vger.kernel.org, m.szyprowski@samsung.com,
	kyungmin.park@samsung.com, laurent.pinchart@ideasonboard.com
Subject: Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Date: Tue, 05 Jul 2011 21:05:34 -0400	[thread overview]
Message-ID: <76f37109-8b9b-4bd6-aee8-0d4f75cc0dc2@email.android.com> (raw)
In-Reply-To: <4E139D50.4050406@redhat.com>

Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

>Em 05-07-2011 16:02, Andy Walls escreveu:
>> Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> I can work on the proposal this week for that. The only reason the
>fps
>>> hasn't been added
>>> yet is that I never had the time to do the research on how to
>represent
>>> the fps reliably
>>> for all CEA/VESA formats. Hmm, pixelclock / total_framesize should
>>> always work, of course.
>>>
>>> We can add a flags field as well (for interlaced vs progressive and
>>> perhaps others such as
>>> normal vs reduced blanking).
>>>
>>> That leaves the problem with GTF/CVT. I'll get back to that
>tomorrow. I
>>> have ideas, but
>>> I need to discuss it first.
>>>
>>> Regards,
>>>
>>> 	Hans
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>linux-media"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> For fps you could use horizontal_line_freq/lines_per_frame.
>> 
>> However, all of the non-integer fps numbers I have seen in this email
>chain all seem to be multiples of 29.97002997 Hz. So maybe you could
>just use the closest integer rate with a flag labeled
>"ntsc_bw_timing_hack" to indicate the fractional rates. :) 
>
>CEA-861 has some other timings that are not 60 Hz * 1000/1001. Yet,
>v4l2_fract
>is capable of handling any of such timings, as, whatever frequency
>taken, it
>needs to be a fractional number. Btw, even some userspace libraries
>prefer to
>represent fps using a fraction, instead of a float, to avoid rounding
>issues.
>
>> 
>> That 29.97 Hz number comes from the NTSC decision in 1953(!) to
>change the horizontal line freq to 4.5 MHz/286.  Note that
>> 
>> (4.5 MHz/286)/525 = 30 * (1000/1001) = 29.97002997 Hz
>
>One of the rationale for that decision was to avoid flicking issues
>with cathodic 
>ray monitors and fluorescent lamps.
> 
>> It is interesting to see one of the most ingenious analog hacks in TV
>history (to achieve color and B&W backward compatabilty while staying
>in the 10% tolerance of the old B&W receivers) being codified in
>digital standards over 50 years later. It boggles the mind...
>
>Yes. Bad (and good) API decisions will stay forever.
>
>Cheers,
>Mauro.

Oops, yes I see the 60.054 Hz rate corresponds to a 262 line field (524 line frame) at the standard NTSC line rate.

Weird stuff.

Regards,
Andy