Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> 60p video streams
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
60p video streams
PostPosted: Thu Oct 28, 2004 11:46 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I know lots of people are having trouble with 720p broadcasts, especially when using XvMC accelleration. I finally admitted that I wasn't really seeing 60 frames a second (more like 40) when using Xv and XvMC has always been unusable for me for 720p video (picture would break up and xine wouldn't respond for several seconds).

If you're running a 2.4 kernel, the way to get smooth 60p (at least on my system) was to change the scheduler from 100 hz to 1000 hz in /usr/src/linux/include/asm-i386/param.h. This is mentioned on the xine site. It will use more CPU but you'll definitely see 60 frames a second if your system is fast enough. For sports this is a dramatic improvement. This quickly eliminated all the judder or jumpy video I've been putting up with. It looks as good as a STB.

After this change, mplayer displayed perfect 60p video using XvMC. I don't know if mplayer worked before that change. If everything else with mplayer worked, I'd still be using it. Unfortunately it screws up the fullscreen aspect ratio on my 16:9 display. I spent an hour trying to figure it out with no luck so I went back to xine.

Xine still scrambled pictures in 720p streams when it used XvMC and it was just too slow to display 60p using regtular Xv. I noticed that the Nvidia card was sharing an interrupt with the network card. I shut the network down with ifdown eith0 and suddenly no (well almost no) scrambled pictures. I moved some interrupts around so the video card would share an interrupt with a USB controller I never use and now it works almost perfectly. I don't know why xine has this problem while mplayer had no problems so there must be a software solution to it. I'd look into it but I couldn't even figure out why mplayer was screwing up fullscreen on my 16:9 display.
View user's profile Send private message
Re: 60p video streams
PostPosted: Fri Oct 29, 2004 2:07 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Hey Scott,

What kind of machine do you have?

I've got AMD XP2000 Via KT333 w/ 512M 333 DDR, 4x AGP, Ti4800SE. As far as I can tell, I get full frame rate from xine at 1280x720p, with Xv. I don't use XvMC because it seems to cause more problems than it fixes, for me.

I can try an older GEForce2 MX400 and/or AMD XP1900 Via KT266 w/ 512M 266 DDR 4x AGP.

What are you using to determine your frame rate? It might be interesting to see if mine is actually as smooth as it appears to be.

One last thing, on xine setup tab 'misc' what do you have for memcopy method? I'm using sse here, but it may have defaulted to mmx.

[edit]
Just tried xine-hd-0.8 from download link on main page. It works really well, much better than xine-hd-0.7. It seems to skip forward and backwards in the pre-recorded stream properly now. The clock is about 305% too high, but I have to do more testing to see if other broadcasts give same clock results. Oh, and instant viewing works now, i.e.

xine -C 19.2 -G960x544 -f dtv://

No pipe needed anymore, didn't see any buffer glitching, but did have to hit pause a couple of times to get it flowing. Once it got going though, I didnt see any glitching. Will have to test it more, of course.
[/edit]


Cheers!



>Scott Larson mentioned:
>I know lots of people are having trouble with 720p broadcasts, especially when using XvMC accelleration. I finally admitted that I wasn't really seeing 60 frames a second (more like 40) when using Xv and XvMC has always been unusable for me for 720p video (picture would break up and xine wouldn't respond for several seconds).
View user's profile Send private message
PostPosted: Sat Oct 30, 2004 6:45 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I have a AMD XP 2700+ running at 2166 Mhz. The memory is running at 333Mhz. The video card is an Nvidia FX5200 running at 8X AGP. My memcopy method is set to mmxext.

With xine, I've been using my eyes to see whether I'm getting a decent frame rate. If I get judder during pans or if anything doesn't have the super smooth video motion look, I know something is wrong. I've been watching 60p video for a year and I didn't realize how smooth it was supposed to be until I played around with mplayer as an experiment. Lately I've been switching back and forth between the computer and a cable HDTV STB which naturally displays 60p without dropping frames.

With mplayer it's very easy to see if you're dropping frames. If you tell it not to drop frames (don't set -framedrop), your video will slowly drift behind your audio since it will unconditionally display every frame with no regard to A/V sync. Even after all these improvements, mplayer will still let the video drift behind the audio on my system but it takes a lot longer.

I think I've found one secret mplayer uses to get XvMC to work better. The function xvmc_sync_surface has a busy loop which I guess hangs around waiting for frames in the hope that soon there will be more frames to render. I don't pretend to understand what it does, but I added a similar loop to xvmc_display_frame in xine to do the same thing I and think the video is much smoother. If you want to try it, put this loop in between the XvMCPutSurface and XUnlockDisplay calls at the end of the function:

Code:
 
   do{
        usleep(1000) ;//1ms (may be 20ms on linux)
        XvMCGetSurfaceStatus(this->display, &this->cur_frame->surface, &status); 
   } while (status & XVMC_RENDERING);
   XvMCSyncSurface(this->display,&this->cur_frame->surface);                                                                   


xine doesn't appear to use much more CPU with this loop although it does lengthen those periods where the XvMC video is all screwy and xine won't respond to any keys or signals. I've been testing and retesting with this week's Monday Night Football and I've certainly never seen smoother video coming out of my system.
View user's profile Send private message
xine
PostPosted: Sun Oct 31, 2004 1:08 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Scott Larson wrote:


Code:
 
   do{
        usleep(1000) ;//1ms (may be 20ms on linux)
        XvMCGetSurfaceStatus(this->display, &this->cur_frame->surface, &status); 
   } while (status & XVMC_RENDERING);
   XvMCSyncSurface(this->display,&this->cur_frame->surface);                                                                   




Sounds like it would apply to xine-hd 0.7 or 0.8.

You hope that usleep() is less than 20ms, because 60p is 16.68ms frame time. usleep kinda bites :>, nanosleep might be more accurate, so would be 16,683,350 nanos, given 59.94 is the actual frame rate. It would take some testing, but half that value would be a good starting point.

I spend a lot of football time in slow mo, so I might not have noticed the frame loss.

I'll have to look closer at 3pm game on FOX.
CBS still sending football at low res.

Looking forward to testing if xine-hd-0.8 is more robust in my patchwork 2.6 environment.

Since the issues I have running 2.6 seem due directly to stream corruption freezing up xine-hd-0.7, I expect 0.8's better stream handling will make that problem go away.

I have also noticed some slight stutter during pans, but it's hard to quantify. It doesn't happen often, and sometimes it's downright difficult to reproduce it on successive playbacks.

Sounds like your problem is much worse. For me, with xine-hd 0.7, except for signal dropouts, the series games were very smooth. Already reclaimed the space or I'd go back and look at them more closely.

Thanks for digging out that code segment. That frame loss detect seems a sound method. No identical function in xine, but perhaps setting large AV sync tolerance will also show up frame loss in lipsync stuff. Harder to tell with sports, until they put the bald guy on. He talks a lot. :>

Cheers!
View user's profile Send private message
xvmc results here
PostPosted: Sun Oct 31, 2004 5:48 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Hey Scott, you made it work better!

Tried xine-hd-0.8 with XvMC before the patch, then after your patch.

Before: Totally unwatchable, looks like bus contention issue on any pans.

After: Pretty nice, nearly as good as Xv.

Still had the overlay speckling in certain black areas, and also did notice the non-responsives you mentioned. I'll stick with Xv for now.

Possible Why: It looks like xine was not allowing enough time for the render to finish. You might be able to reduce the sleep further. I used nanosleep and {0,16683350 / 2}. If you can find the bare minimum sleep time needed, this might reduce the non-responsive times.

Comparison of the slight pan stuttering looks nearly identical between Xv and XvMC now. So close I can't tell any real difference.

Cheers!
View user's profile Send private message
PostPosted: Mon Nov 01, 2004 10:28 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Would you believe that I was just about to say "I'm not sure that loop really does anything"? I didn't get around to testing how often that loop gets executed but I was starting to suspect that the busy loop wasn't really being executed often enough to make a difference. I'll do some testing during MNF tonight.

I did lots and lots and lots of comparison between xine with XvMC and my new cable STB during the Seahawks game on FOX yesterday. I can honestly say that with some saturation and contrast adjustments, the two looked almost identical. It looked like the Moto DCT-6200 was doing the 1280 to 1368 pixel upconversion slightly better, adding a tiny bit of unsharp and maybe a tiny bit of anti-alias filtering. The difference was very subtle. I regularly got confused by which one I was looking at. I'd expect my mouse pointer to zip across the screen and it wouldn't because my monitor was displaying the STB. Except during the screwy XvMC tearing problem, the frame rates looked identical and action and pans were identically smooth.

You can have xine tell you if it's dropping frames with the --verbose option. It will print something every 200 frames if any were dropped or skipped, or it will print nothing if they were all displayed. If xine isn't printing anything, just move your mouse around or do something to eat a little CPU.

The xine XvMC tearing problem is obviously related to how xine is or isn't recovering from dropped frames. The problem never happens when xine is not dropping or skipping frames. It's strange that xine is unreponsive during the periods. It always goes into this state when I pop up an xine menu and it makes it impossible to select anything. I have to stop the video, do stuff in the menus and then restart it.

mplayer sure has a better XvMC engine than xine. It has an eight frame queue that seems to prevent it from dropping frames in situations where xine drops them like crazy. I'm not sure if xine's XvMC code uses a queue at all. I finally figured out how to get mplayer to fullscreen correctly on my 16:9 monitor using the -monitoraspect option (I don't know why it can't figure this out automatically). I think I'm going to start using that instead of xine on the 720p channels. mplayer is definitely not as good as xine on the 1080i channels because it can't do deinterlacing with XvMC.

I also have one other problem with xine's XvMC: it simply can't display my WB station (1080i) correctly. Static (non-moving) parts of the image are displayed as vertical bands about 8 pixels wide. I have no idea what could be causing this but it only happens with xine using XvMC. I think I'll try to figure out how xine does deinterlacing with XvMC and try to get mplayer to do it.


Last edited by Scott Larson on Mon Nov 01, 2004 10:40 am; edited 1 time in total
View user's profile Send private message
PostPosted: Mon Nov 01, 2004 10:37 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Oh yeah, the speckling. Do these appear as white horizonal lines a few pixels long? I was looking for those during the Seahawks game and I didn't notice any but I only see them in dark areas and that was a sunny day game. I remember mplayer also had this problem but displayed them as green or pink lines and those were more distracting than white lines. I've heard that even older STB's have this problem too. I'll be looking for these during MNF tonight.
View user's profile Send private message
PostPosted: Mon Nov 01, 2004 2:12 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I did some lunch-hour looking at the XvMC API. Supposedly the only thing code has to do to get perfect synchronization is to always call XvMCSyncSurface before calling XvMCPutSurface. For some reason neither xine nor mplayer is doing this exactly. They both call XvMCGetSurfaceStatus and test for the XVMC_RENDERING flag. If the frame is still rendering, xine will call XvMCSyncSurface and then call XvMCPutSurface. If mplayer finds the frame is still rendering, it calls XvMCFlushSurface (which is commented out in xine) and then goes into that XvMCGetSurfaceStatus busy loop until the XVMC_RENDERING is false. Only then does it call XvMCSyncSurface.

This seems backwards to me. Why not always call XvMCSyncSurface before calling XvMCPutSurface? Is it so expensive that it's cheaper to call XvMCGetSurfaceStatus in a loop instead? I noticed that in an i810 video driver, XvMCSyncSurface is just a loop that calls XvMCGetSurfaceStatus testing for XVMC_RENDERING (with a comment that says "FIXME: Perhaps a timer here to prevent lockup? FIXME: Perhaps a usleep to not be busy waiting?"). Maybe doing that in the kernel is better.

I also wonder if I should put back all those XvMCFlushSurface calls that someone commented out of xine. It sounds like it could cause an incomplete frame to be displayed, but mplayer thinks it's a good idea and mplayer does work better on my system for some reason. In that i810 video driver, XvMCFlushSurface just returns success. Maybe it actually does something in the driver for my card.
View user's profile Send private message
xine speckling in xvmc mode
PostPosted: Tue Nov 02, 2004 12:34 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




The speckling appears as bright or white pixels, but they are located only in some parts of the black areas, like a certain shade of black is making something else show through.

Not lines vertical horizontal or diagonal, but speckles that seem to follow a certain black level.

Maybe a few hundred pixels depending on the black level, like say a drive to a shadowy area, you'll see a halo of speckles outlining the darkest areas, almost an inverse of the black.

Scoreboard shows it on certain pixels too.

xine static image of stylized 'xine' logo when no video source selected shows worse speckling halo around the stylized lettering curves.

Maybe it's simply a colorkey issue, but could also be a look-up table color translation issue.

I should try in 24 bit or 32 bit mode instead of 16, in case the overlay code isn't rounding the color correctly for a proper 16 bit match-up.

I did notice that xine-hd-0.8 seems more prone to overlay colorkey loss, maybe because the problem lies in binary only nvidia driver.

This may be relatd to the old 'bluescreen' colorkey problem you see when switching between streams that have different sized video frames.

Nvidia claims to have fixed it, but it's not.

I've seen some odd messages that indicate nvidia goofed up locking of the overlay itself, and this might be to blame for the bluescreens.

The same driver behaves better under 2.4.26, but still loses overlay about 1 out of 10 times, and still shows the XvMC speckling that I've seen on every attempt to use XvMC, 2.4 or 2.6 kernel.

Under 2.6.7 it seems overlay colorkey gets lost at a higher frequency, maybe 4 or 5 out of 10, depending on how often I change the frame size.

For example, will play a bunch of same frame size files in a row and maybe fail on 10th one, but if I try 720p then 1080i then 720p, it will bluescreen sooner than later.

It doesn't seem to be related to the choice of xv or xvmc, but I should collect more data on that.

Thanks for that xine patch. At least now I can experiment around with XvMC where before I just laughed at it.

The linear look to the xvmc noise gave it away.

I'm old school man, my TRS-80 Mod 1 had same problem with artifacting when I hopped up the CPU to 3.4MHz. CPU would be trying write to video memory at the same time the video shifter was trying to shift out video bits. The result was black linear rectangles sprinkled around on the screen that matched the CPU+shifter accesses.

A 7474 dual JK that had a single flip-flop unused spare on the mobo let me force the CPU into wait states until the video shifter was done. A little bit slower but a lot better looking.

While the problem isn't identical, it does have enough similarity to make me wonder.

My theory:

The individual stripes looked about 16 pixels tall, and motion compensation would only work on 16x16 macroblocks along a horizontal stripe of video, based on the assumption that most pans are horizontal not vertical.

So the stripe size fits a macroblock size, and the artifacting was caused by not waiting until that macroblock was done before starting another.

A video memory bus contention issue.

These motion compensation macroblocks depend on previous values being fully computed. If you don't wait for the values to get computed, you will have problems farther down the slice. This appears as horizontal artifacts.

If any prior macroblock data, on that slice, is overridden by a new 'too early' macroblock, the partial old data will affect and corrupt the new macroblock that is trying to base itself upon the previous partial, and most likely, corrupted one.

This is why your patch works, because it's waiting long enough for the macroblocks to get done. I suspect xvmc interrupts the sleep if it gets done sooner than the sleep time, so maybe trying to down-tune the sleep is a waste of time.

It explains what I saw, with XvMC before your patch, well enough for me, but maybe I should get new glasses?

I wish I could find such a nice easy explanation for the speckles, but I've got nothing.
View user's profile Send private message
1080i
PostPosted: Tue Nov 02, 2004 12:49 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




I cheat for 1080i mode. De-interlace is too slow for AMD XP2000. Looks like crap.

I use xine -G960x544 instead. Yeah, I know. I said I cheated. My monitor can't do 1920x1088.

So let the overlay cut out every other horizontal and vertical line for free. I think it does some half-pel computation, by the way, which may be why 960x544 doesn't look like crap.

1/4 1080i resolution is still better than DVD.
View user's profile Send private message
welcome to X :)
PostPosted: Tue Nov 02, 2004 2:13 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Yeah, now you know why I'm not real keen on X programming yet. It can be very non-intuitive.

The small bit I've done for my apps, man, I had to think backwards to get it done. Gtk and OpenGL both require some backwards thinking.

Populate the container before adding it to the window, instead of less obtuse method, but now archaic, of adding container to window then populating it.

It looks less 'busy' with the more obtuse X method, and it may avoid null pointers you would run into with the other method.

How does this apply to what you studied?

I don't know. I'm just letting you know you're not the only one who finds X can be a bit backwards. But, man, when you get the order right for whatever you're doing, it's soild.

You know more about xine than me. I dug around a little bit for a clock fix, but it didn't make much sense, too many abstracted structures.

You might be the one who gets the order right for all this XvMC stuff. You've sure done a fine job so far.

And Now For Something Completely Off-Topic and Shameless:

Hey, you think you could tell me why xine ui clock is 300% +/- 5% off? Don't get me wrong, I'm happy to have a clock and all finally, but makes me wonder where the computation went wrong.

Cheers!


Scott Larson wrote:
I did some lunch-hour looking at the XvMC API. Supposedly the only thing code has to do to get perfect synchronization is to always call XvMCSyncSurface before calling XvMCPutSurface. For some reason neither xine nor mplayer is doing this exactly. They both call XvMCGetSurfaceStatus and test for the XVMC_RENDERING flag. If the frame is still rendering, xine will call XvMCSyncSurface and then call XvMCPutSurface. If mplayer finds the frame is still rendering, it calls XvMCFlushSurface (which is commented out in xine) and then goes into that XvMCGetSurfaceStatus busy loop until the XVMC_RENDERING is false. Only then does it call XvMCSyncSurface.

This seems backwards to me.
View user's profile Send private message
PostPosted: Tue Nov 02, 2004 11:10 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Since MNF was a Jets blow out, I had plenty of time to tinker around.

I added a printf to the busy loop in mplayer and the one I added to xine. The busy loop in mplayer was never executed. The busy loop I added to xine was executed continuously, usually every second or two. Since the loops seem to be in the same spot in the drawing process, that implies that they're doing something different somewhere else.

Also, you can replace my busy loop with
Code:
XvMCFlushSurface(this->display,&this->cur_frame->surface); 

It does the same in the driver and may do it more efficiently. It doesn't solve all of xine's problems but it does let xine work perfectly if it isn't dropping frames.

I'm starting to suspect that mplayer's frame queuing system is what's making the difference here. Strangely xine has the beginnings of frame queuing in its code but it isn't used. xvmc_display_frame calls xvmc_add_recent_frame to add the frame to an array before displaying the frame. A comment claims it's used for deinterlacing but it doesn't seem to use any of these frames it's saving. There is also another larger array called frames[] which looks like it was intended for queuing but there's no code to even update the array.

I'm thinking that it might not be too hard to use one of these arrays to implement the simple queuing system that mplayer uses. I'm going to do some more testing to see how deep mplayer queue frames when displaying 60p streams.

I did some eyeball-to-the-screen quality comparisons between xine, mplayer and the STB during MNF. Naturally the STB looked best with the least artifacts. mplayer looked almost as good but with a few more artifacts. For example, the grass flickered more as the camera slowly panned the field. My STB seems to be doing some antialiasing to handle this.

xine on the other hand simply looked terrible close up. The image had vertical bands eight to sixteen pixels wide. They were similar to the problem I have with my WB station, more subtle but definitely there. Chalk lines on the field had white vertical smears giving them a foggy staircase effect. As the camera panned around, the scoreboard left a purple trail a few pixels long. Other high contrast regions left similar trails. This happened even when using regular Xv. Could there be some magic xine setting that's wrong for my system?

mplayer never displayed junk like this. This alone is making me wonder if I might be better off adding XvMC deinterlacing and dtv channel support to mplayer. I have no idea how to solve xine's other problems.

One good thing: I very rarely have overlay problems with the FX5200. I regularly lost the overlay with a slightly older Nvidia card. It's still easy to cause programatically as I've discovered several times.

My old Ohio Scientific computer (about the age of the TRS-80) also had blanking when the CPU accessed video memory. If you disconnect it, you would get a spray of random white pixels which looked even worse than black lines.
View user's profile Send private message
PostPosted: Tue Nov 02, 2004 10:02 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




More comparisons between xine and mplayer on 1080i streams show that xine displays the same ugly vertical banding. Everything mplayer displays is smooth, sharp and clean (with one exception). It's just like not getting 60 frames per second -- once I saw the difference I couldn't stop seeing it. mplayer also has the advantage of being able to sync to the audio stream every time. I almost t always have to pause the latest version of xine-hd to get the sound going.

Even better, adding deinterlacing to mplayer was very simple thanks to XvMC. In the function flip_page(), just replace the last parameter in the call to XvMCPutSurface() from "3" to "XVMC_TOP_FIELD". This apparently will give you "onefield" deinterlacing for free. It works perfectly as far as my eyes can tell me but I won't be sure until I see some football. As soon as I add a command line option to set the channel, I doubt I'll be using xine again. My mplayer command line is:

Code:
 mplayer  -monitoraspect 16:9 -fs -cache 8192 -framedrop -vo xvmc -vc ffmpeg12mc queue -lavdopts idct=2  /dev/dtv


The one problem mplayer has is speckling. It definitely has a problem of displaying short white horizontal lines, sometimes once a minute, sometimes every few seconds. Even with this, it's still cleaner than xine.
View user's profile Send private message
60p video streams
  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 1 of 1  

  
  
 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