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

  • Thread starter Thread starter ANTant
  • Start date Start date
A

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.
( )
 
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.
Click to expand...

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
 
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. :)
Click to expand...

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
 
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. :)
Click to expand...

Do it in 352x240. That way it will also be ready for vcd. (mpeg1)
 
You are not going to get a definitive answer on this!
Click to expand...
Look here:
http://www.dvdrhelp.com/forum/userguides/94382.php
Click to expand...
Seems that 480*384 is the recommended for PAL, 480 X 320 for NTSC.
Click to expand...
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)
Click to expand...

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.
( )
 
FLY135 said:
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?
Click to expand...


"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
 
Ben Pope said:
"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.
Click to expand...

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.
 
FLY135 said:
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.
Click to expand...


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
 
Ben Pope said:
Some questions for ya':

1) Would you class DVDs as higher quality than broadcast?
Click to expand...

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?
Click to expand...

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?
Click to expand...

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?
Click to expand...

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.
Click to expand...

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.
 
FLY135 said:
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.
Click to expand...

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
 
Ben Pope said:
No, but you have to settle somewhere, and 480*320 is probably reasonable in
many cases.
Click to expand...

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.
Click to expand...

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..
Click to expand...

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).
 
FLY135 said:
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.
Click to expand...

OK, I'll engage brain... hold on a minute while it warms up and I attempt to
tune myself into DSP mode :-P
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.
Click to expand...

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
 
Ben Pope said:
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?
Click to expand...

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?
Click to expand...

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.)
Click to expand...

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.
Click to expand...

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.
 
FLY135 said:
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.
Click to expand...

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"
Click to expand...

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.
Click to expand...

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
 
Ben Pope said:
Cool. What microcontroller(s) do you use?
Click to expand...

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 :-)
Click to expand...

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.
 
FLY135 said:
We currently use Atmel's ARM7TDMI based processors. I think the next
version will either use an ARM9 or PPC.
Click to expand...

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.
Click to expand...


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

Thanks for the explanations.

Ben
 
Back
Top