Refresh-rate switching happens late where variable frame rate #52

Open
StrangeNoises opened this Issue Jul 9, 2012 · 152 comments

Projects

None yet

4 participants

@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
Owner

Please enable debug logging in advancedsettings.xml:

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

@FernetMenta
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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
Owner

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) :-)

@StrangeNoises

that atom is actually dual-core but iirc all atoms also have hyperthreading, whereas the core 2 duo doesn't; so despite your lower clock speed you probably will get better threading than me. Linux will see four cores and knows what to do with them. :-)

Can't believe this mac is so obsolete already! :-( (well, it's fine if i decide to be happy with vdpau-bob...)

@StrangeNoises

Temporal/Spatial (half) is within its limits and looks pretty good for interlaced but not telecined sources (which show jerky motion). not sure it's an improvement on bob even on the others. It probably is for content that doesn't really need deinterlacing anyway (ie: bbc's propensity for broadcasting and shipping on bluray everything interlaced even though it's probably filmed on progressive.)

@FernetMenta
Owner

It's not the hyperthreading. The following qvdpautest is from a Zotac ID11, ION2 with Atom D525:

qvdpautest 0.5.1
Intel(R) Atom(TM) CPU D510 @ 1.66GHz
NVIDIA GPU ION (GT218) at PCI:3:0:0 (GPU-0)

VDPAU API version : 1
VDPAU implementation : NVIDIA VDPAU Driver Shared Library 295.40 Thu Apr 5 22:02:06 PDT 2012

SURFACE GET BITS: 193.721 M/s
SURFACE PUT BITS: 161.867 M/s

MPEG DECODING (1920x1080): 68 frames/s
MPEG DECODING (1280x720): 161 frames/s
H264 DECODING (1920x1080): 66 frames/s
H264 DECODING (1280x720): 122 frames/s
VC1 DECODING (1440x1080): 83 frames/s
MPEG4 DECODING (1920x1080): 67 frames/s

MIXER WEAVE (1920x1080): 483 frames/s
MIXER BOB (1920x1080): 675 fields/s
MIXER TEMPORAL (1920x1080): 190 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 121 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 254 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 65 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 53 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 72 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 230 fields/s
MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 121 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 70 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 165 fields/s

It plays 1080i@50 temporal/spatial without problems. Again the multi-threaded behavior is much better than on your GT320M. Either the nvidia driver is not optimized for gt320m, it's the chip itsel, or the way Apple has wired it. Don't know.
Even on my outdated mobo with an GT9300 onboard graphics I can play 1080i temporal without problems.

I have a couple of test systems here sponsored by Zotac. My favorite is the ID80. I do most of my development on this machine and I recommend it to my buddies if they want to build a HTPC.
I am going to replace my living room system with is a custom build. Will use Zotac D-2700-itx board which is basically the same as ID80 but has a pci-e slot I can use for a tv card.

@StrangeNoises

i might go the mini-itx version too with that equivalent board; just looking it up now. not afraid of self-builds, so if i can make it cheaper without making it horrid that way i might. (zotac's own case isn't exactly a looker after all; not for someone used to macs...)

Will be playing with shopping baskets now for the rest of the day i expect ;-) but there's no great rush as vdpau-bob will keep me satisfied for the time being, until the quest for perfection outweight budgetary considerations anyway. :-)

we're way offtopic for this issue now of course. :-)

@FernetMenta
Owner

we're way offtopic for this issue now of course. :-)

Well, this is my repo and nobody should blame us :)

BTW: how much memory have you configured for the GPU?

I am going to use Steacom FC8 as a case. Accoring to the spec the Zotac board does not fit but I hope I can make it fit somehow :)

@StrangeNoises

i haven't explicitly set any memory config on the GPU. Not sure how (about to look at nvidia-settings). If it's a bios thing it probably won't apply on a mac.

nvidia-settings says it has 256MB.

@FernetMenta
Owner

This might be the root cause. It should have 512MB. Don't you have a BIOS setting to configure GPU ram?

@StrangeNoises

it's a mac. it has an apple-flavoured efi and a basic bios emulation mode. :-) The more memory it has the more it gives to the GPU, automatically, but this seems to top out at 256MB. (The machine has 8GB RAM total.) Am still googling for ways to take more control of that but not sure such ways exist. In between reading zotac id80 reviews and costing things. so far i've got a mobo+case combo that's only 80 pence cheaper than the cheapest id80 i've found... :-}

@FernetMenta
Owner

http://support.apple.com/kb/SP585
NVIDIA GeForce 320M graphics processor with 256MB of DDR3 SDRAM shared with main memory

Well done Apple :( Designed for the wrong planet.

@FernetMenta
Owner

weird:

Memory available to Mac OS X may vary depending on graphics needs. Minimum graphics memory usage is 256MB

would it increase VRAM if you increased RAM?

@StrangeNoises

it does, but it has already, given this machine has 8GB; apparently 256MB is the maximum it goes to. I can't find anything that lets me override that.

@FernetMenta
Owner

I would have done a qvdpautest on a machine with 256MB vram but I can't reduce on my systems. I think if you can manager it to get have more vram available running Linux it will boost performance.

@StrangeNoises

i think i shall just admit that vdpau-bob is the best i'll get on this system - and as i haven't actually seen better, I won't feel that I'm missing out. And when my bank balance is a bit better (telling myself not to spend money I can avoid until I can end a month without an overdraft), I expect I'll get a Zotac ID80.

@StrangeNoises

hmm. i have a GT218 in my "big box" core-i7x4 pc that I suddenly no longer use for video encoding. It'll be a bit of a chore to lug it downstairs, and it's a bit noisy for a living room (though not too bad considering it's got 6 mechanical hard drives in it; it's in a good quiet case). I had just presumed the GT218 wouldn't be sufficiently capable but you're suggesting it is (which makes the 320M not being more of a surprise), so I can try this out for zero cost. Then of course if Temporal/Spatial deinterlacing really is that much better i won't be able to go back to just bob, and I'll have to buy a more sensible living-room box. :-}

That machine is already running the quantal alpha but it doesn't really need to, so if the precise builds for xbmc-xvba-testing don't work out I'll just have to reinstall... Well, that's my evening sorted. Phew. :-)

i'll run the qvdpautest on it before trying to move it downstairs...

@FernetMenta
Owner

Well, your mac mini has a core duo. Have you tried software decoding with yadif de-interlacer?

I have googled a bit but I have to admin that (U)EFI is greek to me. Nevertheless I do think it should be possible to hack it to get more vram.

@StrangeNoises

hm. the version of qvdpautest you linked doesn't build on quantal. the up to date version builds but apparently hangs during its first test.

i'm fairly sure when i tried before the mini wasn't up to doing the decodes in software only; but it was long enough ago that i'm not sure now what i tried and software updates might have improved things since anyway.

trying to get xbmc working; it's being recalcitrant...

@StrangeNoises

testing your build of xbmc (same as i've been using) on the "big pc" (core-i7x4 3.07GHz; ubuntu quantal alpha 64-bit (includes nvidia 302.17), GT218) - albeit just on a normal 1080p monitor fixed at 60Hz (dell u2311):

I seem to be getting exactly the same behaviour even though it's quite a different card. That is, Temporal marginally works on some sources (some 1080i@50), and suffers significant frame-drops on others (1080i@50 and 1080i@60), with the threshold between the two seemingly about the same; Temporal/Spatial just loses lots of frames on everything, same as the GT320M.

Of course this machine has shedloads of cpu power, so turning VDPAU off completely works pretty well too; with the default deinterlacing method seemingly working well, though not sure what that is. I suspect it's bob, as it seems to just work on everything. :-)

"Deinterlace" (whatever that is; user interface doesn't specify) works at 1080i@50 but loses frames at 1080i@60. When I look at the deinterlacing options, "yadif" isn't there. "bob" is of course, and works as well as it does anywhere. "weave" is present, but I still end up with plenty of visible combing artifacts so it's presumably not doing what I hoped.

(I also note during playback with these deinterlacing options enabled, only one CPU core seems to be at work. Oh actually it's the same during vdpau playback too so I guess that's not playback-related.)

I'd probably have to downgrade this machine back to precise to eliminate any quantal oddities and run qvdpautest; but I'm not going to take that plunge today.

@FernetMenta
Owner

I think "deinterlace" is yadif but not completely sure. I haven't done much with software decoding. How is the quility with this option?

How much video ram does that GT218 have? 512 or less?

Do you boot Linux on the mac in efi or bios mode? Does NVidia driver work in efi mode? Sooner or later that efi stuff will hit us all.

@StrangeNoises

the binary of qvdpautest built on the mac runs on the quantal pc:

qvdpautest 0.5.1
Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
NVIDIA GPU GeForce 210 (GT218) at PCI:3: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: 1144.14 M/s
SURFACE PUT BITS: 1186.05 M/s

MPEG DECODING (1920x1080): 72 frames/s
MPEG DECODING (1280x720): 162 frames/s
H264 DECODING (1920x1080): 64 frames/s
H264 DECODING (1280x720): 130 frames/s
VC1 DECODING (1440x1080): 83 frames/s
MPEG4 DECODING (1920x1080): 72 frames/s

MIXER WEAVE (1920x1080): 288 frames/s
MIXER BOB (1920x1080): 477 fields/s
MIXER TEMPORAL (1920x1080): 135 fields/s
MIXER TEMPORAL + IVTC (1920x1080): 88 fields/s
MIXER TEMPORAL + SKIP_CHROMA (1920x1080): 179 fields/s
MIXER TEMPORAL_SPATIAL (1920x1080): 60 fields/s
MIXER TEMPORAL_SPATIAL + IVTC (1920x1080): 46 fields/s
MIXER TEMPORAL_SPATIAL + SKIP_CHROMA (1920x1080): 67 fields/s
MIXER TEMPORAL_SPATIAL (720x576 video to 1920x1080 display): 211 fields/s
MIXER TEMPORAL_SPATIAL + HQSCALING (720x576 video to 1920x1080 display): 127 fields/s

MULTITHREADED MPEG DECODING (1920x1080): 62 frames/s
MULTITHREADED MIXER TEMPORAL (1920x1080): 92 fields/s

The decoding figures are slightly better but the mixer and multithreaded tests are still significantly worse, even on this beast of a machine. That said it looks like it ought to be able to do temporal, though temporal/spatial at 60 fields/s is touch-and-go.

@FernetMenta
Owner

Hmm, looking at this numbers I would expect temporal to work with all media. Does this card have 512MB?

I will install the ppa version on my ION2 tomorrow an run some tests.

@StrangeNoises

Making my eyes bleed (metaphorically) staring closely at the monitor the way i won't at a tv; i think "deinterlace" might be marginally better. Not so much as to seem worth the effort. :-)

Using that method on the 1080i@60 sources gets me lots of frame drops. What I see during this time is that one CPU core is working harder while the rest are idle, so the process presumably isn't well multithreaded. But even then it's not exactly thrashing its heart out. It varies a lot but I don't see it exceeding 90%, and the frame drops don't seem correlated at all to when it peaks.

I just had a thought: The 1080i@60 sources I speak of are telecined at source: There was a period when the BBC, who make all their material at 1080i@50, were mastering blurays with the videos telecined up to 1080i@60, presumably for an international market. They don't seem to do it any more, thankfully, at least for the ones they sell here, but they made some otherwise very nice bluray products during that period. Doctor Who season 4 specials, David Tennant's Hamlet, Ganges, Cranford, and some others, that I'm motivated to have play well.

I've never been able to adequately detelecine them so eventually I just decided to preserve the interlacing and let them play as intended, at which - with bob at least - they play well. But I wonder if that might be giving grief to some of the more advanced deinterlacing methods.

Video RAM in the GT218: 1024MB.

Linux on Mac is booted in BIOS mode. The steps to make it boot in EFI mode are tricky and hard to back out of if it goes wrong, and it was such a nightmare getting Linux onto that machine in the first place (mostly in being able to boot an installer) that I don't want to risk having to do it again!

@StrangeNoises

back downstairs and with vdpau off the mac mini definitely doesn't have the oomph. serious frame loss on bob-deinterlace of 1080i@50 correlated with a CPU core hitting 100% a lot. The other core's usually pretty quiet so that might be fixed with more multithreading in the code maybe... ;-) But even so we're still just talking about bob, which is a solved problem with vdpau. "Deinterlace" is worse in the same way (more consistently losing frames, more consistently with one core stuck at 100%).

@FernetMenta
Owner

ffmpeg supports multi-threaded decoding but we have not activated it yet. It breaks the hw decoders.

I have no 1080i@60 video which is telecined using 3:2 puldown but AKAIK this should play as 23.97. vdpau can do IVTC when enabled in advanced settings but this will eat additional resources. It just tries to detect if 2 fields are taken from the same frame. If so, it disables de-interlacing. This setitngs only works with temporal or temporal/spatial.

Will try to record a sample e.g. a football game for you to test this week.

My ID11 (ION2) is very close to its limits when setting to temporal/spatial. Sometimes when bringing up the codec or info screen it start dropping.
I am still confused by your qvdpautest of GT218.

@StrangeNoises

ah you misunderstand; the 1080i@60 video isn't telecined up from 23.97 using 3:2 pulldown. this would be easy to deal with; i'd detelecine at encode stage; as most of these are also VC1 and thus can't be played in the raw anyway. It's telecined up from 25fps content that may or may not originally have been interlaced in its own right. It's hideous. So far the only way I've been able to play them back without a sickening jerky motion is to just preserve the interlacing as is and play with bob-deinterlace. Any other method has to work at least as well as that. :-) So far Temporal sorta-justabout works for me on at least some 1080i@50 content but fails badly at these telecined 1080i@60.

I can upload an example or two...

@FernetMenta
Owner

I can upload an example or two...

Please do

VC1 and thus can't be played in the raw anyway

We do support VC1, don't we?

@StrangeNoises

not if it's interlaced. :-) All this is all about interlaced stuff. I have a load of VC1-progressive movies that play perfectly, yes.

It's coming. I see it now tries and fails badly rather than refuses to try, but as things stand I have to encode VC1-interlaced content using RipBot264 on Windows (for access to the windows media codecs - it's essentially a front-end to avisynth and friends and x264). But I do so preserving the interlacing of the original. When ffmpeg can deal with VC1-interlaced by itself, I'll be ditching the encodes in favour of the raws, but I imagine this issue will still exist because the interlacing/telecining is the same.

Examples are uploading. My uplink is slow so it's taking a while (currently saying ETA 2 hours 13). I'll put a link here when it's up. It's four 2-minute clips from the start of the videos I've been testing with all this while.

@fritsch

@VC-1: We should support interlaced here. At least, we do the mapping:
pic_descriptor->sps_info.vc1.interlace = v->interlace;

@StrangeNoises

unless the required changes to make it work have been added to the build in the last few days i assure you it doesn't work. :-) VC1-interlaced support in ffmpeg has been a bugbear for years. It looks like there has been progress recently, and as I said, the above mapping is probably why it even tries, but it doesn't work. Sound works, but there's massive corruption on screen. The same with other ffmpeg-dependent applications, eg: VLC and Handbrake which will now often crash when trying to play VC1-interlaced instead of just refusing to touch it; but sometimes work just well enough for you to be able to see what's playing, while not actually playing it in a watchable state.

I can add a raw VC1-interlaced example too if you like; one of the ones from which one of the other examples i'm already uploading is derived.

@StrangeNoises

confirmed; current build in this branch (Jul 13 2012) doesn't play them properly, but does try. Looks better with VDPAU off (on sufficiently powerful machine) but only manages about 8fps on a core-i7x4@3.07GHz and I think it's confused about fields. With VDPAU on screen mostly black with glitches and blocks appearing top-left.

@fritsch

One example to reproduce it would be enough. I think that it does not get the mapping right. Sometimes it is not enough to fetch the data out of the VC1-Context, rather one has to look through the mpeg context.

Ouhh - sorry. I am off topic, I thought about XVBA, sorry.

@StrangeNoises

it's all right, this issue went way off its own topic some time ago. FernetMenta seems happy with it. :-)

But yeah, this is an ffmpeg decoding issue i wasn't expecting to get addressed here. :-)

@fritsch

Hehe, it is nice to follow this thread, as it reveals a lot of knowledge concerning the different nvidia chips. I only read with one eye about the VC-1 Codec and did not remember the hwaccel anymore - so you got an answer for XVBA.

Thx for the testfiles anyways - I will try them on AMD xvba.

@FernetMenta
Owner

I checked ffmpeg repo. There's been some patches regarding vc1 de-interlacing recently. I can try to backport them as soon as I have a sample.

@StrangeNoises

Uploading is progressing at a stately but fairly steady 113K/s :-|

@StrangeNoises

uploaded: http://strangenoises.org/~rachel/xbmctesting/deinterlace-testing/ - hopefully filenames are self-explanatory without being too long.

@fritsch

@StrangeNoises:
Thx for the samples. On XVBA all work fine - with the XVBA bob deinterlacer. But VC-1 seems not to be recognized as Interlaced. I think every frame is taken as a progressive one, but only displayed every second. It looks a bit strange.

I will step into it and have a look.

@StrangeNoises

they're all fine with the VDPAU-Bob deinterlacer too (except vc1-interlaced). We've been looking at getting Temporal an Temporal/Spatial interlacing going too, which I'm given to understand is superior. :-)

I expect the vc1-interlaced test is waiting for ffmpeg's support for it as an input format to be completed. Of course, if they think it is completed, give them that to chew on. :-) (It definitely is VC1, and it definitely is interlaced, and it definitely is a raw rip from a published blu-ray disk - and all the others I've tried show the same problems.) Meanwhile the DirectShowSource AVISynth plugin on Windows can read it, which is how I got the encoded version.

@fritsch

@StrangeNoises:
Yeah it is superior. It takes spatial and temporal frame information into account to restore one picture. Bob just sucks in comparison :-). I am recompiling my tree now and see what flags are set in the VC1 Structs - if this is the problem. Interlaced VC-1 one does not get this every day.

@fritsch

Mmh. Seems a bit difficult for me. I tried all patches concerning VC1 till April 2012. They apply cleanly if you cherry-pick them in the right order. But apparantly this does not fix the issue. I am not sure about it.

@FernetMenta
Owner

@StrangeNoises
Thanks for the samples.
I had a brief look into it while packing things together, will be traveling tomorrow and Wednesday. It does not even work for software decoding. Looks like the standard is not interpreted correctly.

@fritsch
Time for you to get out of bed, you have to solve a problem :)

@fritsch

@FernetMenta:
Hehe, just thought to keep it to the ffmpeg people. If you try it in VLC you get a funny error:
[vc1 @ 0x7f979cc20860] Interlaced frames/fields support is incomplete
[vc1 @ 0x7f979cc20860] concealing 0 DC, 0 AC, 0 MV errors
[vc1 @ 0x7f979cc20860] concealing 0 DC, 0 AC, 0 MV errors
[vc1 @ 0x7f979cc20860] concealing 0 DC, 0 AC, 0 MV errors

followed by coredump.

So I think the support in ffmpeg is not there yet.
http://ffmpeg.org/trac/ffmpeg/ticket/275 - But some patches are on the way, not complete yet.

Edit: Same with mplayer and totem - core dumped. I rather stay in bed. xbmc at least does not crash, that is fine.

@StrangeNoises

(i did say that; i wasn't looking for a vc1-interlaced fix here; it's just a bit of a digression...) :-)

@fritsch

@StrangeNoises:
Yeah, that is clear to me - but I looked for something to play with. There is not so much left, what can be improved in XVBA Code ... as new specs are missing and fernetmenta is much too fast while solving bugs.

@FernetMenta
Owner

I think the problem with vc-1 is, that fields are encoded as pictures (true interlaced). Hence we need to divide surface height by 2 and don't expect both fields in a pic/frame.

@FernetMenta
Owner

Apart from the vc1 sample all others play with temporal/spatial on my ID80. This one 1080i-50-raw-dvbs-001 has a clean refresh rate set and pullup correction is able to detect fps.
For the others you need to set fpsdetect to 2 (advanced settings) to get fps detected for patterns > 1. But this step was not required on my system to have them play smoothly.

@StrangeNoises

about to disappear out for the evening, but before i go: reminder you were also going to test it on your gt218 system. I am prepared to pay for a GT520 (should be equiv to what's in the ID80) for my 'big box' and bring that downstairs - as a cheaper short-term solution than buying an id80 - but given the disparity in the GT218 qvdpautest results (above) just want to make sure there's not something else going on that's degrading the performance of my gfx cards below what we'd expect (in which case a GT520 probably wouldn't help).

@StrangeNoises

(for instance i tend to default to installing 64-bit linux on machines that are capable of it - but maybe 32-bit is better?)

@FernetMenta
Owner

I thought 32bit is history. At least I have given up installing/testing 32bit Linux.

@StrangeNoises

ok, we can eliminate that then. :-) i was just wondering given xbmcbuntu images are 32-bit iirc. and we are dealing with a closed binary blob of code. but if we're all on 64-bit and you get better playback than i do on a machine with the same gfx (gt218) (and otherwise in fact much slower machine than mine) then there's something going on...

@FernetMenta
Owner

ION2 is close to its limits playing 1080i50 temporal/spatial. It won't cope with 1080i@60.
But sure, I will do the tests and I owe you a sample of 1080i@50 with fast moving scenes.

@FernetMenta
Owner

Here is a short sample of 1080i50: http://dl.dropbox.com/u/47522966/1080i-50.ts
How does it play? I can try to get a similar sample of a 720p channel on the weekend.

@StrangeNoises

That plays perfectly on Temporal/Spatial on my mac. No change in how it plays the other material, so it's not because of an upgrade being sneaked in! :-) Also, CPU isn't at all elevated on either core. it plays yours at less than 5% CPU on both cores. When playing my 1080i-50-raw-dvbs-001.mkv with Temporal/Spatial (and other sources I have that are BBC HD off-air recordings) I note one core is usually at 100% when dropping frames (and can confirm it is xbmc.bin taking that cpu).

This suggests it might be content-related. There's something easier about your off-air source than mine. But of course I was also having issues with off-bluray sources.

For one thing yours is smaller: resolution is only 1440x1080 anamorphic. BBC HD channels have usually done the same thing, but during this summer, because of Wimbledon, Proms and the Olympics and their 3D demo/trials, they're actually transmitting at 1920x1080. I don't have any raw untranscoded content from before they started doing that.

For another thing, yours is a transport stream. However it's not that; I get the same issues when I play a direct off-air transport stream file as I do when I play it remuxed to mkv. Conversely when I remux your .ts to a mkv it also plays perfectly with Temporal/Spatial.

@StrangeNoises

btw it even drops frames on the bbc hd test card - as well as, i've noticed, on black. So it's not to do with the complexity of detail or movement on screen; given that happens, and yet it's perfectly happy with your example.

I think this makes my examples Good Test Data. Because there's something difficult about it. :-D It's all direct off-air, not encoding errors - not errors made by me anyway! ;-)

A few days ago I recorded about an hour and a half of BBC HD Preview (basically a show-reel they show during the days on BBC HD, clips of various programmes plus testcard and audio sync test). Am thinking of uploading it; only hesitating because it's over 4GB and my uplink is rubbish... Would it be considered useful? :-)

@StrangeNoises

this is probably overdue: http://xbmclogs.com/show.php?id=5211

taken during playback of my DVB-S test file. During playback I see jerky motion and occasionally a frame flashing up from maybe as much as a second ago (or ahead, not sure). If I open the CodecInfo pane I see frames being dropped approximately correlating with this sort of sequence in the log:


23:21:08 T:140547033396992 DEBUG: CDVDPlayerVideo::CalcDropRequirement - hurry: 1
23:21:09 T:140547033396992 DEBUG: Previous line repeats 3 times.
23:21:09 T:140547033396992 DEBUG: CDVDPlayerVideo::CalcDropRequirement - dropped de-interlacing cycle, Sleeptime: -0.069993, Bufferlevel: 1

And I see one CPU core at between 95% and 100%; I think the frame drops are also correlated with when it actually is at 100%.

This log was taken with fpsdetect set to 2; but it didn't seem to make any difference when that was left as default.

BTW not sure you're getting the log level you want, given I see this:


23:20:18 T:140548451665792 NOTICE: Log level changed to 2

followed shortly afterwards by:


23:20:18 T:140548451665792 NOTICE: Disabled debug logging due to GUI setting. Level 1.
23:20:18 T:140548451665792 NOTICE: Log level changed to 1

@FernetMenta
Owner

The sample I posted was only stereo, so this might be the reason why it plays better on your system. Note that I have banned pulse audio from all of my systems. This is actually the first step I do after a new installation. Can you try purging PA?

@StrangeNoises

i'll lay a bet now it's not that. :-) Your test track plays perfectly on this pulseaudio-enabled system. My DVB-S test track that I sent you is only stereo too. The BBC HD Preview reel does have 5.1 surround but there's no difference wrt this problem vs the stereo tracks - neither better nor worse. I can believe pulseaudio might be causing sound issues - for instance I find GUI sounds are a bit hit and miss - but I bet it's not causing this. :-)

Googling a tidy way to disable it... Got to be proven one way or the other. :-)

I will also try comparing with a non-BBC DVB-S source, although tbh I've tended to have more trouble with those, not less; usually, I think, because of the discontinuities around the edited-out commercial breaks. I have none in my vault right now as they show less stuff that I like; but if if I can watch football in the interests of xbmc testing, I can watch chat shows and cookery shows too! ;-)

@StrangeNoises

It's not pulseaudio: Because I log directly into XBMC rather than running it in a unity session, it doesn't even launch. It's running when logged out, in lightdm, but when I log in, it goes.

@fritsch

@StrangeNoises:
Could you set your Audio Output to Analog? As you are using the latest build with AudioEngine included, i suspect some bugs left in this code, to say it modarately.

@StrangeNoises

wouldn't i lose passthru of ac3/dts audio to the amp?

@fritsch
@FernetMenta
Owner

Enumerated ALSA devices:
23:20:18 T:140548451665792 NOTICE: Device 1
23:20:18 T:140548451665792 NOTICE: m_deviceName : default
23:20:18 T:140548451665792 NOTICE: m_displayName : Playback/recording through the PulseAudio sound server
23:20:18 T:140548451665792 NOTICE: m_displayNameExtra:
23:20:18 T:140548451665792 NOTICE: m_deviceType : AE_DEVTYPE_PCM
23:20:18 T:140548451665792 NOTICE: m_channels :

I have seen a couple of cases where PA caused the stuttering. Meanwhile I have tested on ION2. The 50fps sample play fine with temporal/spatial, the 60 with temporal. In neither case I see that high CPU load.

I am just looking for what's different between our systems and might explain the different observations. I set up my systems all the same way: install Ubuntu 12.04 (64bit), purge PA, purge libreoffice, configure ALSA by a single line in asound.conf.

purge PA, purge PA, :)

@StrangeNoises

well, the audio output device was already set to "Default (HDA NVidia Cirrus Analog)". You can't select a non-digital device for passthru but you can disable their use by turning off the "AC3/DTS/AAC capable receiver" options. I did that and there was no difference.

I had been reckoning that if no pulseaudio processes were running then it's not running. And this, not only when xbmc is running, but when it's actually playing a video:

rachel@rarity:~$ ps aux | grep pulse
rachel 26483 0.0 0.0 13580 920 pts/1 S+ 09:48 0:00 grep --color=auto pulse
rachel@rarity:~$

but ok, i'll remove it...

(Interestingly with passthrough off, ac3 5.1 doesn't seem to play at all...)

what's the single line in asound.conf?

@FernetMenta
Owner

pcm.!default plug:hdmi:NVidia

for optical this should work:

pcm.!default plug:iec958:<card>

Interesting that on your system card is NVidia for iec958. I haven't seen this before, mostly its Intel.

@StrangeNoises

right, with pulseaudio gone from the system (and rebooted), and ac3 passthrough off, it's actually worse. Much greater frame dropping.

With an AC3 5.1 source and ac3 passthrough off, there's no sound at all and the video actually only plays at about 1-2 fps. With or without pulseaudio on the system.

Turn passthrough back on and playback on both is the same as when pulseaudio was there.

@FernetMenta
Owner

right, with pulseaudio gone from the system (and rebooted), and ac3 passthrough off, it's actually worse. Much greater frame dropping.

How to interpret this? Even there was no pa process running before, pa did something on your system.

Still this high CPU load?

@StrangeNoises
@StrangeNoises
@fritsch

Mhh, strange experience. What i wanted to test was:
Select Analog in your Sound Settings (not HDMI or Optical), this will disable all the Audioengine Stuff like AC3, DTS, e.g.

At device Selection, select your HDMI output.

@FernetMenta
Owner

Here are some qvdpautest benchmarks listed:
http://www.vdr-wiki.de/wiki/index.php/VDPAU-Grafikkarten
There are two different models for GT218, one with DDR2 memory: compares to your measurement
one with DDR3 which is better.

That might explain the different performance of GT218 but not the high CPU load you even observe on that beast of machine.

@StrangeNoises
@fritsch
@StrangeNoises
@fritsch

What also came to my mind:
Can you check with "top" what process is getting 100 per cent? is it really the xbmc process? or some filesystem kernel process?

@FernetMenta
Owner

@StrangeNoises
Can you post a xbmc log of the high cpu load case?

@StrangeNoises
@StrangeNoises
@StrangeNoises

I'm prepared to admit that audio is probably involved somehow because:

I remuxed my test track to have no audio track at all and it played perfectly. (although obviously without any sound.) No dropped frames, looked good to the eye, no elevated CPU issue.

however, all the above changes to audio setup suggested by you guys are making no difference at all. Actually stripping the whole audio track from the file is the only thing that's made a difference. :-)

@FernetMenta
Owner

@StrangeNoises
I am sorry, I posted a 1440x1080 sample. I never watch this channel, it was listed as HD and thought it was 1920x1080. Will post a new one.

@StrangeNoises

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

@FernetMenta
Owner

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
Owner

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
@FernetMenta
Owner

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
Owner

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.

@FernetMenta
Owner

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

@FernetMenta
Owner

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.

@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
@FernetMenta
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment