Hi Nigel,

I didn't try modifying InputChanged, but based on what I figured out this weekend, I'm not sure that this would help. From what I can tell, 1080i always scales due to a bug, and it's a side effect of that scaling that either causes the dropped frames or not.

Here's what I found:

In VideoOutputQuartzView::Transform there's code that detects and corrects non-square pixels. With 1080i content, this code always thinks that it must do a correction. I think this is because when the height is changed to 1088, the corresponding source aspect ratio is not updated.

So when the non-square pixel test runs, it compares the parent source aspect ratio to the aspect ratio as computed by the parent source width and height. For 1080i, the original source aspect ratio is 1.77778. But the computed aspect ratio with a width of 1920 and 1088 is 1.76471. This results in a delta of 0.0130719, which is enough to trigger the correction for non-square pixels.

If the Mac OS X option is set to "Scale video as necessary", then the correction code tries to scale up the width. If the option is disabled, then the code scales down the height. As it turns out, the side effect of scaling down the height is the key to resolving the dropped frames problem.

To test this, I ifdef'd out the entire non-square pixel correction code. When I did that, I got dropped frames regardless of whether the scale video option is enabled or not. I verified that no obvious scaling was happening to the image.

For now I've hacked my copy of the code to leave out the non-square pixel correction (which I think is broken anyway), and I've added code so that if no obvious scaling is needed, I check to see if there's a 10% or less delta between the image and the display area. If there is, I scale the image. For 1080i, this means scaling the height down from 1088 to 1080. I'm not completely sure why Quicktime likes this scaling, but it does.

This allows me to watch 1080i without dropped frames, plus lower resolution content (like 480p) scales as needed.

In addition, I made a modification to scale the horizontal and vertical resolutions independently when in "kLetterbox_Off" mode. That allows me to change my resolution to an overscan corrected variant (1976 x 996 for my set) , and everything still scales correctly. Prior to that change, my odd sized overscan corrected resolution resulted in a letterboxed display.

Note that I suspect that my code changes are not the right way to solve these problems. But unfortunately I don't have enough of an overview of how this all works to figure out the *right* fix. Who knows, maybe your suggested fix would side step the issue altogether. Maybe I can try this when I get a little more time. Although I probably won't be able to get to it for a couple of weeks.

But regardless, I think it's time to look at revamping the VideoOutputQuartzView::Transform method. Because even if the math error that triggers the non-square pixel correction is fixed, it isn't clear that this code is doing the right thing.

_________________
Best,

Allen Cronce

Unfortunately (or maybe fortunately) my older HDTV died. The problem with that TV was that it only supported a 1080i input via VGA. I've replaced it with a 1080p DLP with a DVI computer input.

Originally I drove the new TV with 1080p and the Mini using my hacked version of the MythFrontend. But I found that certain shows with fast scene changes (like the now canceled "Drive") had very distracting tearing. Even my wife noticed it, which says something.

Rather than tackle this new issue, I tried dropping my Mini down to 720p. While the resolution is somewhat less, the overall watchability is much better now.

At some point I might return to the 1080 struggle. But for now, I've sidestepped it by dropping out of warp

_________________
Best,

Allen Cronce

Hi Allen, I saw your report of this issue on the Myth Wiki..

In your latest 1080p trials, were you still using modified code to compensate for the scaling issues? Or, has that been updated in MythFrontend?

There was also another similar issue discussed on the mailing list, related to a default refresh rate. I think that would apply only to internal displays, but it might be worth checking what refresh rate myth is reporting.

http://www.gossamer-threads.com/lists/m ... ers/257971


On the tearing issues.. The Linux frontend has several frame sync options, like OpenGL vsync, and high resolution timers.. Do any of these apply to the Mac version? I'm not seeing tearing on my 720p display, but it sounds like that's consistent with what you're seeing.

I was using a new 24" iMac, which has 1920x1200 resolution, and got the effect described previously in this thread. It's also been discussed elsewhere, with some people blaming the integrated video in the Mini as the source of the problem.

Problem: By default, playback of 1080i video is very jumpy. It appears to be skipping many frames.

Here is what I found while building 0.20.2 for the iMac:

- The system tested is a new Core2Duo iMac 24", 2.4GHz CPUs, 2GB RAM, discrete ATI GPU. So, I think some explanations in other threads can be eliminated ( CPU not fast enough, 512MB on older Mini not enough for very high resolution processing, Intel integrated GPU not up to the task ).

- There is a secondary monitor connected, in extended desktop mode. The second monitor is 4:3, 1280x1024 connected by VGA/Analog. Setting MythTV to display on the second monitor (Xinerama display 1) works fine. Playback is smooth, scaling is fine, no problems.

- Turning off "Scale Video as Necessary" resolves the problem. 1080i video plays smoothly. But, 720p video is windowboxed (black bars on top/bottom/left/right), and 480i video is even worse - displayed in a very small window. Playback is smooth for all resolutions, but obviously scaling is needed for lower resolution programs.

- I tried applying the change mentioned in my previous post (change default refresh rate from 150Hz to 60Hz), but it made no difference.

- I don't see the video playback problems on other systems/displays: Mac Mini on 720p display; MacBook Pro on 1440x900 internal display or 1680x1050 external display connected via DVI. So, I'm not sure exactly what the threshold is to trigger the problem.


This testing was all done with 0.20.2. I don't have a 0.21svn backend running right now, so I cannot test that frontend. Does anyone know of any relevant changes in that branch?

Current SVN head recently had many changes in the video playback chain, but nothing 1080 specific in the Mac part.

Not saying that SVN won't fix it, just that I don't have 1080i output hardware, and thus wasn't able to explore this bug (before or after the changes).

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

tji, it sounds like you ran into the same problems that I did. As indicated in a previous post, I was able to work around the worst of the problems (dropped frames) by hacking the scaling code. But ultimately ran into other tearing issues that finally made me abandon 1080i.

Anyway, as per Nigel's sugestion, I just tried to do a build of the latest revision 14567 to see if any of these issues have been fixed. Unfortunately I got the following error:


I can't tell if this is a build bug or just a connection problem on my end. Nigel, have you been able to successfully build the latest?

_________________
Best,

Allen Cronce

I just tried downloading libexif, and it worked fine for me. But, I have found fairly frequent problems with those URLs to download packages from osx-packager.pl. The filenames/version and thus the URL change fairly frequently. Or, sometimes a mirror is down.

You can usually track down the current URL, and update the osx-packager.pl script. Or, you can download the file by hand and place it in .osx-packager/src and re-run osx-packager.pl

I also just re-built the MFE lastest svn, and it worked fine for me. You may have just run into an outage on that sourceforge server.

I am planning on setting up a 0.21svn backend for testing. I'll run it in a VMware VM, using an HDHomeRun device for input. So, I should be able to do some more debugging soon.

I set up a 0.21svn backend in a VMWare VM, so I could test the 0.21 client.

The latest Mac frontend build has the same scaling issue as the 0.20. I got very choppy playback on the 1920x1200 display, and smooth playback on the lower resolution secondary display.

So, I did a bit more debugging. I ran Apple's "Shark" tool to profile the CPU usage and what components were being hit the hardest when the problem is seen.

By far the biggest CPU user is "YUV422_UC_ToRGB32BitColorBGRA", which is part of the "QuickTimeComponents" library. Shark shows the sequence of functions something like:

VideoOutputQuartzView::Show()
DecompressSequenceFrameWhen
.... (snipped) ...
YUV422CodecComponentDispatch
ScalingCodecComponentDispatch
... (snip) ...
PrepareForBlitThenDoBlit
FinalGlueBeforeTheBlit
YUV422_UC_ToRGB32BitColorBGRA


The CPU usage in general went like:

41.7% YUV422_UC_ToRGB32BitColorBGRA
7.7% ml_set_interrupts_enabled
7.0% mmx_i420_2vuy
6.0% mpeg_decode_mb
4.7% linearBlendMMX
3.0% put_pixels8_mmx
2.9% put_pixels16_mmx
....


It looked like the YUV422* function was the problem, since it's the huge part of the CPU load. So, I switched the setup to use screen 1 and tried again. To my surprise, I got almost the exact same reading on the other screen, even though the video was now completely smooth. In fact, on the small screen YUV422 was even slightly higher CPU load.


A quick google search for that function turned up a thread on the myth mailing list talking about this same issue.

Nigel: Should I put this info in trac instead? I think there was a closed ticket about this problem. I could put it there.

tji, thanks for the Shark stats. I haven't had time to run any performance benchmarking in a long time.

Here is some old discussion about the routines:
http://www.gossamer-threads.com/lists/mythtv/dev/193022

Basically, YUV422_UC_ToRGB32BitColorBGRA only seems to be used if "Scale Video as necessary" is enabled. I used to think it is a hardware-assisted routine, but judging by the percentages, it isn't.

Allen thought it was due to the source material being 1088 lines high (a common HD resolution that is divisible by 16). Experimenting with over or underscan may let you work around it.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

I tried playing around with overscan, but it didn't seem to have any effect (I'm not really sure what I was doing with that.. I wasn't sure what the right setting was or which way to tweak it. The setup menu descriptions are not obvious to me).


So, I modified the code with the change you (nigel) mentioned earlier in the thread:



Once I made that change, playback was smooth as if scaling was turned off. I checked other channels, with 480i and 720p, and they were playing back fine -- scaled to full screen.

I also checked Shark, and YUV422_UC_ToRGB32BitColorBGRA was no longer in the list. Maybe that is the symptom of the problem. Quicktime doesn't like something about the video and kicks it to a software function. But, with it setup as 1080, the processing is done in hardware.

The saga continues...

After testing the 0.21svn version, I went back and made the same change in the 0.20.2 version. With this one I can connect to my real backend server and have access to many more recordings to test with.

What I found with this version is that the performance is dependent on the content. With some 1080i programs, I still see the problem regardless of the modification.

But, with other programs, I can switch between the original and modified frontends and see the problem go away and re-appear. So, the change definitely has some effect, but it is not a cure-all (at least not in 0.20.2. I don't have enough 1080i programs available in the 0.21svn backend to see the full behavior there).

Also, it's not just station-specific, which might point to a difference in the way they are encoding. I looked at several programs from my local PBS broadcaster, and a few of them played back perfectly after the modification, and several others still showed jumpy playback.



Maybe I should post about this is a different forum, to get more visibility from other potential testers. It doesn't seem like many others here have this problem.

I just ran Shark on my laptop, to compare the results on a completely different system. With scaling turned on, the CPU usage looked like:

22.2% mach_kernel ml_set_interrupts_enabled
9.7% mythavcodec mpeg_decode_mb
8.7% commpage __longcopy
8.6% mythtv mmx_yuv420_2vuy
5.5% mythavcodec ff_simple_idct_add_mmx
.....


"YUV422_UC_ToRGB32BitColorBGRA" is not shown at all here. So, this may support the theory that YUV422* is seen only in problem cases.

I posted about this on the mythtv-users mailing list, and got some feedback there.

Mino, the person who contributed the MMX patch for intel Macs in the past, suggested a change to the aspect ratio / square pixel detection code. (After looking through this thread, I see that Allen had suggested and tested the same thing, which I missed earlier).




After making this change (and backing out the previous 1088->1080 change, playback of 1080i programs is working great so far.

I have tested a few programs, including one that caused problems with the previous patch, and they all played fine. I will record more programs and continue to test this.