What resolutions for encoding to play back on regular TVs (not HDTVs)?

[ANTant]

Is it 320x240 pixels? I am trying to figure out what resolution to
encode video capture from my ATI Radeon 9800's TV tuner. I want to play
back my recording to the TV. Note that the TV is like 20" so I don't
really notice the quality difference unless my TV and/or eyes suck. I
do not have a HDTV or any big screens, but I will never know when I
might need to do that.

Any suggestions? Thank you in advance.
--
"Now I have you where I want you... where is my jar of Bull ants?"
--unknown
/\___/\
/ /\ /\ \ Ant @ The Ant Farm: http://antfarm.ma.cx
| |o o| | E-mail: (e-mail address removed) or (e-mail address removed)
\ _ / Remove ANT if replying by e-mail from a newsgroup.
( )

 

[Ben Pope]

Is it 320x240 pixels? I am trying to figure out what resolution to
encode video capture from my ATI Radeon 9800's TV tuner. I want to play
back my recording to the TV. Note that the TV is like 20" so I don't
really notice the quality difference unless my TV and/or eyes suck. I
do not have a HDTV or any big screens, but I will never know when I
might need to do that.

You are not going to get a definitive answer on this!

Look here:
http://www.dvdrhelp.com/forum/userguides/94382.php

Seems that 480*384 is the recommended for PAL, 480 X 320 for NTSC.

HDTV is officially up to 1920x1080, but I certainly wouldn't recommand
grabbing that high unless your source is of that quality. (and even then
that would create some pretty large files)

Ben

 

[Markus Zingg]

Is it 320x240 pixels? I am trying to figure out what resolution to

encode video capture from my ATI Radeon 9800's TV tuner. I want to play
back my recording to the TV. Note that the TV is like 20" so I don't
really notice the quality difference unless my TV and/or eyes suck. I
do not have a HDTV or any big screens, but I will never know when I
might need to do that.

Any suggestions? Thank you in advance.

NTSC TV is 640x480 PAL is 768x576 note though that the horizontal
number of pixels may slightly vary without causing a problem. I.e.
with PAL, Most TV's would not display more than 720 pixels.

Markus

 

[Blood Dawg]

Is it 320x240 pixels? I am trying to figure out what resolution to
encode video capture from my ATI Radeon 9800's TV tuner. I want to play
back my recording to the TV. Note that the TV is like 20" so I don't
really notice the quality difference unless my TV and/or eyes suck. I
do not have a HDTV or any big screens, but I will never know when I
might need to do that.

Any suggestions? Thank you in advance.

Do it in 352x240. That way it will also be ready for vcd. (mpeg1)

 

[ANTant]

You are not going to get a definitive answer on this!

Look here:
http://www.dvdrhelp.com/forum/userguides/94382.php

Seems that 480*384 is the recommended for PAL, 480 X 320 for NTSC.

HDTV is officially up to 1920x1080, but I certainly wouldn't recommand
grabbing that high unless your source is of that quality. (and even then
that would create some pretty large files)

Oh I forgot about NTSC and PAL. I am on NTSC and I am not planning to
go to other countries for PAL. I guess 480x320 is it. I choosed 320x240
because my TV was small.
--
"Now I have you where I want you... where is my jar of Bull ants?"
--unknown
/\___/\
/ /\ /\ \ Ant @ The Ant Farm: http://antfarm.ma.cx
| |o o| | E-mail: (e-mail address removed) or (e-mail address removed)
\ _ / Remove ANT if replying by e-mail from a newsgroup.
( )

 

[Chimera]

You are not going to get a definitive answer on this!

Look here:
http://www.dvdrhelp.com/forum/userguides/94382.php

Seems that 480*384 is the recommended for PAL, 480 X 320 for NTSC.

ill second that. Analog TV has better broadcast resolution, but the average
TV has resolution marginally better than VCD.

 

[FLY135]

You are not going to get a definitive answer on this!

Look here:
http://www.dvdrhelp.com/forum/userguides/94382.php

Seems that 480*384 is the recommended for PAL, 480 X 320 for NTSC.

At first I thought you might be smoke'n crack but then I realized that you
must be smoke'n crack. Where in the H E double hockey sticks did you get
those numbers?

 

[Ben Pope]

At first I thought you might be smoke'n crack but then I realized that you
must be smoke'n crack. Where in the H E double hockey sticks did you get
those numbers?

"The suggested resolution from experts of DiVX/XviD/ASF are: PAL: 480 X 384,
NTSC: 480 X 320"

It's in the link. We're referring to the resolution to encode at... not the
broadcast resolution.

Ben

 

[FLY135]

"The suggested resolution from experts of DiVX/XviD/ASF are: PAL: 480 X 384,
NTSC: 480 X 320"

It's in the link. We're referring to the resolution to encode at... not the
broadcast resolution.

LOL, sorry I guess they are the one's smoke'n crack. NTSC has 480 visible
scan lines per frame. To encode 480 scan lines into 320 would be a total
cluster f**k. Somebody screwed up quoting the so-called experts. Likewise
with PAL.

 

[Ben Pope]

LOL, sorry I guess they are the one's smoke'n crack. NTSC has 480 visible
scan lines per frame. To encode 480 scan lines into 320 would be a total
cluster f**k. Somebody screwed up quoting the so-called experts.
Likewise with PAL.

Who says that all of the broadcast quality can be displayed on your TV?

Who says the all of the broadcast quality can even be decoded by the
receiving equipment?

Some questions for ya':

1) Would you class DVDs as higher quality than broadcast?

2) If so, would you say that there is no requirement to encode information
that is not there?

3) If so, would you suggest that encoding at full DVD resolution for a
signal degraded is superfluous?

4) If so, would you encode at a lower reolution than DVD?


Personally I answer YES to all of those questions.

DVD is 720*480.

480*320 is 33% reduction in resolution, which is probably roughly equivelent
to the loss of detail after broadcast.

Like I said, there is noe definitive answer, merely opinions.

Ben

 

[FLY135]

Some questions for ya':

1) Would you class DVDs as higher quality than broadcast?

No. Broadcast quality is pretty subjective. I have no idea if the output
of any particular DVD player meets the FCC requirements for broadcast
quality video. There is no question that component output on a DVD player
is higher bandwidth than NTSC. As is RS170A broadcast quality video. And
film sourced progressive DVD material has more detail, but less temporal
resolution than interlaced NTSC. Broadcast quality is not limited to NTSC
composite bandwidth and has less color quantization artifacts than DVD.

2) If so, would you say that there is no requirement to encode information
that is not there?

It's absolutely impossible to encode information "that is not there".

3) If so, would you suggest that encoding at full DVD resolution for a
signal degraded is superfluous?

If you have definitive information regarding what (or how much) can be
thrown away without a perceptable degradation of the image then use it.
Otherwise your best bet is to use the most resolution available to you. Or
run tests.

4) If so, would you encode at a lower reolution than DVD?

Yes, I would. It's not just a matter of losing resolution, but a tradeoff
between detail, file size, and artifacts. I take all of those into
consideration when encoding material.

Personally I answer YES to all of those questions.

DVD is 720*480.

480*320 is 33% reduction in resolution, which is probably roughly equivelent
to the loss of detail after broadcast.

Like I said, there is noe definitive answer, merely opinions.

This is a perfectly good example of why you shouldn't make decisions on
theoretical assumptions. Capturing and encoding 480 pixels on a scan line
is a good bet for getting plenty of detail while reducing artifacts.
However, capturing with a vertical resolution of 320 is a bad idea. If you
use anything less than 480 scan lines (for NTSC), then you will be losing
*both* spacial and temporal resolution that your TV is quite capable of
displaying. Capturing 320 scan lines requires both deinterlacing and
scaling, and you have no idea whether any particular capture card or
software is going to do a very good job of it. A blanket recommendation
saying that 320 scan lines is ideal is ridiculous and was probably never
recommended by any expert.

 

[Ben Pope]

This is a perfectly good example of why you shouldn't make decisions on
theoretical assumptions. Capturing and encoding 480 pixels on a scan line
is a good bet for getting plenty of detail while reducing artifacts.
However, capturing with a vertical resolution of 320 is a bad idea. If
you use anything less than 480 scan lines (for NTSC), then you will be
losing *both* spacial and temporal resolution that your TV is quite
capable of displaying. Capturing 320 scan lines requires both
deinterlacing and scaling, and you have no idea whether any particular
capture card or software is going to do a very good job of it. A blanket
recommendation saying that 320 scan lines is ideal is ridiculous and was
probably never recommended by any expert.

No, but you have to settle somewhere, and 480*320 is probably reasonable in
many cases.

I don't see how you lose temporal resolution by reducing spatial resolution
though.

Besides, I'm not here to discuss the technical ins and outs of video
encoding, merely to make a recommendation on a reasonable resolution to use,
in many cases. Encoding requires trade-offs. Some people rate quality
higher than others, they'll have differing opinions. Like I said, no
definitive answer - whatever I said, somebody would disagree, either on the
loss of quality or the space requirement..

It was a no-win situation.

Ben

 

[FLY135]

No, but you have to settle somewhere, and 480*320 is probably reasonable in
many cases.

No it isn't. You don't need to defend the 480x320 number since you weren't
the "expert" that made it. You would be better served by trying to
understand my argument against it so you understand why it is wrong. You
should capture with a vert res of either 480 or 240 (NTSC) depending on what
you are willing to give up.

I don't see how you lose temporal resolution by reducing spatial resolution
though.

Standard NTSC interlaced video produces 60 fields of 240 scan line video per
second. If you capture less than 480 scan lines per frame then you are
eliminating the 60 (unique in time) fields and only getting 30 frames per
second. This causes a loss of temporal resolution. The result is that the
video is jerkier then the original.

Besides, I'm not here to discuss the technical ins and outs of video
encoding, merely to make a recommendation on a reasonable resolution to use,
in many cases. Encoding requires trade-offs. Some people rate quality
higher than others, they'll have differing opinions. Like I said, no
definitive answer - whatever I said, somebody would disagree, either on the
loss of quality or the space requirement..

I agree that there is no definitive answer to how much *horizontal* res is
necessary to reproduce the original detail on any particular TV. However my
contention with the post you referenced is that the vertical res of 320 scan
lines is totally bogus. This isn't subjective. You need 480 scan lines to
reproduce what your TV can show. That's not to say that 240 lines can't be
an acceptable tradeoff. But 240 lines is NOT SUFFICIENT to support NTSC
without visible degradation. And that is what this discussion was about.
Also 480x320 is not even remotely a good recommendation. I would venture to
say that the number they meant was 320(h)x480(v). However that wouldn't
explain the 480x388 recommendation for PAL, which is also nonsense.
Following the same logic PAL would be 320(h)x576(v).

 

[Ben Pope]

No it isn't. You don't need to defend the 480x320 number since you
weren't the "expert" that made it. You would be better served by trying
to understand my argument against it so you understand why it is wrong.
You should capture with a vert res of either 480 or 240 (NTSC) depending
on what you are willing to give up.

OK, I'll engage brain... hold on a minute while it warms up and I attempt to
tune myself into DSP mode

Standard NTSC interlaced video produces 60 fields of 240 scan line video
per second. If you capture less than 480 scan lines per frame then you
are eliminating the 60 (unique in time) fields and only getting 30 frames
per second. This causes a loss of temporal resolution. The result is
that the video is jerkier then the original.

OK, I kinda see where you're going with that. But I still don't see the
difference. Am I wrong in assuming that you always de-interlace? Or do you
only de-interlace if wish to scale? (I'm also assuming the loss of temporal
resolution is a direct result of de-interlacing, which makes another
assumption, that in de-interlacing, you simply take two adjacent frames and
flatten them, in time, into one frame.)

Have you ever used DScaler? It was my understanding that it was pretty good
at these things.

Ben

 

[FLY135]

OK, I kinda see where you're going with that. But I still don't see the
difference. Am I wrong in assuming that you always de-interlace?

You should not deinterlace video that is intended to be played back on TV,
unless you are using capturing (or rendering from edits) at a lower res than
480 scan lines (of which 240 (for NTSC) is the only reasonable alternative).

Or do you
only de-interlace if wish to scale?

If you were to scale in the vertical, then you would need to deinterlace
first. Deinterlacing is useful for display on computer monitors.

(I'm also assuming the loss of temporal
resolution is a direct result of de-interlacing, which makes another
assumption, that in de-interlacing, you simply take two adjacent frames and
flatten them, in time, into one frame.)

Deinterlacing causes the loss of termporal resolution. Your last statement
should say...

"...in de-interlacing, you simply take two adjacent *fields* and flatten
them, in time, into one frame"

Have you ever used DScaler? It was my understanding that it was pretty good
at these things.

No I haven't used it. Most of the video I capture is either for TV
timeshifting or making a DVD from home videos. Neither of which requires
deinterlacing. I don't do much in the way of video production, but I do
embedded programming on hardware MPEG codecs as my regular job.

 

[Ben Pope]

You should not deinterlace video that is intended to be played back on TV,
unless you are using capturing (or rendering from edits) at a lower res
than 480 scan lines (of which 240 (for NTSC) is the only reasonable
alternative).
Right.


If you were to scale in the vertical, then you would need to deinterlace
first. Deinterlacing is useful for display on computer monitors.

Right, that makes your previous comments make sense (to me

Deinterlacing causes the loss of termporal resolution. Your last
statement should say...

"...in de-interlacing, you simply take two adjacent *fields* and flatten
them, in time, into one frame"

Right. Best get my terminology sorted

No I haven't used it. Most of the video I capture is either for TV
timeshifting or making a DVD from home videos. Neither of which requires
deinterlacing. I don't do much in the way of video production, but I do
embedded programming on hardware MPEG codecs as my regular job.

Cool. What microcontroller(s) do you use?

I quite like the whole embedded thing. My final year project (at Uni) was a
data capture system for a racing car which used CAN to connect multiple
micros together. I used Atmel CANary uCs (8051-based, I presume you use
something a bit beefier

Ben

 

[FLY135]

Cool. What microcontroller(s) do you use?

We currently use Atmel's ARM7TDMI based processors. I think the next
version will either use an ARM9 or PPC.

I quite like the whole embedded thing. My final year project (at Uni) was a
data capture system for a racing car which used CAN to connect multiple
micros together. I used Atmel CANary uCs (8051-based, I presume you use
something a bit beefier

I only did a small amount of embedded programming before I started this job
about 2 years ago. I really like embedded work because you don't have to
deal with so many black box software components (DirectShow for instance).
I have the complete source to the RTOS and TCP/IP stack, so if something
doesn't seem to work right I can trace into any part of the code.

 

[Ben Pope]

We currently use Atmel's ARM7TDMI based processors. I think the next
version will either use an ARM9 or PPC.

OK, quite a bit of grunt then.

I only did a small amount of embedded programming before I started this
job about 2 years ago. I really like embedded work because you don't
have to deal with so many black box software components (DirectShow for
instance). I have the complete source to the RTOS and TCP/IP stack, so if
something doesn't seem to work right I can trace into any part of the
code.

All the job vacancies I've seen for embedded stuff require lots of
experience... Oh well.

Thanks for the explanations.

Ben