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 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 
Real 59.94 fields per second 1080i
PostPosted: Sat Oct 22, 2005 9:38 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Ever notice that 1080i video like you see during football games look so much smoother on your commercial ATSC receiver or cable box than on your HTPC? I have and I think it's because I'm using the cheap "one-field" deinterlacing with xine and mplayer. If you check other threads about this, you'll see to get free deinterlacing, you can call XvMCPutSurface() with XVMC_TOP_FIELD instead of XVMC_FRAME_PICTURE and all the interlace artifacts will never appear.

The problem is, and I may be totally wrong, is that we're only displaying one field every 29.97 seconds and throwing away the other, so that's our frame rate now. This makes motion look more like a 24 frames per second movie than a 60 somethings per second video.

While fiddling around trying to understand this problem, I seem to have stumbled on a solution that's so simple and works so well I'm scared that my eyes are fooling me. All I did was put second call to XvMCPutSurface() after the first with the same arguments except with XVMC_BOTTOM_FIELD, so the code looks like this:

Code:
 
if (deinterlace) {
        rez = XvMCPutSurface(mDisplay,  p_ernder_surface_to_show->p_surface,
                         vo_window,
                         0, 0, image_width, image_height,
                         clipX, clipY, clipW, clipH,
                         XVMC_TOP_FIELD);
        rez = XvMCPutSurface(mDisplay, p_render_surface_to_show->p_surface,
                         vo_window,
                         0, 0, image_width, image_height,
                         clipX, clipY, clipW, clipH,
                         XVMC_BOTTOM_FIELD);
      }


After I did this, I watched football on NBC and switched back and forth between my PC and my cable box and suddenly the motion looks identical on both of them. When I remove the second XvMCPutSurface() call, the motion looks like a 30 fps movie again. I swear it looks almost as smooth as 720p. There are no interlacing artifacts so the hardware must be doing some default deinterlacing. It also doesn't appear to use any more CPU.

I think the hardware is displaying the second field at the right time because my display is set at 60hz so the second XvMCPutSurface() doesn't take effect until the next vertical refresh. When stepping frame-by-frame, I can see the bottom field displaying a fraction of a second after the first. If your refresh is set to something other than 60hz, motion will probably look uneven because the bottom field will display too soon after the top field.

One other bug. Sometimes after fast forwarding or doing something that uses the OSD, I'll get shakey display as if it's displaying the bottom field before the top field. If I pause that will usually fix it but sometimes it doesn't. Maybe I need to add an XvMCSyncSurface() call somewhere.
View user's profile Send private message
PostPosted: Sat Oct 22, 2005 10:55 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




The problem with the shakey display comes from stations sending the fields in the opposite order. Normally they send the top field first as indicated by the top_field_first flag equaling one. For some reason, stations can decide to send the bottom field first for a while. Dunno why they're doing that but I can't complain because they do set the flag to zero to tell me they're doing that.

Right now I'm passing the top_field_first through the render->flags field (which doesn't seem to be used) from XVMC_field_start() in libavcodec/xvmcvideo.c. If the flag is set to zero, flip_page() will display the bottom field first. I've tested it on all the spots in a football game that the screen was going shakey in and it seems to work.
View user's profile Send private message
Re: Real 59.94 fields per second 1080i
PostPosted: Sat Oct 22, 2005 10:56 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Scott Larson wrote:
The problem is, and I may be totally wrong, is that we're only displaying one field every 29.97 seconds and throwing away the other, so that's our frame rate now. This makes motion look more like a 24 frames per second movie than a 60 somethings per second video.


Yes, you are correct. That's commonly known, it's just the regular result from 1-field deinterlacing. Unless you scale down enough to compensate for the missing fields, it will not look smooth.

I just compiled mplayer and tried this myself, and it does work perfectly and it makes perfect sense. I don't know why I didn't think of this myself, heh.

Thanks for the great tip. This is perhaps the most helpful discovery made on this forum yet!

Me == Very happy.. really made my day.
View user's profile Send private message Visit poster's website
Re: Real 59.94 fields per second 1080i
PostPosted: Sat Oct 22, 2005 11:07 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dorphell wrote:
I just compiled mplayer and tried this myself, and it does work perfectly and it makes perfect sense. I don't know why I didn't think of this myself, heh.

Because it doesn't make any sense! Smile What the hell is the hardware doing to make it look so good?

I always thought that stations were sending even and odd fields in separate frames and we were throwing away one of them. Does this mean that they send both fields in a single frame and it's up to the hardware to extract the fields from the frame and display them at the right times? I thought one of the major ideas behind MPEG-2 was to allow compression and transmission of fields as frames so they wouldn't have to send them as a phony progressive frames any more.

But man, this does make a huge difference. It makes it really hard to tell the difference between 720p and 1080i on my display.
View user's profile Send private message
Re: Real 59.94 fields per second 1080i
PostPosted: Sat Oct 22, 2005 11:20 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Quote:
Does this mean that they send both fields in a single frame and it's up to the hardware to extract the fields from the frame and display them at the right times?


I don't think so. I think this hack just sends the 2 frames and apparently the hardware (ours at least) is having no problem handling twice the load in the given timeframe of 1. I really don't think the hardware is displaying just one of the 2. It simply displays both in the time it should display 1. I guess the hardware was simply not being used to its full potential and this is something the card can do with no problem.
View user's profile Send private message Visit poster's website
PostPosted: Sun Oct 23, 2005 12:22 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




But if you debug the code you'll see that flip_page is only being called 30 times a second (well 29.97) in accordance to the rate specified in the MPEG header. If something is loading the surface with both fields before it gets to flip_page, I haven't found it. I put a printf in libmpdemux/video.c to print whenever a frame was decoded and there were only thirty of them a second.

I still think the second XvMCPutSurface() call is being syncronized by the vertical refresh (unless you've tested it on a display that isn't running at 60hz) otherwise both fields would display at about the same time every 29.97 seconds and it wouldn't look this good. The sweeping zooming pans around Franz Ferdinand on SNL looked excellent, almost as good as the 720p pans on American Idol and looked exactly like what my cable box displayed. The only interlacing artifact I've seen is a little twinkling on the edges of the CBS bug.

If you have problems with shakey displaying due to the field swapping let me know and I'll post the top_field_first fix. Too bad the mplayer developers are so unwelcoming to improvements. This could easily be added to xine of course.
View user's profile Send private message
PostPosted: Sun Oct 23, 2005 7:32 am Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Scott Larson wrote:
But if you debug the code you'll see that flip_page is only being called 30 times a second (well 29.97) in accordance to the rate specified in the MPEG header. If something is loading the surface with both fields before it gets to flip_page, I haven't found it. I put a printf in libmpdemux/video.c to print whenever a frame was decoded and there were only thirty of them a second.

That's because we're not really playing this as a 59.94fps video. MPlayer still treats it like it's 29.97fps, it's not aware of the extra rez call. Because there's nothing notifying mplayer about the extra XvMCPutSurface, it is not aware of it.

Scott Larson wrote:
I still think the second XvMCPutSurface() call is being syncronized by the vertical refresh (unless you've tested it on a display that isn't running at 60hz) otherwise both fields would display at about the same time every 29.97 seconds and it wouldn't look this good. The sweeping zooming pans around Franz Ferdinand on SNL looked excellent, almost as good as the 720p pans on American Idol and looked exactly like what my cable box displayed. The only interlacing artifact I've seen is a little twinkling on the edges of the CBS bug.

Ironically, I am running it at 60hz; that's just the limit of my LCD. Why do you think it wouldn't look this good? This is exactly how 60p (which is exactly 59.94fps) format is created, the broadcasters split the fields into frames.

As for your twinkling on the edges... Make sure you don't use this trick on 24p content. I'm sure you know that some stations actually use the 1080-30i format to transmit at 24p. NBC [WHDH] does this here. MPlayer should detect it and tell you:
Code:
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.


Scott Larson wrote:
If you have problems with shakey displaying due to the field swapping let me know and I'll post the top_field_first fix. Too bad the mplayer developers are so unwelcoming to improvements. This could easily be added to xine of course.

Yeah, I don't even want to mention it to them. They'll come up with some [probably wrong] reason to why doing this is very bad.
View user's profile Send private message Visit poster's website
PostPosted: Sun Oct 23, 2005 11:35 am Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Scott Larson wrote:
If you have problems with shakey displaying due to the field swapping let me know and I'll post the top_field_first fix. Too bad the mplayer developers are so unwelcoming to improvements. This could easily be added to xine of course.


You know what, I'm starting to notice this twich sometimes so yeah.. post what you have, I'll give that a try.
View user's profile Send private message Visit poster's website
PostPosted: Sun Oct 23, 2005 1:39 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dorphell wrote:
That's because we're not really playing this as a 59.94fps video. MPlayer still treats it like it's 29.97fps, it's not aware of the extra rez call. Because there's nothing notifying mplayer about the extra XvMCPutSurface, it is not aware of it.

And that implies that we're doing two XvMCPutSurface calls on a single frame.

Quote:
Ironically, I am running it at 60hz; that's just the limit of my LCD. Why do you think it wouldn't look this good? This is exactly how 60p (which is exactly 59.94fps) format is created, the broadcasters split the fields into frames.

Because I believe the XvMCPutSurfaces are being synced to 60hz by the display's refresh rate. If your display was running at say 75hz, instead of both fields displaying 1/60th of a second, the top field would be displayed for only 1/75th a second and the bottom field would be displayed 1/50th of a second (if I did my fractions correctly).

Quote:
As for your twinkling on the edges... Make sure you don't use this trick on 24p content. I'm sure you know that some stations actually use the 1080-30i format to transmit at 24p. NBC [WHDH] does this here. MPlayer should detect it and tell you:
Code:
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

Yeah, some stations have encoders that apparently use cadence detection (is that what it's called?) to lock onto telecine sequences and use the repeat flags. I think this is kind of cool since it does reduce bandwidth waste. My CBS station does this but forcing the fps didn't change it. It's really not that noticable.

Quote:
Yeah, I don't even want to mention it to them. They'll come up with some [probably wrong] reason to why doing this is very bad.

I've noticed just mentioning HDTV makes them roll their eyes and shake their heads, as if it's just a toy that rich Americans are playing with and a waste of time for sensible people.
View user's profile Send private message
PostPosted: Sun Oct 23, 2005 1:57 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




dorphell wrote:
You know what, I'm starting to notice this twich sometimes so yeah.. post what you have, I'll give that a try.

OK here's what I have...

In XVMC_field_start() in libavcodec/xvmcvideo.c, under the
Code:
    render->flags =  (s->first_field)? 0: XVMC_SECOND_FIELD;

line, put
Code:
    render->display_flags = s->top_field_first;

The display_flags field is totally unused and safe to use.

Then in libvo/vo_xvmc.c, change the original change to this:

Code:

      if (deinterlace) {
        unsigned int first_field, second_field;
                                                                               
        if (torndr->display_flags) {
                first_field = XVMC_TOP_FIELD;
                second_field = XVMC_BOTTOM_FIELD;
        } else {
                first_field = XVMC_BOTTOM_FIELD;
                second_field = XVMC_TOP_FIELD;
        }
                                                                               
        rez = XvMCPutSurface(mDisplay, p_render_surface_to_show->p_surface,
                         vo_window,
                         0, 0, image_width, image_height,
                         clipX, clipY, clipW, clipH,
                         first_field);
        rez = XvMCPutSurface(mDisplay, p_render_surface_to_show->p_surface,
                         vo_window,
                         0, 0, image_width, image_height,
                         clipX, clipY, clipW, clipH,
                         second_field);
      }
View user's profile Send private message
PostPosted: Sun Oct 23, 2005 2:26 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




vo_xvmc.c:1077: error: 'torndr' undeclared (first use in this function)

Where's this torndr comming from?
View user's profile Send private message Visit poster's website
PostPosted: Sun Oct 23, 2005 10:43 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




Ooops, I bet I put "torndr" in to debug something at some point. Above the flip_page function, put this line in:

Code:
xvmc_render_state_t * torndr;


I think that will link to the global "torndr". If not lemme know.

I've noticed I get a lot of dropped frames when there's some disk activity. One or two dropped frames every second with 720p is hardly noticable but this makes 1080i lose two or four consecutive fields since they're considered one frame. I think the code is more likely to drop frames too because the two XvMCPutSurface calls are taking more time. I don't have a slow system at all so I'm trying to figure out how to get mplayer to treat the two fields as individual frames so maybe only one will get dropped.

When I'm reading 1080i straight from the device with no dropped frames my God it looks absolutely wonderful -- absolutely no difference between mplayer and my cable box. Surprised
View user's profile Send private message
PostPosted: Fri Oct 28, 2005 10:20 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




As a "proof of concept", I made a horrible hack to mplayer that greatly improves the way it displays interlaced fields with XvMC. I was getting lots of frame drops with the original change and I figured it was because the two consecutive XvMCPutSurface calls in flip_page() were taking longer than the ugly mplayer main loop would like. Normally flip_page() would return almost immediately (XvMC will automatically display the image at the right time by itself). It appeared that the second XvMCPutSurface call was taking a long time, probably because it was waiting for the first one to finish being displayed (one vertical refresh). mplayer just hated waiting for flip_page() to return because it didn't leave it much time to do anything else in the main loop.

So the horrible hack (and there are better ways of doing this) is to force the frame rate to 59.97 frames per second with -fps, then instead of having flip_page() display both fields the main loop would set a global variable to select which field it would display. The mplayer loop then has to remember not to call video_read_frame() when it loops to display second field (since it will be displaying from the same frame as the last) and likewise not call decode_video() since that's already been done too (and fake its success so the code doesn't freak out). Then flip_page() does the job of flipping the global variable back and forth depending on which field it just displayed.

This has the effect of making the main loop spin twice as often so it can take care of the audio sync much better and be less tempted to start dropping frames to keep the video in sync. The result is almost as good as 720p behavior. Before mplayer would always drop a frame or two every second when I was watching 1080i video like SNL and Letterman. Now I never lose a single one unless I'm doing something else on the system (just like 720p).

Besides the kludginess of the code, I haven't been able to get the mplayer XvMC render queuing to work since I don't have a way of tracking when I've displayed both fields of a frame and it can be removed from the queue. The code works very well even without the queuing.

We'll see how well it works tomorrow during NBC and CBS's college football.
View user's profile Send private message
PostPosted: Sun Oct 30, 2005 1:18 pm Reply with quote
dorphell
 
Joined: 01 Feb 2005
Posts: 71




Hmm, can you post your code for that hack? If it'll get rid of the shakeyness and keep it the video steady I wanna try =)
View user's profile Send private message Visit poster's website
PostPosted: Sun Oct 30, 2005 7:30 pm Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




I already posted a fix for the shakey video (the top_field_first fix).
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 1 of 5  
Goto page 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