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 : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames

ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
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 [email protected], [email protected], [email protected].

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

mp2ts source to interlaced it uses [email protected]
mkv source to progressive it uses [email protected]
mkv source to interlaced it uses [email protected]

In all cases the source is [email protected].

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. [email protected] and [email protected] 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 [email protected]. which maxes at 1920x1080@64. There may be other factors I can't see that's pushed some of these up to [email protected]. 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 [email protected] 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 [email protected]; 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 [email protected] 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]

not the bbc's fault: ITV1 HD's output shows the same issue.

[FernetMenta]

Here is a new sample: http://dl.dropbox.com/u/47522966/1920x1080i-50.ts
Don't blame me for the content :)

[StrangeNoises]

i call shenanigans in a german changing room!

ok, I made a mistake above: When I said the track with the audio stripped out worked, i was lying; I'd forgotten to set the interlacing type to Temporal/Spatial, it was still on bob. With it set to Temporal/Spatial it shows the problem described.

So does your new sample - again, on its own, no audio, transcoded via handbrake, and with aac sound remuxed from that back to the original video - all exactly the same deinterlacing problem.

[StrangeNoises]

transcoding (with handbrake) your new sample down to 1440x1080 anamorphic (like your first sample) makes it happy; though cpu usage (on both cores) is higher, it's not maxed out; closer to 50% each. The D line in the CodecInfo pane is too long and the dropped frame count can't be seen, but it looks ok in playback.

Needless to say I'd rather keep Bob than transcode to a lower resolution. :-) But we're testing; and this is the only real pattern where a feature of the video stream is affecting the output; and it's the most obvious one of course: size. it's not handling 1920x1080 (storage dimensions - it handles 1440x1080 anamorphically displayed at 1920x1080). that also does suggest that all i need is a gfx card with a bit more oomph.

unsurprisingly, it's very happy to play SD content (576i@50 dvd-rip of 1970s bbc studio-bound production) with Temporal/Spatial.

Transcoding my 1080i-60-raw-bluray-001 test to 1440x1080 anamorphic works with Temporal/Spatial too.

[StrangeNoises]

oddly it does seem to be linked to dimensions rather than complexity, bitrate, anything like that. it'll happily deinterlace temporal/spatial a complex, fast-moving 1440x1080 but loses frames even when showing a static test card, or black, at 1920x1080. (in fact i think it loses more on black than when there's something going on.)

[FernetMenta]

I played the 60i sample on the ION2

vdpau bob: CPU load approx. 25%
temporal: 40-60%
temporal/spatial 90-120%

It seems that a maxed out GPU affects the CPU. Maybe the CPU threads do a busy wait if they are not able to deliver data to the GPU.

So, to summarize:
We can't tell the performance of a GPU just by the model. 512MB is highly recommended.
I am not sure what makes you model of a GT218 perform lower than mine. Is it DDR3 to DDR2 or better DMA capabilities on the ID11.

[StrangeNoises]

On 19/07/2012 16:40, Rainer Hochecker wrote:

I played the 60i sample on the ION2

vdpau bob: CPU load approx. 25%
temporal: 40-60%
temporal/spatial 90-120%

It seems that a maxed out GPU affects the CPU. Maybe the CPU threads do a busy wait if they are not able to deliver data to the GPU.

So, to summarize:
We can't tell the performance of a GPU just by the model. 512MB is highly recommended.
I am not sure what makes you model of a GT218 perform lower than mine. Is it DDR3 to DDR2 or better DMA capabilities on the ID11.

I don't know, that's why i was asking how one finds out...
nvidia-settings doesn't reveal it

Rachel

---

Reply to this email directly or view it on GitHub:
#52 (comment)

[FernetMenta]

nvidia-smi was used to provide useful information like GPU utilization but most parameters are not available anymore. So I don't know either.

[StrangeNoises]

have placed an order for a GT520 for the big box. that's definitely 1GB DDR3. Couldn't find box/manuals for the GT218, couldn't find a way to detect it insystem. but basically the latest results do point to the GPUs just being maxed out doing it with 1920x1080 sources. i did try nvidia-smi, but it didn't give that information

[FernetMenta]

A friend of mine recently built a system with a GT520 low profile. Hopefully it does work for you as well, otherwise we have to dig deeper.

[StrangeNoises]

well it was looking for a while like there might be some systemic problem or misconfiguration (considering both machines were experiencing it). We might be back to that if this doesn't work :-) that's partly why i just bought the card, which is cheap, rather than a whole zotac id80, which is more than i want to go for right now; but i expect if it works that id80 will be a future purchase.

At the moment, however, from the tests I've done where it worked, I can't honestly say it looked startlingly better than bob. But I expect it'll be one of those things: once i've watched stuff with temporal/spatial for a while, i'll notice it if i try to go back. :-) Our expectations always ratchet up.

[StrangeNoises]

big box carried downstairs, new GT520 put in it, set up (fresh ubuntu 12.04 install; i think my quantal setup was sick)... all test material (including the 1920x1080i@60) plays perfectly with Temporal/Spatial deinterlacing.

Am glad I built this machine to be quiet - and i found a fanless GT520 to put in it too, which helps.

One niggle but i don't think it's anything to do with xbmc though might be to do with the xorg.conf: lightdm crashes the machine when you log out. Which is a bit alarming. but once actually logged into xbmc it seems to work perfectly.

NB: the TV shows up as DFP-1 on this fairly standard graphics card too, so it's not just a mac hardware thing.

[StrangeNoises]

looks like i fell afoul of this http://phoronix.com/forums/showthread.php?70619-Logout-freeze-using-Nvidia-Proprietary-driver-(latest-and-even-older-versions)&p=276076#post276076

Workaround applied; I have a happy system. :-)

[FernetMenta]

Great! Welcome to the club of users who can enjoy 60i at high quality.

[FernetMenta]

Checkout ffmpeg logs for the last 2 days: http://git.videolan.org/?p=ffmpeg.git;a=shortlog
vc1 field mode is getting fixed.

[StrangeNoises]

I haven't seen a recurrence of this issue for the last year, though I can't be sure whether that's because it's a solved issue or I just don't encounter those files any more. fritsch says you're looking to spring-clean old open issues, so as far as I'm concerned, I'm ok with this being closed. everything is in far later versions now, so even if it does appear again might as well report anew.

[StrangeNoises]

just confirming with some recently handbraked m4v content; i can't reproduce this now.

[newphreak]

I can still reproduce this "issue" with anime series with variable fps.

[StrangeNoises]

well, i lost, um, basically all of my older encodes in a disk failure a little while ago. (Repeat after me: RAID is not backup, doubly so while reshaping.) New encodes, while still showing variable frame rate in mediainfo, certainly don't seem to have this problem. It may have been a bug fixed in handbrake or a library it depends on in the intervening time. Can you post up a file that demonstrates it and I can see if I have a problem with it? (Understand it may be necessary to post the whole file as, scanning back over this thread, it looks like the problem went away if it was mkvmerged, as I'd normally do to extract a clip for upload.

Also of course I'm now running the pre-gotham stuff. And it looks like it was this issue/thread that ended up with me going on to just retain and play the raws rather than transcoding stuff anyway, but by the same token it looks like it went way offtopic.

[newphreak]

http://hwat.be/variable.fps.mkv

[StrangeNoises]

dunno whether it's my download rate or your upload rate that sucks tonight (probably the former) but that's going to take another hour to come down.

In any case, reminder again that the original issue reported this happening with MP4 or M4V files, and extracting or remuxing them to MKV made the problem go away, so for me that was actually my workaround solution at the time. (I also remember now some months later looking at those mkv files and wondering why I'd remuxed them, I'd forgotten all about this!) So even if this file shows a problem, it may in fact not be the same problem. But confirm do you experience the problem WITH THAT FILE? the one you uploaded, not the one it was clipped from?

[StrangeNoises]

it's down, and i can also see in mediainfo that it's actually constant frame rate mode.

But I see it does exhibit similar behaviour: Playback starts at 60Hz (in my case having to switch to that as it's not the default in the GUI), then corrects itself after a few seconds.

I don't know. The symptom looks similar to the issue I used to have, but it's not the same kind of file that I used to experience it on so the cause may be different. So I guess I'll still leave it that I'm OK for the issue to be closed. But you may want to open a new one.

[newphreak]

I'll let Rainer test and decide what he wants to do
On Dec 11, 2013 12:06 AM, "StrangeNoises" [email protected] wrote:

it's down, and i can also see in mediainfo that it's actually constant
frame rate mode.

But I see it does exhibit similar behaviour: Playback starts at 60Hz (in
my case having to switch to that as it's not the default in the GUI), then
corrects itself after a few seconds.

I don't know. The symptom looks similar to the issue I used to have, but
it's not the same kind of file that I used to experience it on so the cause
may be different. So I guess I'll still leave it that I'm OK for the
issue to be closed. But you may want to open a new one.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-30277929
.

[FernetMenta]

yes, most of this anime has variable frame rate and no standard fps set to start with. As a result player can't switch when playback is started. Probably it would be best not to switch at all for this kind of material but the problem is we have no proper detection for it. Not sure whether it can be detected reliable.

There are videos starting with a trailer and after a short while switching of refresh rate is desired.