I`m struggling to find the correct deinterlace settings for VDPAU (Atom): "Auto" only works for 576i, but gives me stutters with 1080i... Even "Bob" makes 1080i stutter... But I thought the Atom does have built-in deinterlace functions...? The CPU is idling at around 10%, so that probably not a problem.
I using an Atom 330 with the nvidia drivers from the xswat ppa and libvdpau from nvidia-vdpau ppa.
Thanks!
Not sure what your source is here, but for the 1080i BR rips I work with I have to manually set the force the fps to 30,000/1001 = 29.97 fps in MKVMerge or TSMuxer.
Once I did this the file played smoothly; without it stuttered like crazy.
http://forum.xbmc.org/showpost.php?p=649...stcount=20
Source of the movies is DVB-S2, recorded with a TT 3200 device and mythTV.
After having implemented the hints from
here and
here, I can play back movies almost (see
here), if I don't activate deinterlacing in XBMC (my TV has a basic built-in deinterlace facility, so that's ok).
My hope was that deinterlacing through VDPAU would be better than what's built into my TV. But it's strange that neither "Auto" nor "Bob" are working for 1080i. Interestingly, if I turn on deinterlacing, there is no real "stutter", it's more like the movie is playing back in waves, slowly, then accelerating (smoothly, but clearly too fast), then again too slow.
Your suggestion is to transcode the movies, from currently 50 fps to 30 fps, and to deinterlace them at this point, so that the result would be a 1080p movie, right? I guess that's more a work-around than an actual solution to play back 1080i content.
Hammi Wrote:Interestingly, if I turn on deinterlacing, there is no real "stutter", it's more like the movie is playing back in waves, slowly, then accelerating (smoothly, but clearly too fast), then again too slow.
I see exactly the same behavior. The interval length of one fast-slow iteration is in the magnitude of one second, I would estimate.
The content which I'm trying to play is an untouched MPEG2 stream ripped from an original Star Trek TNG PAL DVD muxed into an MKV container.
If I recall correctly the behavior occurs only with interlacers which produce one frame per field (doubling the frame rate and preserving temporal resolution), but not with interlacers which produce only one frame per two fields (preserving the frame rate but reducing temporal resolution).
I'm also using Dharma on Atom+ION.
kolja Wrote:If I recall correctly the behavior occurs only with interlacers which produce one frame per field (doubling the frame rate and preserving temporal resolution), but not with interlacers which produce only one frame per two fields (preserving the frame rate but reducing temporal resolution).
Ok, so does this mean the these deinterlacers are as such not usable, badly implemented in VDPAU, or is this an issue with Dharma? I don't think I had these issues with 9.11, but I'm not entirely sure.
I'm not sure it has anything to do with the VDPAU deinterlacers.
I'm currently at work and can't try it myself, but if I recall correctly it happens also with pure software deinterlacers. For example try Bob and Weave, I would expect Bob to show the problem and Weave to be OK. You can also try all the VDPAU interlacers with "Half" at the end of the name, they should be OK also. It only depends on whether the interlacer doubles the frame rate or not.
Maybe the difference between Dharma and previous release seems to be which interlacer is picked when Auto is selected. I assume currently the best possible VDPAU interlacer is chosen, which is "Temporal+Spatial" without "Half", which doubles the frame rate.
If I understand the source correctly, Bob may be VDPAU or software, but Weave is always software. So my conclusion may be wrong.
The only deinterlace method in XBMC implemented in software is the one called "Deinterlace", the rest is done in opengl or vdpau.
Thanks for the clarification.
Do you have any thoughts about the original problem, playback of 25fps interlaced mpeg2 results in uneven speed when a fps-doubling deinterlacer is selected?
I just found another thread from december last year where you wrote in a similar context something about framerate calculation which needs to be fixed. Is this related?
->
http://forum.xbmc.org/showthread.php?tid=88230
That was simply because the gpu was too slow.
Ah yes, if I remember correctly first generation ION is not powerful enough to deinterlace 1080i using full temporal+spatial, which may explain what Hammi is seeing. But I would expect no problem with PAL resolution, which is what I am playing back.
Here it comes. I used sed to filter path- and filenames which are logged by the library update process for privacy reasons.
http://pastebin.com/am3sR3Dd
Playback was started two times during this session, first time using "Temporal/Spatial (Half)", second time using "Temporal/Spatial". The fast-slow-fast playback pattern was cleary visible the second time. One slow-fast iteration is a little bit shorter than one second and always very periodical.
kolja Wrote:Ah yes, if I remember correctly first generation ION is not powerful enough to deinterlace 1080i using full temporal+spatial, which may explain what Hammi is seeing. But I would expect no problem with PAL resolution, which is what I am playing back.
I'm having the issues with 576i as well as with 1080i... And I can't remember that I had these with 9.11...
Hammi Wrote:I'm having the issues with 576i as well as with 1080i... And I can't remember that I had these with 9.11...
What graphics hardware do you have exactly?