Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Real 59.94 fields per second 1080i Goto page Previous  1, 2, 3, 4, 5  Next
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Tue Aug 15, 2006 5:41 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Scott Larson wrote:

I'm using version 4496 from way back in 2003. I've never been able to get any other version to work. I'll load the new driver, my display will say "unsupported resolution" or something. I'll go back to 4496 and everything's fine.

The modeline is:
1368x768_60.00" 85.86 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync


Thank you for the modeline Smile

So, I assume recent drivers accept your modeline but somehow they output it in a different way that your display doesn't like. Great... Sad

Anyway, I got your modeline working with my desktop's TFT. Making the 4496 driver work was a bit hard. I also had that version still lying around my disk, but it was patched for an old 2.6 kernel. I wasn't able to compile that driver with recent 2.6 kernels (the usual os-agp.c errors...). I used to get the patches from minion.de, but the site is now gone.
Went back to kernel 2.4.33 and found out that a 6600 GT cannot work with that driver (X doesn't even start). Replaced the 6600 GT with a FX 5200 and now X starts.
Finally, I ran a few interlaced clips with the modified mplayer and... no more cpu struggling. CPU usage is now in the range of 30%-60%, but... a very significant number of fields are dropped.
I rechecked everything... ahh, the "queue" xvmc suboption was missing. After running the clips again, cpu is now in the range of 30%-42% and no fields are dropped. Good.
Another interesting thing is the mplayer's status line. It reports 45% for decoding and another 45% for video output.
BTW, using a sleep before flip page only made things worse.
Very interesting.

So, now I would like to know if you're using a 2.4 kernel or a 2.6. If you're using 2.6, it would be great to know how to patch it.

Quote:

Well mplayer supports lots of things from the command line. I think he may have been talking about making mplayer do this by default for truly interlaced content but it's not clear.


I understand. Some things have to be done automatically, otherwise it would be a nightmare having to set specific command lines to each file. Not an easy thing to do from the couch. Smile

Quote:

Insulting their knowledge doesn't promote a positive work environment and I don't think it encourages people to work on open source projects.


Agreed.
View user's profile Send private message
PostPosted: Tue Aug 15, 2006 12:16 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I'm condemned to a 2.4 kernel as long as Nvidia's 2.6-compatible drivers are broken. It could be that Nvidia's recent X servers are ignoring the IgnoreEDID line (I have one of those Sharp displays that won't admit they display 1366x768 in the EDID data). I think I've gotten them to work at lower resolutions but they don't look very good. I'm also condemned to older Nvidia cards which is fine because my FX5200 card works great and doesn't have a fan.

It looks like you've reproduced everything I see on my system with its old kernel, old driver and old Nvidia board. I'm guessing Nvidia did put a spinlock on the vertical refresh wait in the more recent versions of their driver. I'm also guessing putting a sleep before the second field display doesn't work well with the old driver because you have two events to schedule (your sleep and the driver's vertical scan) and by the time the second event gets scheduled, it's too late to display the second field.

Spinlocking on vertical refresh seems crazy to me. I have my scheduler going at a thousand times a second so unless the driver monopolizes the CPU until vertical refresh happens (!), the spinlocking code is being preempted many many times. Maybe they have some "spin, sleep, and spin some more" algorithm or something. We have to remember that these drivers are tuned for playing video games, not for Internet browsing while watching HDTV in the background.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 3:14 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Scott Larson wrote:
I'm condemned to a 2.4 kernel as long as Nvidia's 2.6-compatible drivers are broken. It could be that Nvidia's recent X servers are ignoring the IgnoreEDID line (I have one of those Sharp displays that won't admit they display 1366x768 in the EDID data).


You probably know this already, but have you tried using "UseEDID" ? Recent nvidia's readme.txt state :

NVIDIA-Linux-x86-1.0-8762 Readme wrote:

Option "IgnoreEDID" "boolean"

This option is deprecated, and no longer affects behavior of the X
driver.
See the "UseEDID" option for details.



Also, I believe any old NVidia's driver can be made 2.6 compatible, given enough changes in os-agp.c and the likes. I used 4496 with old 2.6 kernels for very long. No problems whatsoever. It should not be hard to make 4496 compatible with 2.6.17.

Oh well, seems like the next thing for me to do is try other versions after 4496 and find out where the spinlock is being used. For now I'll use a 2.4 kernel. Work, work... *sigh*

Thanks.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 9:47 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




ubikdood wrote:
You probably know this already, but have you tried using "UseEDID" ?

Uh, well, I guess I'll have to see if that's the option I'm using when I get home. I didn't see any "IgnoreEDID deprecated" messages in the log but maybe I shouldn't count on Nvidia helping me out like that. Embarassed

The first driver that failed for me was 5328 and its README says "IgnoreEDID" was still supported. According to the README's this option wasn't deprecated until 8756, literally years after I had given up on trying to get new versions of their driver to work.
View user's profile Send private message
PostPosted: Wed Aug 16, 2006 11:21 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Wow, I'm actually using the latest Nvidia driver. By trial and error I discovered that instead of adding a "UseEDID false" line, I had to add a few other things:

Code:
Option   "FlatPanelProperties" "Scaling = native"
Option   "ExactModeTimingsDVI" "true"
Option   "ModeValidation" "NoEdidDFPMaxSizeCheck, NoEdidMaxPClkCheck, NoMaxPClkCheck, NoHorizSyncCheck, NoVertRefreshCheck, NoEdidDFPMaxSizeCheck, NoEdidModes"


Now that I'm using the same driver as everyone else, yes, I do see that odd sawtooth CPU usage pattern where it hits 100%, slowly backs off over several seconds, then goes straight back to 100%. It's the same with 720p sources too. It's extremely annoyng. Perhaps this is just because I'm using an older card.

I may stick with this driver because it may solve other occasional problems I have. Sometimes XvMCPutSurface() never returns and goes into an infinite loop in the driver. Sometimes the screen turns into a mosaic of green and purple blocks. And I still do have the dreaded "blue screen" problem when the overlay stops working.
View user's profile Send private message
PostPosted: Thu Aug 17, 2006 2:35 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Scott Larson wrote:
Now that I'm using the same driver as everyone else, yes, I do see that odd sawtooth CPU usage pattern where it hits 100%, slowly backs off over several seconds, then goes straight back to 100%. It's the same with 720p sources too. It's extremely annoyng. Perhaps this is just because I'm using an older card.


Aha ! Good to know you did it ! Smile
Now, the saw tooth can be due to an older card, or it can be the driver's fault. I saw the sawtooth effect both with a 5200 and a 5500. For me, it's out of the question to solve this issue just by replacing the FX 5500 with a 6600 GT on the HTPC because it's a lot noisier and generates a lot of heat.
Next weekend I will try several nVidia driver versions and see where the "sleeplock" (?) became a "spinlock".


Quote:
And I still do have the dreaded "blue screen" problem when the overlay stops working.


Hmmm. I saw that once too. And with some cards I have a pesky blue line at the top of the image. I would like you to try this (in your .xinitrc, or equivalent) :

Code:

# Get rid of the pesky blue line at the top of the image...
/usr/local/bin/xvattr -a XV_COLORKEY -v 0


You may get xvattr from here, if you need it :
http://freshmeat.net/projects/xvattr/

Good luck.
View user's profile Send private message
PostPosted: Thu Aug 17, 2006 9:45 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I don't have a blue line problem so I don't know what I should be looking for when running that command.

The blue screen problem is when, due to some timing problem, the overlay simply stops working and all you get is the blue screen in its place. In older versions of the driver (or maybe older cards like the 4400) you would have to reboot to get Xv and XvMC working again. At some point they improved it so restarting X would be enough to reset the card.

The green/purple mosaic problem and the XvMCPutSurface() infinite loop problem only require restarting the player. Much less annoying but it doesn't impress people who come over to watch a movie. These also seem to be timing problems since they happen mostly when other X applications are drawing to the screen.

Unfortunately I've found a serious problem with this driver. While the driver was burning up the CPU, I ran a couple of CPU-intensive gimp functions. It always caused mplayer to crash with this:

Code:
vo_xvmc: no free surfaces, this should not happen in g1
vo_xvmc: surface[0].state=3
vo_xvmc: surface[1].state=0
vo_xvmc: surface[2].state=0
vo_xvmc: surface[3].state=0
vo_xvmc: surface[4].state=1
vo_xvmc: surface[5].state=2
vo_xvmc: surface[6].state=1
vo_xvmc: surface[7].state=1
vo_xvmc: get_image failed
Only buffers allocated by vo_xvmc allowed
mplayer: vd_ffmpeg.c:1023: mc_get_buffer: Assertion `0' failed.
 
 
MPlayer interrupted by signal 6 in module: decode_video
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We
can't and
  won't help unless you provide this information when reporting a
possible bug.
vo_xvmc::uninit surface_render[0].status=1
vo_xvmc::uninit surface_render[4].status=1
vo_xvmc::uninit surface_render[7].status=1
alsa-uninit: pcm closed
bash-2.05b$


This happens with queuing both on and off.

There might be a bug in mplayer. The find_free_surface() function doesn't quite make sense to me. It could accidentally return a surface that's rendering (XVMC_RENDERING) since it only checks for the XVMC_DISPLAYING flag to see if it's free, and it's odd that mplayer tries to keep track of the statuses of surfaces on its own when its knows they aren't always accurate. I guess this is to reduce the number of XvMCGetSurfaceStatus() calls, yet it still has to call XvMCGetSurfaceStatus() eventually to make sure its own status is correct. Since some of the unfree surfaces have state==0 in this error message, obviously mplayer's surface state isn't always the same as its XvMC status.

The loop in find_free_surface() looks like exactly the kind of code that could cause sawtooth CPU usage. On my system at least mplayer is obviously having trouble finding free surfaces at times. That would make the code fall into the active loop that waits for a surface to free by continuously calling XvMCGetSurfaceStatus() (with a short sleep). I'm guessing that when there are lots of free surfaces, we don't see much CPU usage. Once free surfaces become scarce, that active loop runs more and more often until we see a peak in CPU usage. Once the surfaces start freeing up, CPU usage goes down again.

I also don't know why the code picks the last surface in the array to actively loop on. Checking through the entire array of surfaces for a free one makes more sense to me since it seems like any surface could free up at any time. Perhaps the author forgot a pair of braces and meant to loop on the last surface with state==0. [EDIT: I see now that it's testing for state==0 and skipping the return if the surface is XVMC_DISPLAYING so it does loop on a surface with state==0. But still, why check just that one surface in the loop instead of all surfaces with state==0 in the array?]

If there isn't a way to fix mplayer, well, this isn't going to work since I use the computer for other things while watching TV and I can't have it crashing all the time.
View user's profile Send private message
PostPosted: Fri Aug 18, 2006 2:32 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Scott Larson wrote:
I don't have a blue line problem so I don't know what I should be looking for when running that command.


Depends on the hardware. If you're not experiencing it, never mind.

Scott Larson wrote:

The blue screen problem is when, due to some timing problem, the overlay simply stops working and all you get is the blue screen in its place. In older versions of the driver (or maybe older cards like the 4400) you would have to reboot to get Xv and XvMC working again. At some point they improved it so restarting X would be enough to reset the card.


That used to happen to me with old versions of the nvidia driver (can't remember exactly which version was it). It's very embarrassing.
It's strange that it happens to you with the recent driver (8762, right ?). I've been using 8762 with my 5500 for quite some time now, and what you're experiencing never happened with this version. The only difference being is that I'm using a 2.6 kernel... Or maybe it's simply because I never stress-tested it like you did. :-\

Quote:

I also don't know why the code picks the last surface in the array to actively loop on. Checking through the entire array of surfaces for a free one makes more sense to me since it seems like any surface could free up at any time. Perhaps the author forgot a pair of braces and meant to loop on the last surface with state==0. [EDIT: I see now that it's testing for state==0 and skipping the return if the surface is XVMC_DISPLAYING so it does loop on a surface with state==0. But still, why check just that one surface in the loop instead of all surfaces with state==0 in the array?]


There should be some obscure motive for the author using the last surface. Without comments, it's really hard to know.
Anyway, the array of surfaces is used only when the "queue" suboption is specified (correct me if I'm wrong), so I don't understand why do you get that error even with queue switched off...
View user's profile Send private message
PostPosted: Fri Aug 18, 2006 9:49 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I never said the blue screen problem was happening with the 8762 driver. I've only been running it for a little over a day. So far I've had none of the problems I've mentioned but it's way too early to tell.

I changed find_frree_surface() to check all surfaces when it starts looping and now it's not crashing any more at least. It doesn't improve performance. mplayer is certainly having a much harder time finding free surfaces with this version of the driver. There is another array called show_queue that appears to be kept in chronological display order so maybe that's what the author thought he was using.

This increased CPU usage is terribly confusing. Sometimes I can't get it to display anything without dropping frames. Other times it will displaly the same content perfectly with only 30% CPU, then go back to 100% CPU for no apparent reason. This makes displaying the second field impossible.

There is a huge increase in the CPU the X server uses and that seems to be coming from mplayer's text output! Try running mplayer > /dev/null or minimize its window and watch the CPU usage drop! It nearly goes to normal and makes mplayer usable again. Perhaps this is all caused by changes in the X server Nvidia made.
View user's profile Send private message
PostPosted: Sat Aug 19, 2006 10:10 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Just finished testing several nvidia drivers. Interesting results.

Code:

Card : GeForce FX 5500
Software : MPlayer 1.0-pre8-bobdeint
Clip : MPEG2 1920x1080 29.970 fps, all frames interlaced, avg. bitrate aprox. 14 MBit
Xorg Modeline "1024x768@59.94" 64.93 1024 1048 1184 1344 768 771 777 806 -vsync -hsync


Command line :
                TIME="real %e\nuser %U\nsys %S\npct %P" time \
                /inc/build/video-stuff/MPlayer-1.0pre8-bobdeint/mplayer \
                -ao oss -monitoraspect 16:9 -fs -vo xvmc:queue
                -vc ffmpeg12mc part2.ts

Driver  | Kernel  | MPlayer | fields | NOTES
Version | Version | avg.CPU | drop'd |
--------+---------+---------+--------+--------------------
4496    | 2.4.33  | 56      | 83     | 3 frames dropped, constant cpu usage
5336    | 2.4.33  | 56      | 76     | 7 frames dropped, constant cpu usage
6629    | 2.4.33  | 31      | 0      | constant cpu usage
7167    | 2.4.33  | 31      | 0      | constant cpu usage
7174    | 2.4.33  | 31      | 0      | constant cpu usage
7184    | 2.4.33  | 31      | 0      | constant cpu usage
7184    | 2.6.17  | 34      | 0      | constant cpu usage *
7664    | 2.4.33  | 31      | 0      | constant cpu usage
7667    | 2.4.33  | 31      | 5      | constant cpu usage
7676    | 2.4.33  | 31      | 0      | constant cpu usage
7676    | 2.6.17  | 35      | 0      | constant cpu usage *
8174    | 2.4.33  | 43      | 0      | growing cpu, maxed at 100% (due to X)
8178    | 2.4.33  | 43      | 0      | growing cpu, maxed at 100% (due to X)
8756    | 2.4.33  | 43      | 0      | growing cpu, maxed at 100% (due to X)
8762    | 2.4.33  | 43      | 0      | growing cpu, maxed at 100% (due to X)
8774    | 2.4.33  | 43      | 0      | growing cpu, maxed at 100% (due to X)
8774    | 2.6.17  | 35      | 0      | growing cpu. maxed at 100% (due to X)

* - Motion looks smoother with 2.6 kernel



The numbers speak for themselves. I hope this helps you on picking a good driver version.
BTW, your change in the surface loop would be most welcome. Smile

EDIT:
Also, making driver 7676 compile with kernel 2.6.17 (vanilla, from www.kernel.org) was not very hard. Just modify Makefile.kbuild and add this in row 78:

Code:

EXTRA_CFLAGS += -DNV_SIGNAL_STRUCT_RLIM -DNV_PCI_GET_CLASS_PRESENT -DNV_REMAP_PFN_RANGE_PRESENT


EDIT 2:
Although enabled to perform the above tests, the XvMC suboption "queue" is not mandatory to achieve a low and constant cpu usage when using nvidia's 7xxx drivers.


Last edited by ubikdood on Mon Sep 11, 2006 3:12 am; edited 5 times in total
View user's profile Send private message
PostPosted: Sat Aug 19, 2006 2:49 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Did you confirm that the X server CPU usage was due to the mplayer text output?
View user's profile Send private message
PostPosted: Sun Aug 20, 2006 12:56 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




This driver still gives me the problem where the screen suddenly turns into green and pink squares so that's not fixed.
View user's profile Send private message
PostPosted: Sun Aug 20, 2006 9:31 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




And the XvMCPutSurface() infinite loop problem still happens. This driver isn't really any better for me than the one I was using from 2004.

Oh, they did fix a DPMS problem so now my monitor turns off instead of suspending.
View user's profile Send private message
PostPosted: Mon Aug 21, 2006 2:28 am Reply with quote
ubikdood
 
Joined: 24 Jan 2006
Posts: 18




Scott Larson wrote:
Did you confirm that the X server CPU usage was due to the mplayer text output?


I completely forgot to test redirecting mplayer output to /dev/null.
However, I believe that it's very unlikely that mplayer's output is causing the saw-tooth effect. Usually, when I run mplayer I do it either from mythtv (which has mplayer output redirected to a shell withou tty) or from a remote terminal (using ssh). Anyway, I shall test that also.

Quote:

This driver still gives me the problem where the screen suddenly turns into green and pink squares so that's not fixed.


Quote:

And the XvMCPutSurface() infinite loop problem still happens. This driver isn't really any better for me than the one I was using from 2004.


Sorry, I'm confused here. Which driver version are you talking about ?
Have you ever read about other people experiencing green and pink squares ? Starts to sound like a hardware malfunction.
View user's profile Send private message
PostPosted: Mon Aug 21, 2006 8:57 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I guess Mythtv would redirect mplayer's output for you. I don't see any sawtooth CPU usage now that mplayer's output isn't going to the screen. Before I did that I would see seemingly random amounts of CPU usage depending on what other X applications were running.

I'm talking about the 4496 driver I was using before. These problems sounded like hardware to me too so I bought an FX5500. I had the exact same problems with it too so I put the quieter FX5200 back in. It still could be a motherboard problem or who knows what else.
View user's profile Send private message
Real 59.94 fields per second 1080i
  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 3 of 5  
Goto page Previous  1, 2, 3, 4, 5  Next
  
  
 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