Opened 18 years ago
Closed 14 years ago
#2381 closed patch (fixed)
Add support for CoreVideo when displaying on Mac OS X
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | Ports - OSX | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
The attached patch implements a VideoOut? class using CoreVideo? and OpenGL instead of QuickTime/QuickDraw?. This is a more 'forward looking' approach to presenting video in Mac OS X.
Although at the moment it shows no particular performance advantage over the QuickTime? approach (since QT uses ostensibly the same code path to do the actual drawing) this code should offer more future enhancements. For example CoreImage? filters can now be run on the video stream and the OSD display could in the future be composited onto the display in RGB space rather than the YUV conversion that is currently performed to draw the OSD 'in line' with the video image.
This patch seems to work well for me - even in it's currently limited state however it needs additional work to implement PIP support. I'm also planning on updating the current 'usleep/busy wait' timing method to use the CoreVideo? display link mechanism to provide notifications as to when to draw the next frame.
I can't yet see any evidence of anyone else implementing YUV420(YCbCr420) -> YUV422(YCbCr422) CoreImage? filters or a CoreImage? deinterlace filter but it's certainly possible such items could appear in the future. Doing the colorspace conversion entirely on the card would definately yield some further performance improvements.
Note that videoout_corevideo doesn't implement any of the 'cute' features of videoout_quartz such as video in the dock or in a transparent window - those settings are ignored.
Attachments (8)
Change History (21)
Changed 18 years ago by
Attachment: | videooutbase.cpp.patch added |
---|
Changed 18 years ago by
Attachment: | libmythtv.pro.vo.2.patch added |
---|
Changed 18 years ago by
Attachment: | videoout_corevideo.h added |
---|
Changed 18 years ago by
Attachment: | videoout_corevideo.cpp added |
---|
comment:1 Changed 18 years ago by
Changed 18 years ago by
Attachment: | quartz.log added |
---|
Changed 18 years ago by
Attachment: | corevideo.log added |
---|
comment:2 Changed 18 years ago by
Yep - you're right there is definately something a little awry.
I had got it working with 4:3 SD and then found and fixed some problems with 16:9 HD, now going back to 4:3 SD I see that there's something broken there.
I'll take a look into it. Thanks for your testing !
Changed 18 years ago by
Attachment: | videoout_corevideo.2.cpp added |
---|
comment:3 Changed 18 years ago by
I've update the videoout_corevideo.cpp file - it should now support the various frame sizing options correctly.
One note - this version follows more closely the xv 'style' of video sizing which means the 'W' key now works (it doesn't in quartz code). However if that 'annoys' you (it seems to me that it always stretches 4:3 content if you have a 16:9 display) there's a #define USE_DISPLAY_VIDEO_RECT which you can set to 0 to restore the quartz behaviour.
comment:4 Changed 18 years ago by
(In [11250]) Check for Mac OS X CoreVideo? headers, set config symbol if available. See #2381
Changed 18 years ago by
Attachment: | videoout_corevideo.3.cpp added |
---|
Implement UpdatePauseFrame? fully
comment:5 Changed 17 years ago by
So, I've been using this patch (through its various iterations) against the svn head for a couple of weeks now, and I've noticed no problems with it. I did set #define USE_DISPLAY_VIDEO_RECT to 0 though, as there's nothing that irritates me more than 4:3 content stretched to a 16:9 ratio.
I'd be interested to know how much more work you're intending to do on it (using Display Link for example) before you think it's ready to be committed to svn? Also (and forgive my ignorance here), how easily could deinterlacing filters using Core Image be written and integrated into the code? Deinterlacing content for a progressive display (my iMac) is the area that I think that Myth is the most lacking at the moment (particularly as bob is unavailable on OS X).
comment:6 Changed 17 years ago by
I'd like to get a feeling from a few more people as to which way USE_DISPLAY_VIDEO_RECT should be set. In particular that the stretching behaviour is also present on Linux and that I've not introduced something new (I agree with your sentiment about 4:3 stretched to 16:9).
I think it could be committed to SVN once the above issue is resolved (if the committers agree). Adding DisplayLink? support would be nice and would probably improve performance a little - however I think it might be a bit tricky given the current decode & display architecture in Myth.
Adding CoreImage? filters to the class is pretty straightforward and I'll probably add some 'if def 0' code to illustrate that using an 'effect' filter. At this point I'm not aware of any CoreImage? filter that does de-interlacing however. It's not rocket science to write one but it's not something I have the time for right now (I also have to be careful of Intellectual Property from my employer who has technology in that space).
comment:7 Changed 17 years ago by
Turning off USE_DISPLAY_VIDEO_RECT makes your new class work like the old Quartz one, which is what the Mac users have always had anyway. If I have the time this weekend, I'll dig out my old widescreen monitor and hook it up to my backend, to see how the video stretching happens on that system.
Quite understand the IP issues, but some example code would be good (although I've got a feeling that all the "nice" deinterlacers need multiple fields to work on, and I'm not sure how easy that will be).
I'll post a link to my Macintel compiled version of the frontend with your code in on the wiki, and hopefully that'll encourage some more people to test it.
comment:8 Changed 17 years ago by
Owner: | changed from Isaac Richards to Nigel |
---|
comment:9 Changed 15 years ago by
Status: | new → assigned |
---|
comment:10 Changed 14 years ago by
Component: | mythtv → Ports - OSX |
---|
comment:11 Changed 14 years ago by
FWIW, I don't see anything in this code that hasn't been implemented in VideoOutputOpenGL.
I suspect it can be closed.
comment:12 Changed 14 years ago by
With the exception of the call into AccelUtils? - but it doesn't appear to be 'core' to the patch.
(p.s. the last comment was by me!)
comment:13 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I'm going to close this one as fixed, since markk has indicated that pretty much everything in this patch apart from the AccelUtils? call has already been implemented in VideoOutputOpenGL.
If you do come up with a patch to use the Mac's hardware acceleration in a manner compatible with the rewritten output layer then feel free to open a new ticket.
Stuart
I tried out this patch, and it worked (to a degree). I got video playback no problems on my iMac, but 4:3 channels (I have DVB-T in the UK) played off-centre on the screen to the right, and 16:9 content didn't change aspect ratio, and played within the same off-centre 4:3 ratio area. I've attached two -v playback logs, if they're any help.