[ashlar]

Thanks. I'm available for providing more information, if needed. I tried watching a movie yesterday night, forcing 24Hz. It was good. As I said, not perfect but good. Definitely watchable.

Tried the latest SVN, problem is still there (autoswitching to 60Hz).
On the other hand, when forcing 48Hz from inside XBMC, playback performance has improved. Not perfect by any means (24Hz is far better) but there is noticeable improvement "stable-framerate-wise".

[Hitcher]

How on earth do you force a framerate change from inside XBMC?

[ashlar]

How on earth do you force a framerate change from inside XBMC?

I'm using a little program, quickres, which I have bound to keys on my remote, by using the HIP Remote application.
The refresh rate keys are system wide, meaning they are used from anywhere in Windows (HIP allows different keymaps for different applications).
If you need more details, links, whatever, feel free to ask.

[ashlar]

Should I file a bug report for this 60Hz autoswitch thing?

[HexusOdy]

Yeah you should mate, sounds like a bug to me

[rernst]

I'm using a little program, quickres, which I have bound to keys on my remote, by using the HIP Remote application.
The refresh rate keys are system wide, meaning they are used from anywhere in Windows (HIP allows different keymaps for different applications).
If you need more details, links, whatever, feel free to ask.

Are you using digital input (HDMI or DVI) into your TV? If so, whateer you set your refresh rate is completely meaningless. Refresh rate pertains to the speed of the CRT beam. If you don't have a CRT but a digital display refresh rate does not exist.

[marc.aronson]

I just installed XBMC and tried using it for the first time today. It is a great product, but I am also having the problem with "jittery" playback, especially during horizontal pans. I am wondering if this could be same problem I ran into when I first tried to transcode mpeg2 video recorded in NTSC land to XVID using mencoder. During the transcode process I would deinterlace the video using the "kern" deinterlace filter so that the output XVID was progressive scan. Some videos came out perfectly smooth; others had the same problem with jittery pans. Here is what I eventually learned:

In NTSC transmissions, there are two distinct methods used for creating interlaced video: Interlacing and telecine. TV shows filmed in front of a live audience, such as "THe Nanny" & "Home Improvement" are interlaced, and a deinterlace filter will produce good results. Shows like "JAG", "Battlestar Galectica" and others not filmed in front of a live audience are telecined, and need to be deinterlaced using an inverse-telecine filter. Using a regular deinterlace filter, weather kern, linear blend or any other will give poor results if the source was telecined, with the problems most visible during pans.

In mythtv the bob2x filter is actually capable of deinterlacing either method properly, as bobx2x essentially simulates what an old-style interlaced TV set does.

The document that helped me to better understand this situation is http://www.mplayerhq.hu/DOCS/HTML/en/men...ecine.html


Does XBMC support both deinterlacing and inverse telecining and could this be the source of the problem?

Marc

Addition made after initial post: It is probably worth noting that this problem will not happen with PAL transmissions. PAL transmission are never telecined. This is only a problem in NTSC land...

[ashlar]

Are you using digital input (HDMI or DVI) into your TV? If so, whateer you set your refresh rate is completely meaningless. Refresh rate pertains to the speed of the CRT beam. If you don't have a CRT but a digital display refresh rate does not exist.

I'm using VGA in on a plasma display but in any case refresh rate is far from meaningless, both with VGA and DVI.

And, basically, you really don't know what you are talking about. No offense.

Edit: I don't want to sound like a smartass, it's just that you are wrong.

[dpassent]

There is ALWAYS refresh rate. The pixels just stay turned on on LCD/PLASMA they don't flicker like on CRT. But graphic card will ALWAYS use some refresh rate, ie feeding 24 pictures in a second (24Hz) or 50 pictures in a second (50Hz) or 60 (60Hz) or whatever your TV can handle. The trick is that if you want smooth playback you MUST match your video FPS to the refresh rate. It just works this way.
Imagine you have 24fps (23.997 to be precise) material and you have LCD set to 50Hz (common in the PAL world). You just CAN'T get smooth playback as the gfx card must feed 50 pictures in a second, and you have 24 frames per second in the video. You can of course display frame twice - it gives 48 pictures in a second (48Hz) but you are left with 2 frames - they must be displayed 3 times instead of 2 - that's the jitter. There are some tricks of course that can make this jitter look more acceptable.
In the world of TV they just run 24fps material in the speed of 25fps (7% faster) so it fits perfectly in 50Hz - making films shorter (and the soundtrack a bit chipmunk ).
So to make my point. There is ALWAYS refresh rate in the signal coming out from the gfx card - it just doesn't make pixels in LCD/PLASMA flickering...

My 2 cents...

[ashlar]

Should I file a bug report for this 60Hz autoswitch thing?

I filed the bug report yesterday... but today I've discovered something that might be relevant.

By pressing the \ key on the keyboard I am able to toggle between the desktop refresh rate and 60Hz and the program remains in fullscreen.
XBMC starts with -fs -p arguments. I tried taking them away or running with only one but the desired result was not there (ie. staying at the desired refresh rate, in fullscreen).

[WiSo]

Sounds weird since \ = alt+enter = toggle between fullscreen and window mode

[RDHoworth]

Sounds weird since \ = alt+enter = toggle between fullscreen and window mode

Could that be because Windowed mode has to use the desktop rate? I have noticed that if the resolution is set to the full screen 1920x1080, then alt+enter seems to have no effect.

[WiSo]

yeah that could be because in current svn res >=DESKTOP will trigger full screen afaik. Some thing we have to clean up one day anyway.

[ashlar]

yeah that could be because in current svn res >=DESKTOP will trigger full screen afaik. Some thing we have to clean up one day anyway.

Ok, so there's two things, if I understand things correctly:

1) The autoswitch problem remains and hopefully will be corrected in the future.

2) In the meantime, how can I have XBMC launch in the windowed mode, set at full screen resolution. I mean how can I get from the start the result that I get by manually pressing \ ?

And thanks for all the help, really.

[Hitcher]

I filed the bug report yesterday... but today I've discovered something that might be relevant.

By pressing the \ key on the keyboard I am able to toggle between the desktop refresh rate and 60Hz and the program remains in fullscreen.
XBMC starts with -fs -p arguments. I tried taking them away or running with only one but the desired result was not there (ie. staying at the desired refresh rate, in fullscreen).

Interesting, I'll give it a go later.

Sounds weird since \ = alt+enter = toggle between fullscreen and window mode

Could that be because Windowed mode has to use the desktop rate? I have noticed that if the resolution is set to the full screen 1920x1080, then alt+enter seems to have no effect.

Same here, from what I remember.