| From: Lennart Sorensen via talk
| b/c could be read as b divided by c. After all we use ppi for pixels
| per inch.
"per" *is* a division. Of units
10 b/c
* 3 c/pixel
= 30 b/pixel
300 p/in
* 8.5 in
= 2550 p
This kind of operation on units is called dimensional analysis. It is
a very
| From: Scott Allen via talk
| On Tue, 20 Jun 2023 at 10:40, James Knott via talk wrote:
| > Is this documented anywhere? Sure the audio is sent over the cable, but
| > why should there be such a thing as a blanking interval on a digital
| > system?
|
|
On 2023-06-20 15:06, Lennart Sorensen wrote:
My understanding was that on a CRT it needed a bit of blanking time in
order to have time to change the magnetic field so the beam could start
at the begining of the next line. Whether you used composite sync or
seperate H and V sync didn't matter,
On Tue, 20 Jun 2023 at 15:07, Lennart Sorensen via talk wrote:
> After all we use ppi for pixels per inch.
And miles per gallon is commonly MPG (though the metric standard
reverses the terms and uses the slash; litres per 100 kilometres -
L/100km).
--
Scott
---
Post to this mailing list
On Tue, Jun 20, 2023 at 03:04:38PM -0400, D. Hugh Redelmeier via talk wrote:
> That's an odd resolution. Of course that makes your point clearer:
> it's just arithmetic.
>
> But of course it is not. There is a certain amount of extra
> jiggery-pokery added.
>
> My first post on this topic
On Tue, Jun 20, 2023 at 11:16:05AM -0400, James Knott via talk wrote:
> Other than a small bit about lip sync, there is nothing about syncing the
> signal in that.
Well https://www.youtube.com/watch?v=5acgSK0kWTE has a lot of details
on how HDMI works. I don't think it says how audio and video
| From: Alvin Starr via talk
| The bit rate going over HDMI would be something like:
| Image height * Image width * pixel size * frame rate.
|
| So for an example:2048*1024*24*60 = 3,019,898,880bits/s
| Add on to that the overhead for some number of audio channels.
That's an odd resolution.
On Tue, Jun 20, 2023 at 11:24 AM Scott Allen via talk
wrote:
>
>
> https://en.wikipedia.org/wiki/Vertical_blanking_interval#Vertical_blanking_interval_in_digital_video
>
>
If one follows through that link, it seems we still have vblank because
accessibility tools required it for timing and
On 6/20/23 11:16, James Knott via talk wrote:
On 2023-06-20 10:50, Lennart Sorensen wrote:
https://www.fpga4fun.com/files/HDMI_Demystified_rev_1_02.pdf gives a
nice explanation of how it worked in HDMI 1.3. 2.1 just got rid of the
dedicated clock to free up a 4th signal pair.
Other than a
On Tue, 20 Jun 2023 at 10:40, James Knott via talk wrote:
> Is this documented anywhere? Sure the audio is sent over the cable, but
> why should there be such a thing as a blanking interval on a digital
> system?
On 2023-06-19 18:04, D. Hugh Redelmeier via talk wrote:
Except varous things exploited them. Like whacking on GPU registers only
during blanking intervals to avoid tearing.
You may recall the Sinclair ZX80, which had a performance mode which
killed the video. If you wanted a display, you
On 2023-06-20 10:50, Lennart Sorensen wrote:
https://www.fpga4fun.com/files/HDMI_Demystified_rev_1_02.pdf gives a
nice explanation of how it worked in HDMI 1.3. 2.1 just got rid of the
dedicated clock to free up a 4th signal pair.
Other than a small bit about lip sync, there is nothing about
On Tue, Jun 20, 2023 at 10:40:31AM -0400, James Knott wrote:
> Is this documented anywhere? Sure the audio is sent over the cable, but why
> should there be such a thing as a blanking interval on a digital system?
> The blanking interval was used to sync the camera and TV. There is
> absolutely
On 2023-06-20 09:23, Lennart Sorensen wrote:
Supposedly HDMI is using some of the blanking space to send audio,
so I guess it has some use.
Is this documented anywhere? Sure the audio is sent over the cable, but
why should there be such a thing as a blanking interval on a digital
system?
On Mon, Jun 19, 2023 at 03:11:44PM -0400, James Knott via talk wrote:
> That doesn't make sense, especially when you consider how the digital system
> works, with things like I, P and B frames.
> https://en.wikipedia.org/wiki/Video_compression_picture_types
Compressed video is not related to how
| From: James Knott via talk
| On 2023-06-19 18:04, D. Hugh Redelmeier via talk wrote:
| > Is such compression part of what HDMI carries? For computer monitors?
| > Almost all compression used in video is lossy -- not what I want for a
| > computer monitor
|
| I don't know the details of what
On 2023-06-19 18:04, D. Hugh Redelmeier via talk wrote:
Is such compression part of what HDMI carries? For computer monitors?
Almost all compression used in video is lossy -- not what I want for a
computer monitor
I don't know the details of what HDMI, but compression would generally
be done
| From: James Knott via talk
|
| On 2023-06-19 14:47, D. Hugh Redelmeier via talk wrote:
| > One silly wast of bandwidth is blanking intervals. That mattered for CRTs
| > since steering the electron beam took time. It should not matter for
| > LCDs.
|
| That doesn't make sense, especially
On 2023-06-19 14:47, D. Hugh Redelmeier via talk wrote:
One silly wast of bandwidth is blanking intervals. That mattered for CRTs
since steering the electron beam took time. It should not matter for
LCDs.
That doesn't make sense, especially when you consider how the digital
system works,
Video bandwidth is precious. In particular the HDMI standards seem to
lag in providing the bandwidth I need. Partly because I run old hardware.
One silly wast of bandwidth is blanking intervals. That mattered for CRTs
since steering the electron beam took time. It should not matter for
20 matches
Mail list logo