Ben Bargabus wrote:
Also--and probably more importantly--you lose much of the benefit of DVD.
This relates to another question I have. With a DTV receiver connected to the
backend is the output decoded by the receiver, encoded by the PVR-250, sent
across the network, and decoded by the PVR-350 in the frontend?
Basically, yes. However, any machine with a PVR-350 should be used as a
frontent/backend combo (since it has a tuner card and TV out). However,
with your stated goal of keeping all the satellite receivers in one
server room connected to dedicated backends, it doesn't make sense for
you to use PVR-350's. Buy PVR-250's (or PVR-150/PVR-500's once you get
comfortable with IvyTV--since they're newer and not as well supported at
this time) and get a good video card. That way, you get OpenGL support
for good Goom. (One of the visualizations in MythMusic--and, with my
pitiful collection of music, the only reason to use MythMusic. :)
Is this the only solution if the receiver is connected at the backend
(obviously the specific hardware could change but I'm talking about the decode,
encode, decode sequence)?
Yes. (Unless your receiver does digital output via firewire, then
there's only one decode.)
I'm well versed in computers but not very well in video so please excuse my
ignorance for a moment, is this because the output from the receiver is analog?
Yes.
(if it were digital it seems that it would be much easier to just divvy it up
into packets and send it on its way)
Yes. But TV has been analog since it's inception, so most standard
definition receivers output in analog. Now that we're moving to digital
TV (at least here in the US), the MPAA doesn't want you to be able to do
this, so we now have things like the broadcast flag, HDCP, HDMI, CPRM,
and D-VHS to stop all of us thieves (except, of course, the
insiders--like the one who released Star Wars, Episode 3, The Revenge of
the Sith onto the internet 6 hours before it opened in theaters ;).
With some receivers, you can pull a digital signal (generally MPEG-2
video) via firewire, but that's a whole different question...
Even if analog why not just a good ADC on one end and DAC on the other? Is
this a bandwidth/storage-capacity issue (and thus really relying on the
compression of MPEG)?
Yes. MPEG-2 compression allows the recording of TV at pretty good
quality at about 1.25GiB/hr (3 Mb/sec) including audio. However, many
people use higher bitrates for "better" quality, but DVD--which also
uses MPEG-2--maxes out at about 4.25GiB/hr (10.08Mb/sec according to the
spec) including video, audio, and subtitles). MPEG-4 can--in
theory--give the same quality as MPEG-2 with half the bitrate. Assuming
a 16-bit/pixel uncompressed format (like YUV or YUV2) at 720x480, a
one-hour recording will take about 70GiB/hr (166 Mb/sec) and a
24-bit/pixel format (like RGB24) would take about 105GiB/hr (~250Mb/sec)
not including audio. (I.e (720 * 480) pixels/frame * 30 frames/sec * X
bits/pixel = bitrate ) Now that's compression...
Note that:
1 GiB = 1024MiB = 1048576 KiB = 1073741824 bytes
(see http://physics.nist.gov/cuu/Units/binary.html )
1Mb = 1000 Kb = 1000000 bits
<snip>
Therefore, you will lose quality--even if you can't do progressive display with
your TV.
Is this noticeable? highly noticeable? Does this manifest as pixelation or
artifacts etc...
Interlacing artifacts usually include the "jaggies". Pixelation (or
blockiness) happens when recording with too high a resolution for a
given bitrate on a given scene. I'd say you'll notice more of a quality
loss from the decode-encode-decode cycle (which can, in fact, cause
blockiness--even with a sufficient bitrate--through the amplification of
the quality loss in the original MPEG encoding) than from the loss of
progressive output. However, it's quite possible that even the
decode-encode-decode cycle won't make a noticeable difference. The best
way to decide is to see it yourself (and try not to let your
preconceptions cloud your perspective).
And, finally, there's the annoyance factor... Since Myth would treat the DVD playback as just
another "LiveTV" channel, it would buffer it (to allow you to pause, rewind, etc.).
Therefore, there would be a couple of seconds of delay between the time you pushed a button on your
DVD remote until it "took" (i.e. when navigating DVD menus).
Does this also apply to changing channels on "live" TV? For example, I change
the channel on my DTV receiver connected to the backend of my system, do I now wait
several seconds for the content to appear? That seems like an unacceptable delay, if I
were surfing through channels and each press of the channel changer took several seconds
to respond.
Yes. However, not many people who use MythTV watch LiveTV. (I'm Mike
Dean and I haven't surfed channels in 15 months! Hi, Mike!) Those who
do watch LiveTV get used to changing channels through the program guide.
In general, though, once you have your recording schedules set up
properly, you'll find that you record anything and everything you might
possibly want to watch. Then, when you have some time to watch TV,
instead of watching "what's on now," you'll be able to choose what to
watch from your array of recordings. You might watch some LiveTV for
sports, but typically, setting up a recording offers you the benefit of
not having to remember/be home to start MythTV's LiveTV when the game
starts (and you can start watching the recording even while it's still
recording) and you don't have to worry about running out of LiveTV
buffer when you get interrupted and have to pause the game.
(Note that Myth has no provisions for piping data directly to TV without a
buffer, and there
are no plans to add this functionality.)
Is this open source?
Yes. GPL2.
What language is it written in?
C++ using QT.
If I get energetic enough I may fix that. (I'm a programmer)
I recommend discussing your plan with the Myth devs (note that I'm not
one of them) before starting, to ensure that you choose an approach that
they would be willing to incorporate. Many of the past requests for
unbuffered TV have resulted in responses to the effect of, "Use xawtv
for that. Myth is a PVR." (Disclaimer: I am not trying to start a
flame war. I am not trying to speak for the devs. I am not trying to
twist the meaning of any dev's words. These responses may have simply
been because the requestor was not offerring to do the work, or I may
have misinterpreted them. You can see the unadulterated responses on
the MythTV ML archive at http://www.gossamer-threads.com/lists/mythtv/
. Search on "delay" or "change channels buffer" (no quotes) or ...)
Note, also, that you may have additional delays that you cannot fix.
For example, the only way for my Myth box to communicate with my
satellite receivers is via an IR signal (all Dish network receivers are
this way, but some DIRECTV receivers have a serial port). Therefore, I
have a script that sends a channel change to the Dish receiver by taking
the channel number as an argument and sending each digit and following
the last one with a select (#digits + 1 keys). I'm using the "low"
numbers for the channels (i.e. the same ones used for broadcast TV)
instead of the 8000's numbers so I have 2 digits for all of them except
4 of my 13 channels. The IR receiver on the satellite receiver requires
an explicit delay for a reliable channel change, so--through trial and
error--I adjusted the values to find the lowest value that always
worked. I ended up with 0.4 seconds. So, changing channels on the
satellite receiver typically takes 1.2 seconds--even after factoring out
the buffering done by Myth. With 3-digit channels, it takes 1.6
seconds; and with 4-digit channels, it takes 2.0 seconds. (Note that
even in LiveTV, Myth takes the full channel number and /then/ sends it
to your change channel script, so this isn't covered up by slow human
interaction.)
Oh, and BTW, the "use xawtv" comment is not really meant to be useless.
It can even be done with Myth using the EXECTV functionality in the
menus (basically, create a button that launches xawtv and tells Myth the
tuner is in use). That being said, the PVR-x50's have their own
internal buffer (mine delays TV by about 1-2 seconds when used from the
command-line with a PVR-350). Note that there is a passthrough mode for
the PVR-350 (I think it's pretty well working, now), but I haven't
played with it at all, so I don't know if there's any delay with it.
However, *any* method of having passthrough (built into Myth or xawtv
through EXECTV) is going to require the tuner card to be local to the
frontend (i.e. a frontend/backend combo)--which doesn't fit with your
plan. Using separate backends and frontends requires compressing the
video (as described above), which means you can't use the PVR-350's
passthrough mode (especially since it would try to output to the "TV" in
the server room), so--ignoring any other delays--you'd at least have the
delay imposed by the PVR-x50's buffer.
Thank you for your response, I look forward to your further feedback,
I'm sure you'll tire of my long responses soon enough. ;)
Best of luck,
Mike
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
