Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Dropping frames during playback, processor usage only at 15% Goto page Previous  1, 2
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Tue Mar 08, 2005 9:22 pm Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Thanks for the feedback, maestro. I tried it on 4 computers now (all of them fairly powerful machines, some Windows, one Linux, even one Xeon machine: all of them skipped at various places (slightly) during playback. They skipped at slightly different places each time I played it (still confused by that one). But none of the processors were pegged, and none of the machines had anything else significant running on them. All of them had Nvidia video cards, though. So that is interesting that it didn't skip or studder on an ATI card. Maybe I should try it on an ATI card. When I pulled out the main stream (tsprog=0) and coverted (not transcoded, just extracted the MPEG stream) it to a .m2v file with no audio, it didn't skip near as much as it did with the original .ts file. I don't know why that would be. I shall not give up!!! Very Happy I really appreciate the feedback!

Out of curiousity...is your Pentium M the one with the 2MB L2 cache?
View user's profile Send private message
PostPosted: Wed Mar 09, 2005 7:36 am Reply with quote
maestro
 
Joined: 10 Jul 2004
Posts: 18




bmhowe wrote:
Out of curiousity...is your Pentium M the one with the 2MB L2 cache?


No, it definitely only has 512KB. The video isn't long enough to test if it was running at the full 2.0GHz, or if it was slowed to 1.2GHz (as it displays currently). CPU was about 40%-50% during playback.
View user's profile Send private message
PostPosted: Wed Mar 09, 2005 12:58 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Anonymous wrote:
When I ran xine --verbose=8, it didn't say anything about dropped frames (past the initial startup), but it is clear that they are getting dropped somewhere.

Then I don't see how this could be a problem at the software level. Either xine displays the frame, or it drops the frame, or it skips the frame and verbose=8 will always tell you if a frame has been dropped or skipped.

Does your /dev/rtc have permissions set correctly so xine can open it?
View user's profile Send private message
PostPosted: Wed Mar 09, 2005 1:15 pm Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Quote:
Then I don't see how this could be a problem at the software level. Either xine displays the frame, or it drops the frame, or it skips the frame and verbose=8 will always tell you if a frame has been dropped or skipped.

Does your /dev/rtc have permissions set correctly so xine can open it?


I'm not at the machine right now, but I know that I have set /dev/rtc's permissions manually before to enable world read access.

With the file that I posted on my website (mentioned in a previous) post, mplayer claims that it is not dropping any frames either, so I do believe that xine and mplayer think they are playing it correctly, but I know they are not. For kicks, I tried the .ts file that is posted in the "Downloads" section on this website, and it, too, is jumpy on multiple machines (not the hi-def stream, the tsprog 1 stream).

(More stream of conciousness writing...)

Last night, when I was watching shows that I had recorded previously recorded (Amazing Race, specifically -- not HiDef), I noticed that it is smooth for 1-2 seconds, then jumpy for 1-2 seconds (i.e., drops to roughly 10FPS), and the process repeats for just about the entire show (I will post a clip tonight). It seems like a buffer somewhere (probably low-level buffer since mplayer and xine don't know about it) is filling up, dropping frames, and then flushing itself to make room for more data. I find it odd, though, that every machine that I play these .ts files on, is choppy. What is everybody else doing that I am not? Do I need to enable double/triple buffering somewhere for the video cards? I just wish I could find a log message of some sort that admits that frames are being dropped! Other people that I show these clips to admit that frames are being dropped, so it's not just me being picky. Hmm.... (actually more like "Arghhh...." now) Confused
View user's profile Send private message
PostPosted: Thu Mar 10, 2005 11:46 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I looked at the code yesterday and I couldn't find a way for xine to think it displayed a frame when it didn't unless the hardware/device driver is saying it displayed a frame when it didn't.

If it's jumpy, it may actually be displaying all the frames but not smoothly enough for you to see them all. That could indicate a different kind of problem like /dev/rtc not working.

One more thing... try playing these streams in slow motion using the down key in xine. Are all the frames there? Do any of them look broken?
View user's profile Send private message
PostPosted: Fri Mar 11, 2005 7:24 am Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Quote:
If it's jumpy, it may actually be displaying all the frames but not smoothly enough for you to see them all. That could indicate a different kind of problem like /dev/rtc not working.

One more thing... try playing these streams in slow motion using the down key in xine. Are all the frames there? Do any of them look broken?


I ran a simple test of /dev/rtc (http://www.risacher.org/yopy/rtc-test.c), and it appeared to be working as it should.

When I tried playing the frames one at a time, all the frames looked good.

I tried messing with the IRQs yeseterday, but to no avail. That is, I tried disabling the serial ports, parallel ports, USB, onboard sound, and network card in BIOS. Then I pulled out the HD-3000 capture card, so that the only thing in the system was the video card....it was still choppy. Sad

I'm thinking this has to be some sort of hardware/driver issue, like you mentioned above, Scott. But I tried to putting my hard drive into my dad's computer (nForce2 chipset, too, with a GeForce Ti 4200), and it was choppy there, too. Could it be that there is a problem with the nForce2 chipset w/ Linux?

My main goal right now is to find a debug message somewhere that indicates how many frames are being dropped. Once I do that, then I can find out why they are being dropped.

Is it possible to use the xv or vesa drivers in Mythtv instead of the nvidia driver? At least those are open source, so maybe I could do some debugging. I tried using xv, but got a black screen when trying to watch any tv or recordings.
View user's profile Send private message
PostPosted: Fri Mar 11, 2005 10:04 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




xv relies on the Nvidia driver too so that gets you nothing. I don't know about vesa. You can try using the open source Nvidia driver (I think you just change the Driver from "nvidia" to "nv" in your XConfig file) but I don't think that even support xv. At this point I wouldn't bother doing any testing with Myth since you're also haivng the problem with xine. xine is much easier to debug.

Are you saying that xine -V xv gives you a blank screen? That means something is terribly wrong. What options are you running xine with?

I'll say it again: the --verbose=8 option will tell you how many frames it is dropping and skipping. I use it all the time. To prove this, start xine with it and do some things to give xine a hard time, like moving the mouse around, switching windows, starting a big application and so on. Every 200 frames xine will tell you it's not doing a very good job.

I vaguely remember someone having a problem like this and it was a problem with a specific kind of disk drive.
View user's profile Send private message
PostPosted: Fri Mar 11, 2005 10:25 am Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Sorry, I meant nv, not xv. I'm gonna try that this weekend. You're correct that I shouldn't do any testing in myth.

Quote:
Are you saying that xine -V xv gives you a blank screen? That means something is terribly wrong. What options are you running xine with?


Sorry, I meant that when I am using the nv driver, I get a blank screen when trying to watch tv in myth, but I don't remember if I tried xine or mplayer when I had tried that. Will try that.

I have seen both xine and mplayer admit that they've skipped frames before, so I know what to look for: it just doesn't admit it as often as it is actually happening.

I can feel that I am getting closer to the problem...I think that the fact that the studdering is periodic (roughly every 3 seconds) should tell me something. When I get home today, I'm going to go through every process that is running and see if there is any possibility that that process is blocking interrupts. I read today (http://tvtime.sourceforge.net/problems.html) that sometimes the apm driver in linux will block interrupts when reading the battery info from apm, but obviously, my system isn't a laptop, so it should be running this, but I wonder if there is something similar that is happening.

Must.....not........give........up!
View user's profile Send private message
PostPosted: Fri Mar 11, 2005 11:28 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Good, that's what should happen when you use the nv driver. Smile

Are you running mplayer with the -cache option? I set it to 4096 to 8192. Have you tried increasing xine's cache (it's somewhere in the menus)? Using a pretty big cache has solved some studdering problems I've had in the past.
View user's profile Send private message
PostPosted: Fri Mar 11, 2005 8:25 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




OK I found another thing to check -- what is the vertical refresh of the monitor you're using? If it's not 60hz then there's a problem with getting 30/60 fps streams to display smoothly because the player will want to display frames when the hardware won't be able to. It shouldn't cause the huge studdering you're seeing but it couldn't be helping.
View user's profile Send private message
PostPosted: Sat Mar 12, 2005 4:37 pm Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Very Happy Very Happy Very Happy Very Happy Very Happy

OK I don't want to jump the gun, but I think the problem is solved!!! Upon startup, my distribution (KnoppMyth R5A10) started a program called "dbus-daemon-1". I don't know exactly what this program is, but once I killed it, the video is smooth! According to the man page, it appears to be a messaging API/library/daemon that allows applications to communicate in a point-to-point fashion. I don't think that Myth is using it, so I don't know why it was set to run, but once I stopped it, video is smooth!!!!!!!!!!!!!!! I've only tested for a few minutes, but so far so good! I will keep everybody posted in the next few days.

Very Happy

(Now I can start sleeping at night again) Laughing
View user's profile Send private message
PostPosted: Sat Mar 12, 2005 8:49 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I uh thought you said you had killed everything off. Confused

I uh thought you said you had tried this on four different machines. Confused
View user's profile Send private message
PostPosted: Sat Mar 12, 2005 9:46 pm Reply with quote
bmhowe
 
Joined: 03 Mar 2005
Posts: 14




Well, after further investigation, killing the dbus program didn't actually fix it...it was something else that I had done. (I had killed all the unnecessary programs that were using even 0.1% of CPU.) I switched to a DVI cable instead of the VGA cable (both from the same video card). I had forgotten I had done that when I first noticed that the video was smooth. I didn't think a VGA cable could cause studdering video problems, even with a noisy cable, but apparently with my video card it did.

I had tried a small video clip on four different machines (and different O/S's), and that clip is still slightly jumpy...don't know why, but when using the DVI port instead of the VGA port on my HTPC, all is good, so I will continue to try to find out why it was jumpy on the other Windows machines and keep you posted. Something that was different, though, on my HTPC: the jumpiness was periodic; that is, it studdered every 2-3 seconds. But on the other machines, it was mainly jumpy in a certain spot that I was watching; that is, I don't think it was periodic jumpiness.
View user's profile Send private message
Dropping frames during playback, processor usage only at 15%
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 2 of 2  
Goto page Previous  1, 2
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin