LinHES Forums

Pauses every two seconds in live tv
Page 1 of 1

Author:  jared [ Tue Apr 12, 2005 8:08 pm ]
Post subject:  Pauses every two seconds in live tv

Hi all,

I've been getting pauses (or stutters?) every two seconds in both live tv and recorded shows, but only on a low end (K63-400 mhz) box. My laptop (1.8 mhz celeron) can play either stream fine, so I don't think it's a server or recording issue.

However, when I turn on the automatic transcode after recording option, the recorded shows don't gap at all... Even if we are watching the show while it's being recorded, it runs fine.

I'm clueless here... (and that applies on so many levels! ;) )

Any idea? TIA

Author:  cesman [ Tue Apr 12, 2005 8:11 pm ]
Post subject:  Re: Pauses every two seconds in live tv

jared wrote:
but only on a low end (K63-400 mhz) box.
I think you've answered your own question. Seeing as how you provided no further details, no one can really help you.

Author:  jared [ Tue Apr 12, 2005 8:19 pm ]
Post subject:  Why do you bother?

What additional information would you (or anyone else) like? Details are helpful. I provided what I thought was enough... feel free to enlighten me. ;)

The low end box plays the recorded shows fine. To me, that indicates that something within Myth is treating those recordings differently. Since I'm watching them live while they are being recorded, and the dialog indicate that the transcoding is done after the recording is completed, it doesn't seem to be related to stream content post-transcode... but maybe it transcodes on the fly? I'm wondering if anyone knows if Myth is treating these recordings differently, and if so, can I get the live tv to be handled the same way.

Author:  cesman [ Tue Apr 12, 2005 8:28 pm ]
Post subject: 

TV tuner card info would be helpful. When you watch live TV, you are encoding and decoding, this take more processing power than when you watch a recorded show. MythTV doesn't treat the files differently.

Author:  jared [ Tue Apr 12, 2005 8:42 pm ]
Post subject: 

Gotcha... hardware details. First, I am using separate frontend and backend boxes.

The mythbackend box is a 1.2 ghz AMD Thunderbird w/512 megs of memory. Primary hd is a 20, data is 200, both are 7200 rpm w/DMA turned on. Base system is Kubuntu w/Myth 0.17. ECS K7SA motherboard.. using onboard sound. The capture card is a ~really~ cheap Bt848 card. Avermedia WinTV. Card=27 for modprobe bttv purposes. CPU floats between 50 and 80% during capture.

Front end box is a K6-3 400mhz w/256 megs of memory. The video card is an Nvidia GeForce 4 480MX (a newer version of the 440). I think it's go 64 meg of memory, but it may have 128. The system is also Kubuntu but the same symptoms occur with a like KnoppMyth CD. The box stays at 80 to 90% cpu during playback.

Network: Server plugs into a 100 mb switch, then goes through a 100 mb router (in the switch ports), then to a 10 mb switch. Since it's 3 hops, I mention it, but the laptop I mentioned earlier plays the video fine on the network connection.

This box seemed to work fine w/0.16 but I only did "proof of concept" with it, but now we've replaced the Tivo, so we're looking at it much more.

If I turn the "automatically transcode" option off, everything being played (live or recorded) gaps. When Transcode automatically is on, the recorded shows don't gap.

Is it possible that the server is transcoding on the fly and the client box can more easily handle the stream (as it's half the size)? I use ~2 gigs an hour raw, then it transcodes (to MPEG4) to just under 1 gig an hour.

Author:  tjc [ Tue Apr 12, 2005 9:11 pm ]
Post subject: 

The problem with low spec machines that otherwise work for real-time applications like this usually ends up being missed deadlines. Rather like climbing rope it's not the average load that's an issue but rather the momentary peak load.

You can try turning up the buffering via the setup screens and aggressively "nice-ing" background processes like transcoding. However you may still find that the CPU doesn't have enough headroom to handle some transitory peak loads without maxing out. Basically, under heavy load it can't finish certain urgent tasks fast enough to get back to feeding smooth video.

Author:  jared [ Wed Apr 13, 2005 5:29 am ]
Post subject: 

so you're telling that the transcoding is taking place on the client machine, not the mythbackend machine? That doesn't sound right.

And you're also saying that watching a transcoded show (which requireds more work so more CPU) should gap more often. Since that's not the problem I described, I suspect it's something else.

Author:  cesman [ Wed Apr 13, 2005 11:10 am ]
Post subject: 

tjc and I are saying the same thing, your processor isn't powerful enough to watch live TV.

Author:  jared [ Wed Apr 13, 2005 1:19 pm ]
Post subject: 

tjc and I are saying the same thing, your processor isn't powerful enough to watch live TV

I understand your point.

What I am trying to understand how the data stream for a show that is marked to be transcoded is different than live tv. Does anyone know that?

Before you say they aren't different, they play back differently, so there is ~some~ difference.

Author:  brendan [ Wed Apr 13, 2005 2:25 pm ]
Post subject: 

Reading the current mythtv docs on the website, there should be no difference. Assuming it is up to date with the real behavior of 0.17, transcoding isn't supposed to happen until after the recording is finished.

I wonder if something very strange is happening such as: you get better live video on the slow frontend if the backend is currently performing a low priority transcode on a recently recorded program? That seems sorta silly though, but I've seen stranger things happen.

One more thing: have you set up the mythfrontend suid root on the slow machine? According to the output of mythfrontend, that can help sometimes, and it sounds like the hardware you're using is perhaps only a tad underpowered, so the suid thing might push you back into the land of acceptable performance.


Author:  jared [ Wed Apr 13, 2005 5:43 pm ]
Post subject: 

Thanks Brendan.

I also wondered if the extra load on the server machine was actually slowing something down enough for the lowly front-end box to handle it. Still seems odd though, but like you said, stranger things have happened.

And yes, I'm running myth w/sudo mythfronend.

What sorts of speeds are other people using for dedicated front-end boxes? I've got an Athlon 550 upstairs but it's use as a server box. I could swap them but it would mean a lot of work, especially if it's still not "fast enough".

Author:  tjc [ Wed Apr 13, 2005 7:10 pm ]
Post subject: 

It may seem counter-intuitive but a FE often needs more horsepower than a BE. This is especially true with a PVR card (Yes, I know you don't have one). Playback is more demanding about the amount of headroom it has because the destination device (the protoplasmic one wearing your skin) is quite sensitive to buffering delays, so you really can't miss your realtime deadlines.

When you're recording, if a momentary load spike happens it may not be an issue if you got some spare buffer space where the data can sit for a couple seconds. It's in a buffer, and it can be processed and dumped to the disk as soon as the CPU gets some spare cycles. If it goes in chunks nobody really cares just so long as things don't backup to the point that the buffers overflow.

Now, what I was trying to explain to you earlier was very closely related to this:

    - Playback is effectively a realtime streaming application with hard deadlines.

    - If the data to display the next frame isn't ready the display will "glitch" and not be smooth. This is the streaming part.

    - Meeting the deadlines means getting enough CPU cycles early enough in each time window (the period between displaying one frame and the next) to get that data ready and to the video card before the next frame has to be displayed.

    - The less free CPU you have and the slower the CPU clock is, the earlier in the window you absolutely positively have to get you cycles (with no interuptions) if you're going to make the deadline.

    - If your data arrives late for any reason (maybe because the back end is busy or the CPU didn't have enough free cycles to handle the network traffic) You can't start your processing for the current window.

    - If something else (another task, netowrk traffic, ...) is "distracting" the CPU during your window the deadline may not be met.

Author:  brendan [ Sat Apr 16, 2005 11:39 am ]
Post subject: 

jared wrote:
What I am trying to understand how the data stream for a show that is marked to be transcoded is different than live tv. Does anyone know that?

Before you say they aren't different, they play back differently, so there is ~some~ difference.

Looking through the changelog for the new MythTV .018 release, there are interesting comments re: a recent pair of changes:

April 9:
Fix - get rid of autotranscode for livetv
Fix - reenable autotranscode for livetv

So, there's always the chance that 0.17 was doing autotranscode on live TV too. However, it's not listed as a feature in any documenation that I've read.

Course I could be reading too much into that: those changes might only apply to boards without hardware decoders (not the PVR-xxx series) that require mythtv to perform an encoding step before writing video to disk.


Author:  jared [ Sat Apr 16, 2005 1:07 pm ]
Post subject: 

Thanks for the info Brendan. I've continued tinkering on this end.

The transcoding does appear to be running "realtime". My CPU on the client box can playback the MPG encoded streams smoothly, but gaps with RTJPEG or plain live TV. The gaps and quality of the stream make it very obvious which one I'm seeing. The server box uses about 60% of the CPU when recording w/o transcoding, but pegs the CPU when automatically transcode is checked.

I tried wiping the frontend box and installing KnoppMyth (instead of the Kubuntu I'd been using) to see if the performance would be better. I found it difficult to use. It was interesting that the install made no allowance for a front-end client. It assumes everything is running on the same box... not complaining mind you (it's a great distro!), but I had to dig the info out of the fourms on how to disable everything cleanly.

I also had trouble getting the native Nvidia drivers installed on the KnoppMyth version. I guess it's what version you know... anyway, X was ~very~ slow under KnoppMyth, so I probably wouldn't have kept it anyway, but the video gapped worse under KnoppMyth than it did under Kubuntu...

sooo.... :)

I used the KnoppMyth live CD to see how my Athlon 550 mhz did at video playback, and it looks to be fine. I am currently moving Tomcat, Apache, CVS, etc and so forth off of the Athlon and I'll setup it all back up on the 400mhz box, making it the server. Then the Athlon will get to be the Myth box.

More than you wanted to know? :)

I found a few posts in the forums that indicate you can run Myth w/slower hardware than my 400 mhz, but they seem to be watch recorded shows more than live TV.

Anyway, thanks for the helpful posts all! Despite all the noise, I think I've finally figured out what the streams were doing. If it we were only using the box to watch recorded content and we recorded it as MPEG, 400 mhz would have been fine, but it couldn't handle live TV.

Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group