[mythtv-users] High level system architecture questions

Michael T. Dean mtdean at thirdcontact.com
Thu May 26 04:38:41 UTC 2005


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


More information about the mythtv-users mailing list