Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 8 years ago

Closed 4 years ago

#2381 closed patch (fixed)

Add support for CoreVideo when displaying on Mac OS X

Reported by: awk@… 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)

videooutbase.cpp.patch (639 bytes) - added by awk@… 8 years ago.
libmythtv.pro.vo.2.patch (663 bytes) - added by awk@… 8 years ago.
videoout_corevideo.h (1.1 KB) - added by awk@… 8 years ago.
videoout_corevideo.cpp (26.0 KB) - added by awk@… 8 years ago.
quartz.log (27.6 KB) - added by pdbailey@… 8 years ago.
corevideo.log (25.1 KB) - added by pdbailey@… 8 years ago.
videoout_corevideo.2.cpp (27.9 KB) - added by awk@… 8 years ago.
videoout_corevideo.3.cpp (27.8 KB) - added by awk@… 8 years ago.
Implement UpdatePauseFrame? fully

Download all attachments as: .zip

Change History (21)

Changed 8 years ago by awk@…

Changed 8 years ago by awk@…

Changed 8 years ago by awk@…

Changed 8 years ago by awk@…

comment:1 Changed 8 years ago by pdbailey@…

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.

Changed 8 years ago by pdbailey@…

Changed 8 years ago by pdbailey@…

comment:2 Changed 8 years ago by awk@…

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 8 years ago by awk@…

comment:3 Changed 8 years ago by awk@…

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 8 years ago by nigel

(In [11250]) Check for Mac OS X CoreVideo? headers, set config symbol if available. See #2381

Changed 8 years ago by awk@…

Implement UpdatePauseFrame? fully

comment:5 Changed 8 years ago by pdbailey@…

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 8 years ago by awk@…

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 8 years ago by anonymous

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 8 years ago by danielk

  • Owner changed from ijr to nigel

comment:9 Changed 5 years ago by Dibblah

  • Status changed from new to assigned

comment:10 Changed 5 years ago by stuartm

  • Component changed from mythtv to Ports - OSX

comment:11 Changed 4 years ago by anonymous

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 4 years ago by markk

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 4 years ago by stuarta

  • Resolution set to fixed
  • Status changed from assigned to 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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.