Refresh-rate switching happens late where variable frame rate

[StrangeNoises]

Mostly pasted from the offtopic post to the forum yesterday. :-) NB: This is now repeated with the version just now updated from https://launchpad.net/~wsnipex/+archive/xbmc-xvba-testing - which internally shows to be 12.0-ALPHA3 GIT:Unknown) but which apt reports as:

Version: 2:12.0~git20120708.2243-c6fc742-0precise

Issue is with auto-switching of refresh rates: Some videos for which the refresh rate should be changed, do not trigger that refresh rate change until after a few seconds of playback. The pattern I've been able to find so far is that this only seems to affect videos marked as having a variable frame rate.

(Handbrake uses a variable frame rate as part of its High Profile preset; and has done for at least a couple of years. Even if the frame rate isn't actually going to vary.)

Thing is, at least according to mediainfo, a headline refresh rate is provided anyway, so surely even if it is marked as variable, it should start with the given frame rate as a starting presumption? I think older versions - in particular up to 11.0 eden - did do this as I'm only starting to see this problem now. I had been seeing it on only one fairly old encode before, where that headline frame rate was actually listed (oddly) as 24.998fps; whereas most PAL-type videos show exactly 25.000fps. So even on eden that video started, then changed refresh rate (actually just back to the same one as it's the closest). But with the new build, it's doing it for all such variable-frame-rate recordings.

After that initial refresh rate change, playback continues normally for the duration. It's just that it seems to be waiting to see if it really needs to change refresh rate for such videos. Obviously this is pretty disruptive to the viewing experience.

edit: context:

System is Ubuntu 12.04 64-bit installed on 2010 mac mini server connected by HDMI to a Panasonic Viera TV.

The only deviations from the Ubuntu standard packages are the ppas: ubuntu-x-swat/x-updates (for nvidia 302.17) and wsnipex-xbmc-xvba-testing (for this build of xbmc)

Everything's up to date.

XBMC log of session is here: http://xbmclogs.com/show.php?id=4704

The relevant part (where the refresh rate changes) is at lines 320-331.

mediainfo on the track being played in the log: http://xbmclogs.com/show.php?id=4705

[FernetMenta]

Please enable debug logging in advancedsettings.xml:

<loglevel hide="false">2 </loglevel>

[StrangeNoises]

at http://xbmclogs.com/show.php?id=4706

[FernetMenta]

In case your video file it correct this is a problem we inherited with last update of ffmpeg. The stream info reports 25fps which seems to be correct but ffmpeg guesses 50.17 (tbr). Hence XBMC picks a refresh rate >= 50.17 which is 60 in your case. After XBMC has detected a refresh rate of 50, it switches. You can define overrides in advanced settings and make XBMC choose 50 in case of values of e.g. 49 - 51 Check section adjustrefreshrate: http://wiki.xbmc.org/index.php?title=Userdata/advancedsettings.xml

[StrangeNoises]

hm. i don't mind doing that for myself, but I suggest the bug ought to be fixed, wherever it needs to be fixed and whomever it needs to be fixed by. :-) If it's going to do this for all High Profile (or derived presets) encodes from handbrake there's going to be quite a lot of users affected by this. In fact I'm affected less than I was: until recently nearly my whole library was encoded by handbrake, but I just recently moved to using the raw rips of stuff where I could and only encode stuff that xbmc couldn't play direct.

(talking of which with a new ffmpeg I should just check it still can't play the raw tvrips from bbc hd... though of course even if it can there's still a lot of legacy files around.)

[StrangeNoises]

well, the overrides seem to be being ignored. Log: http://xbmclogs.com/show.php?id=4707

Entire advancedsettings.xml:

<advancedsettings>
        <loglevel hide="false">2</loglevel>
        <adjustrefreshrate>
                <override>
                        <fpsmin>24.600</fpsmin>
                        <fpsmax>25.500</fpsmax>
                        <refresh>50.0</refresh>
                </override>
                <override>
                        <fpsmin>49.0</fpsmin>
                        <fpsmax>52.0</fpsmax>
                        <refresh>50.0</refresh>
                </override>
        </adjustrefreshrate>
</advancedsettings>

I guess I'm misunderstanding something...?

[FernetMenta]

The adjustrefreshrate settings have to reside in the video section of advanced settings.

[StrangeNoises]

duh! I'm better than that, honest. Usually. :-) Yes, that works for me now, except on the one tv show I was having the same issue with on Eden as well, despite its reported frame rate being within the range I defined. But that's a single, old, encode, so I'm not going to fret about it unless it turns out to affect more stuff after all.

[FernetMenta]

np :), I agree setup is still too complicated. I have never seen a regular refresh rate of 50.17. It should be nailed to 50 by default. If you cut out a short sample of that video which does not play well, I can look into it.

[FernetMenta]

Do I remember right that you have mentioned de-interlacing problems? This should work ok because this is my primary use case. But there was a problem when running without window manager. See #49. Scroll down the issue to the last couple of posts.

[StrangeNoises]

Yes it's me that's talked about interlacing/deinterlacing issues before. They're basically resolved for me now by virtue of no longer worrying about how best to deinterlace at encode-stage but instead just retain the raws (or encode to h.264-interlaced if source is unplayable vc1-interlaced) and play those with xbmc set to use VDPAU bob-deinterlace (and whether to deinterlace set to Auto so I don't have to turn it off all the time I want to watch a movie...) Essentially playback is effectively perfect for me now with almost everything.

I don't think it's what's at issue in this ticket though., given I was having the same issue with 25fps progressive (stuff that had been deinterlaced at encode-stage - sometimes years ago). In both cases, 25p and 25i content, it was failing to select the correct refresh rate at start of play. The hack into advancedsettings.xml works for me but it should probably be made to work automatically for everyone.

No window manager in use here - i log into xbmc directly from the lightdm screen.

On playing MPEG2 PAL interlaced sources (ie: DVD raw rips) I do get a bit of flicker on the left side of the top line and right side of the bottom line - it actually seems less pronounced now than ever - I might not have noticed if I hadn't been looking for it, but it's there. Always used to have this problem too when I'd encoded them to 25p using Handbrake, so I wonder if it's actually an ffmpeg issue with the decode stage, or if it's just an inevitable feature of interlaced content? Sometimes if it has annoyed me I just zoom the image in by one notch so that the top and bottom lines are off the screen. This may be the correct thing to do anyway as overscan/picture framing seems to be a bit of an issue with PAL DVDs.

I could go on (for which read: just deleted a paragraph where I did a bit) but I expect it's going offtopic for this issue. :-)

[FernetMenta]

Thanks for feedback. Can we close this issue? And the other one you opened?

[StrangeNoises]

I think I suggested closing the other one myself as I haven't been able to repeat it - and to date I still haven't. :-)

This one - it is still an issue that it doesn't select the right refresh rate without stuff in advancedsettings.xml. A few posts up you asked for a snippet of file to test, but you seemed to refer to the one that's still broken with the hack, and was broken on xbmc. I'm less interested in that as it probably is one odd file. What's more worrying is all the 25p/25i sources starting at the wrong refresh rate without those advanced settings, and that ought to be fixed.

I'm free (and a bit bored) now, so I'll test now that the problem still exists without advancedsettings.xml with the slightly newer build I'm running now (on the offchance...) and assuming not, I'll split off the first minute or so of something and uploaded it somewhere for you. Stand by.

[StrangeNoises]

correction, reminding myself as i was about to test with the wrong file. not all, just those with variable frame rate, handbrake's default output at High Profile.

[StrangeNoises]

I can't reproduce it now, except on that one file (actually a whole tv series; probably the oldest encode I have in my vault). I no longer have the handbrake-encoded 1080i files i observed before as (as previously mentioned) I've switched to just using the raws; and the period when I had the encoded-interlaced stuff from handbrake was so short that I still had all of the raw files they came from.

That said, I reported it also happening on 25p rips, of which I still have plenty, and I can't reproduce that now. They all play fine except for that one show.

So it's possible the bug has after all been fixed in a more recent build.

I will use handbrake to make a new encode of the same show i opened this issue with and check that it definitely is or isn't resolved. Even if it isn't though, my change of usage pattern (using the raw media and not handbraking everything) means it doesn't really affect me any more.

If you really want to chase the issue with the one older encode i do have this issue with, I can still produce an excerpt of that, though to be fair I'm prepared to consider that a probable bug in handbrake - or BBC's HD encoder - at the time.

Will report back in a little while with the results of the encode-and-test...

[StrangeNoises]

one finding: the problematic old encodes seem to be entirely fixed by remuxing them from .m4v to .mkv using mkvmerge. So for that one at least, the mpeg4 container format seems to be at issue. (This by the way also means I can't send a snippet anyway, as my tool for doing so is mkvmerge...)

Still testing with the new stuff.

[StrangeNoises]

same with a brand new encode. Encoded first 2 mins with handbrake to .m4v and it doesn't correctly switch refresh rate. Interestingly, unlike my original report, it doesn't ever switch to the right refresh rate, it just stays on default (60Hz in my case).

Can confirm problem also affects 25p-encoded version, where it does switch after a few seconds as previously reported.

Encode by the same handbrake, everything the same but output to .mkv and it switches perfectly at the start. So it would seem to be an mp4 container issue.

Remuxing from the .m4v to .mkv using mkvtoolnix also - as with the old files - fixes the issue.

(Renaming .m4v to .mp4 makes no difference.)

Going to upload the 2min 25p .m4v file for you now as that's the possibly common use-case that needs fixing.

[StrangeNoises]

Uploaded here: http://strangenoises.org/~rachel/xbmctesting/hollowcrown2-hb-25p-2mins.m4v

(NB: have annoyingly confirmed it's not affecting all hb-encoded 1080p@25 encodes, but definitely was the one linked above.

[FernetMenta]

Have to look into what we get from ffmpeg. According to the media info I think we should start with max framerate:

Frame rate mode : Variable Frame rate : 24.611 fps Minimum frame rate : 1.009 fps Maximum frame rate : 50.000 fps

[FernetMenta]

Can you post this info for a couple of other files? e.g. for the one with stated with 50.17.

[StrangeNoises]

interesting. Unfortunately I don't have the same actual files as I had when I opened this issue, however, don't forget I did paste up the mediainfo on that file in the first post; it's here: http://xbmclogs.com/show.php?id=4705. and you can see it shows:

Frame rate mode : Variable Frame rate : 25.000 fps Minimum frame rate : 1.870 fps Maximum frame rate : 25.000 fps

I note that the "Frame rate" figure on that showed as exactly 25.000, which led me to expect that to be reliable but I confirm on the one I sent you that I also see 24.611. Also odd to see that "Maximum frame rate" of 50.000fps on a (not-bob) deinterlaced video. I don't know what that's about at all. It's actually making me doubt that I did encode it the way I thought I had.

It would appear handbrake is being inconsistent. Not sure how but could be because I asked it just to encode the first two minutes for the tests I did last night; and the earlier test was full length? Everything else was the same...

For what it's worth, the raw source file these were all encoded from has:

Frame rate mode : Variable Frame rate : 50.000 fps Original frame rate : 25.000 fps

But that's an mkv muxed from the original MPEG2 transport stream. That shows just:

Frame rate : 25.000 fps

and none of the other fields exist.

NB: For those four fields, the interlaced encode I did last night (which should have been the same as the one in the originating post of this issue, being encoded with all the same settings) shows the exact same values as the progressive. ie:

Frame rate mode : Variable Frame rate : 24.611 fps Minimum frame rate : 1.009 fps Maximum frame rate : 50.000 fps

but shows scan type MBAFF and scan order Top Field First, rather than Progressive so definitely not the same file.

I then remembered that I had done the first encode from the mpeg2 transport stream, not from the mkv remux, so I did that again as I still had that transport stream file in my testing folder. However:

Frame rate mode : Variable Frame rate : 24.844 fps Minimum frame rate : 2.411 fps Maximum frame rate : 25.000 fps

So still inconsistent.

The m4v interlaced handbrake encode remuxed using mkvmerge to mkv has just:

Frame rate mode : Variable / Variable Frame rate : 25.000 fps

And the mkv interlaced generated directly by handbrake shows:

Frame rate mode : Variable / Variable Frame rate : 50.000 fps

It does seem to indicate that headline "Frame rate" figure isn't as reliable as it had seemed when I posted the first post opening this issue.

TBH it seems a bit of a mess, and it seems to revolve entirely around the MP4 container format, as all the problems go away when MKV is used instead. I'm now not sure what you could do to fix this.

Maybe MP4 is just broken. For instance, I was only encoding these with handbrake in the first place because if I just exported them from EyeTV with "Native formats, no re-encoding" it produced an unplayable .mp4 file. I had thought the BBC's h.264 encoder was producing something that xbmc just couldn't play well, but as a result of this issue I actually gave it a try first just playing the MPEG2 transport stream and then remuxing from that direct to mkv and xbmc played both perfectly (and the latter wasn't much bigger than the handbrake re-encodes anyway - BBC must be optimising heavily for bitrate).

That was the point at which I decided to switch to just retaining and playing the raw mkv-remuxes and deleted the handbrake encodes I'd done earlier for which the raws still existed. Which is why I don't have the file at the top of this issue any more. :-)

[FernetMenta]

I am inclined to blame Handbrake. It not only changes frame rate but codec.

ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.2 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames

ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.0 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames

We had lots of reports from users having complained that h.264 level 5.1 did not play on ATI. Bluray standards is 4.1. What Handbrake does is a no-go.

[StrangeNoises]

yes, it does seem to vary the profile doesn't it. Of the tests I've done all with the same versions at the same settings except for choosing interlaced or not, the profile ranges from High@L4.0, High@L4.2, High@L5.2.

The pattern seems to be (and remember the mkv source is just remuxed from the mp2ts source):

mp2ts source to interlaced it uses High@L4.0 mkv source to progressive it uses High@L4.2 mkv source to interlaced it uses High@L5.2

In all cases the source is High@L4.0.

shrug :-}

No idea what that's about. They all play perfectly on my xbmc/nvidia system except for this framerate issue which only exists if it's in an MP4 container - which could probably be fixed by my selecting a constant framerate in handbrake - i was deliberately trying to resolve a problem with the default. You choose settings to suit your playback device's capabilities of course. It's just using x264 underneath.

As for myself, after using it heavily for years I suddenly find myself no longer caring so much if handbrake does stuff right since i've gone to playing the raw media instead. The only encoding i now need to do is for VC1-interlaced content which handbrake can't do anyway - and when it can I wouldn't need it to because xbmc would be able to play them raw at that point anyway, given that's about ffmpeg supporting the input format.

However, discussion about the profile is probably off-topic for this issue about frame rates. Given that doesn't affect me any more because of moving off handbrake, I guess i've no objection to this issue being closed if it's not affecting anyone else either... I kind of assumed it would be. :-)

[StrangeNoises]

It turns out handbrake encodes according to the settings/preset used and gives it a format profile that encompasses the properties of the video track it's written wrt resolution, bitrate, reframes, frame-rate, this, that, the other, and probably the phase of the moon as far as I can tell! I think that probably accounts for the wandering profile/level values seen in these videos.

And the thing that's most likely to be pushing some of these videos' profile higher is the maximum framerate (as opposed to refresh rate at playback) being perceived as 50fps rather than 25fps. High@L4.0 and High@L4.1 max out at 1920x1080@30, so seeing that it's got a track with a max frame rate of 50, an apparent 1920x1080@50, would push it up to at least High@L4.2. which maxes at 1920x1080@64. There may be other factors I can't see that's pushed some of these up to High@L5.2. It only seems to have done that for the videos sourced from the MKV rather than the MP2TS. I don't know why, given the actual video track should be the same.

The fact that it sees a file with an apparent max frame rate of 50fps is presumably confusion introduced by the source being interlaced.

Confirmed that if I tell handbrake to use constant framerate and actually specify the framerate - 25 in this case - it produces a High@L4.0 m4v file that does not exhibit the initial-wrong-refresh-rate issue and plays perfectly. This was from the MKV source, so the exact same settings but with the default variable-same-as-source selected it wrote High@L5.2; so it definitely seems that nailing the frame rate down fixes it.

So in summary:

Your AMD users probably want to do the above - specify constant framerate and specify what that framerate is; that will resolve this issue and should also keep an otherwise High Profile Handbrake encode at High@L4.1 or less, given AMD hardware decode seems not to support higher than that.

That's a thing for the encode-stage. If one's trying to resolve this problem with existing encodes, any one of the following seems to resolve the initial-wrong-refresh-rate issue (but won't help those AMD users if the profile/level is too high):

• Set the refresh rate overrides in XBMC's advancedsettings.xml as discussed earlier in this thread.
• Remux problematic files to MKV using MKVToolnix.
• If encoding with handbrake (and not fixing framerate as above), select output format MKV.

Thing is, XBMC Eden and earlier at default settings didn't have any problems with the VFR files, so users are going to see this as a regression. But as you said right at the top, it seems to have come in with the latest ffmpeg, and the proper fix probably also lies with them.

It's not a problem for me any more though. :-)

[FernetMenta]

Thanks for the detailed information. The problem is that countless users are affected by this and they don't have your skills. They just transcode or rip their media on desktop PCs with I7 and wondering why it does not play nice on their HTPC running XBMC. What we need is some correction and educated guessing mechanisms to make that "bad" material play. But that's a bigger project on its own. I need to bring all my changes to mainline first which is quite challenging because this branch is already diverged by approx 10k lines of code. Once completed this task and nobody other volunteered for this project, I will take it :)

[StrangeNoises]

well, each of the user actions i listed above are pretty much what I'd advise users to do having this problem now. If they are encoding with handbrake and they know to come to a forum to ask, they can probably follow one of those instructions. They're a few steps up in skill from, eg: my sister and nephews who I think suspect their appletv is filled using magic. :-) But of course yes we'd want xbmc to be able to do the right thing automatically.

Perhaps a cheap way of doing it in the code would be to have xbmc default to the behaviour defined by the override rules above? Which is to say, essentially, sloppier framerate-to-refreshrate matching; at least around the PAL frame/refresh rates. That worked for me; essentially locking everything between 24.5fps and 25.5fps, and between 49fps and 52fps, to 50Hz.

You probably need to keep it tighter around the 24/30/60 ranges to make it properly select between eg: 59.94Hz and 60Hz for content. PAL doesn't have those fractional rates to worry about. Of course I've only seen this issue with PAL because that's where I live and it's affecting off-air broadcasts.

I had been wondering whether this branch is the most appropriate for me to be using now. It is working well for me now, but I'm not sure how much of that is because of what's in your branch and what's already in the mainline branch. (I was using 11.0 stable until I switched to this branch, so I hadn't started using the 12.x stuff at all yet.)

Looks like I stick with this one at least until you do that merge; which I'm afraid means any more problems and I come here too. :-P

[FernetMenta]

What you get with this branch is a complete re-write of vdpau, new interface to X11 (drop of SDL), XvbA (AMD, you probably not interested in), and many changes to video player and renderer. In uses buffering in order to be more resilient against any sort of delays. The version which is currently xvba testing ppa I use myself on the box in my living room. BTW: do you allow nice levels for the user you start XBMC? See step 5 in http://forum.xbmc.org/showthread.php?tid=116996

Without this audio thread can't get a higher priority. Even worse, there was a bug which caused audio to get a lower prio without this setting.

[StrangeNoises]

as playback with vdpau is working very well for me, then that seems worth sticking with, definitely. vdpau bob-deinterlace in particular is new, i think, and seems to work perfectly. I think the only playback issue i have now is one movie at exactly 24fps, which now seems to be trying to play on 23.97 because xrandr sees no 24Hz mode... but at least it's that way round now, rather than that one movie playing perfectly and all the other having the opposite glitch. :-) But that's another issue. Probably needs an exact 24Hz modeline set up.

I have also bumped up my cache size as I did have it run out and stop to buffer a couple of times. That said, at that time I was streaming over http from a dav source, and also over http from a Plex server via PleXBMC. Since then I've switched to using NFS and XBMC's own library handling (much improved from the last time I tried it, which drove me to plex). I don't think that caching has any effect over NFS, given the stats pane is now showing "Cache:0 B" :-) But it seems to be ok.

I did apply that nice change in step 5, yes. Also step 6 though not sure what I get from it. Not step 7: the dirty regions change causes me problems; namely often when i try to play a video i get the sound but it stays in the gui, and i have to quit and restart to clear it. I do have the step 9 changes (already did) Haven't needed to do anything after that, in the optional section.

[FernetMenta]

vdpau-Bob is actually not new. Did you activate the vdpau interop methods in video playback menu? With interop yuv de-interlacing can also be done by the renderer (bob). I renamed one method to vdpau-bob which is the same method you always had when using vdpau. Might work better now :) But bob is just basic quality. An ION2 can do temporal/spatial at 1080i@50 with this build. Does playback stuttering if you switch to the advanced methods temporal or temporal/spatial?

[StrangeNoises]

The interop settings are enabled (by default I think; not understanding them I don't think I would have enabled them deliberately)

Temporal & Temporal/Spacial fail badly, with massive stuttering and many, many lost frames. In the hundreds after only seconds of viewing.

(reminder; nvidia GeForce 320M here. Don't know how that relates to ION2. Driver 302.17 of course.)

VDPAU-Bob looks perfect. The build I first installed when I switched to this branch had a WeaveX2 which seemed to work well but had a little occasional stuttering, so switched back to VDPAU-Bob. That WeaveX2 setting seems to be gone now anyway.

[FernetMenta]

I had a brief look into the spec of gt320m. It should have at least the performance of ION2. It that an HP notebook? There are cases where faulty BIOS prevents PowerMizer from going to max performance level. Have you checked PowerMizer?

WaeveX2 is now weave and weave is dropped. The AUTO setting has never been auto, it just defaults to temporal. That brings up an idea for implementing a real auto method. It should automatically apply the best de-interlacing and scaling method and reduce to a lower level as soon it detects dropping. Another projects for more user friendliness.

EDIT: mac mini, right? Ugh, way too expensive. Compare this to Zotac ID80 which plays everything at highest quality.

[StrangeNoises]

It's a Mac Mini Server (Mid-2010) aka Macmini4,1

(XBMC/nVidia seems to work much better in Linux than OSX. Not least, newer nvidia drivers being available on linux and vdadecoder having issues; being unable to play interlaced content at all, for instance. And PGS subs causing crashes.)

powermizer:

rachel@rarity:~$ DISPLAY=:0 nvidia-settings -q GPUPerfModes -t perf=0, nvclock=405, memclock=1064, processorclock=405 ; perf=1, nvclock=450, memclock=1064, processorclock=810 ; perf=2, nvclock=450, memclock=1064, processorclock=810 ; perf=3, nvclock=450, memclock=1064, processorclock=950

No options for it in xorg.conf. Don't know how to ask it what setting it's actually on.

I am failing to google an adequate description of what Temporal or Temporal/Spatial deinterlacing actually does, when it works. :-)

Bob at least seems to have the virtue of being the closest you can get to straightforward interlaced playback (as if i was actually just playing the blu-ray or watching tv normally) on a progressive display. And tbh it looks indistinguishable to me and I've been pretty happy with it. So I'm looking forward to whatever unimagined improvement on the original I'd get with temporal/spatial when i get it working. ;-)

btw the content i tried it on yesterday was a programme that starts with a sequence of left-to-right pans across scenic settings, such that if you don't deinterlace at all the entire frame is filled with combing artifacts.

[FernetMenta]

Bob de-interlacing only looks at the current field and creates a frame out of a single field. This version of vdpau uses 4 past and 2 future fields when doing temporal or temporal/spatial. It uses the information of all those fields to reconstruct the missing information. There is a huge difference in quality. Watching e.g. a tennis match using bob is no fun if you are used to better quality. I use XBMC primarily for watching TV and de-interlacing (temporal/spatial) is much better than a TV does.

So you have three performance levels. You can query the current level with nvidia-settings. Does it go up to 3?

[FernetMenta]

Can you run qvdpautest and post the output?

[StrangeNoises]

i seem to have no such command qvdpautest; what do i need to install? :-)

tried logging into ubuntu2d to run nvidia-settings and set powermizer to prefer highest performance, and saved settings; but logging back into xbmc it didn't seem to help. On logging back into ubuntu2d and looking at nvidia-settings it seemed to be back onto adaptive. Looking at the .nvidia-settings.rc file, I don't see the setting.

About to try running xbmc in ubuntu2d while nvidia-settings is actually up and has the maximum-performance setting visibly enabled...

[StrangeNoises]

... at which Temporal loses about 30 frames at start of playback but then seems to settle down and behave. Temporal/Spatial still quite glitchy but better than before.

(What's the difference between Temporal and Temporal/Spatial?

[StrangeNoises]

(i meant unity2d of course...)

[FernetMenta]

I haven't tried for quite a while but it should still work.

apt-get update apt-get install qt4-qmake qt4-dev-tools libvdpau-dev libvdpau1

cd /data/installfiles/qvdpautest wget http://hftom.free.fr/qvdpautest-0.5.1.tar.gz

cd /tmp tar -xzf /data/installfiles/qvdpautest/qvdpautest-0.5.1.tar.gz cd qvdpautest-0.5.1/ qmake make

[StrangeNoises]

nb: found a way to 'turn powermizer off' in xorg.conf which seems to work. but on longer examination, Temporal still seems glitchy after all.

installing qvdpautest...

[FernetMenta]

Zotac ID 80:

qvdpautest 0.5.1 Intel(R) Atom(TM) CPU D2700 @ 2.13GHz NVIDIA GPU GeForce GT 520M (GF119) at PCI:2:0:0 (GPU-0)

VDPAU API version : 1 VDPAU implementation : NVIDIA VDPAU Driver Shared Library 302.17 Tue Jun 12 16 :27:11 PDT 2012

SURFACE GET BITS: 192.315 M/s SURFACE PUT BITS: 162.462 M/s

MPEG DECODING (1920x1080): 157 frames/s MPEG DECODING (1280x720): 408 frames/s H264 DECODING (1920x1080): 128 frames/s H264 DECODING (1280x720): 212 frames/s VC1 DECODING (1440x1080): 83 frames/s MPEG4 DECODING (1920x1080): 130 frames/s

MIXER WEAVE (1920x1080): 533 frames/s MIXER BOB (1920x1080): 834 fields/s MIXER TEMPORAL (1920x1080): 240 fields/s MIXER TEMPORAL + IVTC (1920x1080): 153 fields/s MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 315 fields/s MIXER TEMPORAL_SPATIAL (1920x1080): 101 fields/s MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 80 fields/s MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 113 fields/s MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 343 fields/s MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 206 fie lds/s

MULTITHREADED MPEG DECODING (1920x1080): 175 frames/s MULTITHREADED MIXER TEMPORAL (1920x1080): 187 fields/s

[StrangeNoises]

qvdpautest 0.5.1 Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz NVIDIA GPU GeForce 320M (C89) at PCI:5:0:0 (GPU-0)

VDPAU API version : 1 VDPAU implementation : NVIDIA VDPAU Driver Shared Library 302.17 Tue Jun 12 16:27:11 PDT 2012

SURFACE GET BITS: 944.473 M/s SURFACE PUT BITS: 942.325 M/s

MPEG DECODING (1920x1080): 79 frames/s MPEG DECODING (1280x720): 175 frames/s H264 DECODING (1920x1080): 47 frames/s H264 DECODING (1280x720): 95 frames/s VC1 DECODING (1440x1080): 62 frames/s MPEG4 DECODING (1920x1080): 53 frames/s

MIXER WEAVE (1920x1080): 514 frames/s MIXER BOB (1920x1080): 800 fields/s MIXER TEMPORAL (1920x1080): 79 fields/s MIXER TEMPORAL + IVTC (1920x1080): 73 fields/s MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 79 fields/s MIXER TEMPORAL_SPATIAL (1920x1080): 73 fields/s MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 68 fields/s MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 73 fields/s MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 268 fields/s MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 174 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 59 frames/s MULTITHREADED MIXER TEMPORAL (1920x1080): 47 fields/s

... that bottom-most reading looks like what i'm seeing: it's just not up to temporal at 50 fields/second - and of course i've got some stuff thats 1080i@60 too...

[FernetMenta]

Try watching PowerMizer perf level while running qvdpautest. Does it switch to highest level?

[StrangeNoises]

of course this line

H264 DECODING (1920x1080): 47 frames/s

is also why the files where i'd done the bob-deinterlace at the encode stage - which worked on the Plex system (on newer mac) I had before, don't work on this box

I had it set on maximum performance before starting the test but the window was obscured while the test ran so, while i expect it stayed there I need to do it again to guarantee that. :-) hang on...

[FernetMenta]

That's interesting, why does it perform that bad when it comes to multi-threading.

There is the following setting in advancedsettings under video. Set to true and will skip chroma de-interlacing for HD material. vdpauHDdeintSkipChroma

[StrangeNoises]

yes, the performance level isn't changing as the test runs. It's on maximum. However, I'm reviewing the xorg.conf change I made earlier, which may not be correct.

[FernetMenta]

yes, the performance level isn't changing as the test runs

What does that mean? Would it switch to highest level when you set preferred mode to max?

[StrangeNoises]

i mean, i'd set it to "prefer maximum performance" before starting the test, the highlighted line was the maximum, perf=3; and it stayed there for the duration of the test.

It seems the xorg.conf setting was correct enough (was cribbed from a laptop config, but changes made while referring here http://tutanhamon.com.ua/technovodstvo/NVIDIA-UNIX-driver/ for an AC-only machine I don't think really amounted to anything; but following advice there have also rebooted... Despite that it is still reporting that it's on adaptive on nvidia-settings but the actual performance level that's active is the maximum.

almost no difference to qvdpautest figures. Some of the MIXER tests are a couple of fields/sec better but that's all, and probably just natural variation. Trying that chroma thing...

[FernetMenta]

The perf levels don't differ that much on your system: This is an ION2:

perf=0, nvclock=405, memclock=405, processorclock=810 ; perf=1, nvclock=535, memclock=790, processorclock=1230

Yours: perf=0, nvclock=405, memclock=1064, processorclock=405 ; perf=1, nvclock=450, memclock=1064, processorclock=810 ; perf=2, nvclock=450, memclock=1064, processorclock=810 ; perf=3, nvclock=450, memclock=1064, processorclock=950

Maybe Apple don't let it go full speed because of cooling issues.

[StrangeNoises]

... although i notice in the test results the SKIP_CHROMA variant figures were no better than without. And with that skipchroma setting I see no improvement. :-(

OK, what hardware are you using? It's atom-based I see; is it a self-build or a specific nettop product? I'm probably not in a position to buy new hardware at the moment - and have been happy with bob up until now anyway :-P - but for future reference...

[StrangeNoises]

thing is, i think it's only marginally failing, so the relatively small rise in those values between your perf=1 and my perf=3 may well be enough. your qvdpautest readings certainly show much better figures for the tests, except bizarrely the SURFACE GET/PUT BITS ones...

[StrangeNoises]

ah, i've found the Zotac ID 80. I thought they just did graphics cards. (in fact i have one in a machine upstairs - lower-spec gt210 iirc) :-)