pcHDTV :: View topic

Scott Larson

So this proof of concept didn't quite work all the time. It worked fine with 1080i stations with reduced bit rates (yeah, almost all of them these days). It had no problem keeping up with any film-source material and had no problem keeping up with SNL and Leno and the horse racing on NBC.

It totally failed with any 1080i video at full ATSC bitrate like CBS football (my affiliate turns off subchannels during sports). The problem was that the decode_video() call was taking too long processing all the data. XvMC speeds up the displaying of MPEG but it doesn't making processing MPEG-2 any faster (and there's a lot of stuff you have to do before XvMC can help you). Often decode_video() would take more than 1/60th of a second to finish which is too long for 59.97 fps. Once you add the flip_page and other overhead, it would get hopelessly out of sync with the audio and start dropping frames like crazy. Even though decode_video() was skipped every other time it looped (every frame contains both odd and even fields so the second field is already decoded), the time saved in the second loop doesn't help because every loop has to complete in 1/60th of a second otherwise the frames will display unevenly (mplayer doesn't like this). So I've found it's more reliable to run the loop at 29.97 fps and let flip_page() take a longer time displaying both fields with two XvMCPutSurface() calls than running the loop at 59.97 fps and hope that decode_video() will complete fast enough all the time.

I think the flip_page with the two XvMCPutSurface calls is taking lots of time because the second call is waiting for the first call to finish displaying the surface. It might be possible to use two separate surfaces so the calls won't have to share the same surface.

I also noticed that my system just barely keeps up with 720p at full ATSC bitrate. It usually drops a frame every three or four seconds. What keeps it going is that flip_page() (which calls XvMCPutSurface()) can display 1280x720 just fast enough to avoid trouble, while displaying one field of 1920x1080 takes about 50ms longer. Dropping a 720p frame is less noticable because it's just 1/60th of a second, a tiny blip. Dropping a 1080i frame takes out 1/30th of a second of video which is much more noticable.

dorphell

Scott Larson

Instead of using torndr->display_flags, try getting rid of torndr and changing the if to use "p_render_surface->display_flags":

dorphell

Okay that worked

Scott Larson

Here's an update on what I've been doing. Please note that these diff fragments might depend on changes I've made in header files and might not compile. If that's the case, let me know. I'm mostly illustrating changes, not posting a patch.

I'll review the basics here... the method of having put_xvmc_image() display both fields works, no doubt about it. While my Nvidia card is only using bob deinterlacing, it looks just as good as my cable STB (which probably also uses bob deinterlacing!). If you've ever seen smooth 1080i video, you know you want this.

The problem is that mplayer maintains A/V sync by dropping frames. With 720p this isn't a big deal because one missing 720p frame isn't too noticable. Dropping a 1080i frame on the other hand is actually dropping two fields -- much more ugly. It's also more likely to happen since displaying 1080i takes more CPU and the call to XvMCPutSurface() to display the second field will block until the next vertical refresh.

My idea of having the mplayer main loop run at 60 fps so it wouldn't be blocked when displaying the second field? Forget it. The mplayer main loop wasn't really designed to display fields and the overhead of spinning the loop twice as often was more than XvMCPutSurface() waiting for the vertical refresh, so I went back to handing the dirty work to put_xvmc_image().

The best method I found was to have the main mplayer loop tell put_xvmc_image() via an ugly global variable to skip displaying the second field when it needs to adjust the A/V sync. If the video continues to fall out of sync with the audio, it will start dropping entire frames. Here's the global in mplayer.c plus a new static variable to keep track of how many fields have been dropped:

ubikdood · Last edited by ubikdood on Sun Aug 13, 2006 8:54 am; edited 1 time in total

Hi Scott,

I've been looking for something like this for quite a while.
A simple "thank you" is not enough to express my gratitute to you for sharing your knowledge on such a hard subject.
Too bad we don't have more people trying to improve HDTV displaying in mplayer Sad

Your changes for smooth interlace display were right on the spot.
The following is a patch to be applied on MPlayer-1.0pre8, with slight changes to avoid compilation errors and lirc detection on newer kernels.

Out of curiosity, what vertical display rate do you use to play 1080i streams bob-deinterlaced with your method ?
I can play 1080i bob-deinterlaced streams at 60 Hz, but CPU usage is near 100% when I use a GeForce FX 5500. If I increase the vertical display rate to 70 Hz, CPU usage gets low to around 30% (but bob is not so smooth Sad

). This "CPU struggling" also happens when I play 720p streams (59.94 fps) using any "vanilla" mplayer (1.0pre7, 1.0pre8).
When I switch to a GeForce 6600 GT, CPU is around 40-75% (varies a lot).
Seems like an obscure "timing" issue. Geez...

Anyways, thanks again.
The patch follows, for anyone who's interested. I sure recommend it to anyone who needs deinterlacing.

Hugo

Scott Larson

ubikdood · Last edited by ubikdood on Sun Aug 13, 2006 9:14 am; edited 1 time in total

Ryan

ubikdood: Using an Athlon XP 3000/400fsb with a Geforce 5900xt, and I don't get 100% cpu usage although I may be getting what you described with 720p if top isn't lying to me when I make it update more quickly.

BTW. your patch as posted doesn't apply cleanly thanks to the wonders of whitespace. Had to remove spaces from empty lines, add the odd extraneous space, and a hunk from mplayer.c actually needs a mix of tabs and spaces. :/

ubikdood

Ryan

I use an LCD monitor that's set at 60 Hz, so I SHOULD be affected by whatever it is you're seeing.

Scott Larson

If the sleep helps things that perhaps the driver does an active wait on the vertical refresh. I know my old version of the driver doesn't do that but who knows what crazy things Nvidia is doing with their drivers these days.

You're correct that these changes haven't been accepted by the mplayer folks yet. The maintainer of this code has been having discussions with author about details of the changes and it's been going back and forth for weeks. He believes the code to set the first_field and top_field_first flags are too complicated thus there must be "a simpler way." He has no suggestions on what that simpler way might be but perhaps he's communicated this to the author in more detail.

He's also not convinced that the second XvMCPutSurface() is doing anything even though anyone who has applied this code can easily see the frame rate doubling and both fields being displayed deinterlaced properly. It's hard to convince someone who has never seen it.

He suggested that they rewrite mplayer to loop at double the frame rate to support software deinterlacing too. I thought he actually tried this once and the code was rejected. It's an interesting idea but it would require a lot of recoding and adds a lot of overhead which is wasted in XvMC because the frame with the second field is already sitting there waiting to be displayed after the first field is displayed. It would allow the code to treat field-dropping as the same as frame-dropping but I've found it's better to treat them differently. My code starts dropping fields if the video gets slightly behind the audio (dropping fields is barely visible) and only drops complete frames if the field-dropping doesn't sync things up again.

I'd like to thank Tomas Janousek for submitting these changes to the mplayer development list. I would never have the patience to deal with the incomplete and hypothetical requests they're asking of him to get this change accepted! Confused

ubikdood

ubikdood

Scott Larson