Opened 13 years ago

Closed 13 years ago

#9268 closed Patch - Bug Fix (Fixed)

[PATCH] mythvideo: fix win32 playback of dvd's and iso images

Reported by: Lawrence Rust <lvr@…> Owned by: markk
Priority: minor Milestone: 0.25
Component: Ports - Windows Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This series of patches fix win32 specific issues with mythvideo.

  • pathname.diff allows the VideoStartupDir? to be a semicolon (instead of colon) separated list of dirs. This permits win32 absolute paths such as d:\...
  • io.diff fixes libmythtv/mythiowrapper to use a 64-bit off_t type as expected by libdvdnav. This fixes the playback of iso images.
  • ogl-thrd.diff fixes libmythui/mythrender_opengl and libmythtv/mythplayer to ensure that only the correct thread calls MythRenderOpenGL::makeCurrent. This is important on win32 where each thread has its own OpenGL context - see http://msdn.microsoft.com/en-us/library/dd374387%28v=VS.85%29.aspx

Attachments (3)

ogl-thrd.diff (3.2 KB) - added by Lawrence Rust <lvr@…> 13 years ago.
pathname.diff (1.5 KB) - added by Lawrence Rust <lvr@…> 13 years ago.
io.diff (2.4 KB) - added by Lawrence Rust <lvr@…> 13 years ago.

Download all attachments as: .zip

Change History (16)

Changed 13 years ago by Lawrence Rust <lvr@…>

Attachment: ogl-thrd.diff added

Changed 13 years ago by Lawrence Rust <lvr@…>

Attachment: pathname.diff added

Changed 13 years ago by Lawrence Rust <lvr@…>

Attachment: io.diff added

comment:1 Changed 13 years ago by robertm

Owner: changed from Nigel to robertm
Status: newassigned

I'll look at the RB/mythiowrapper stuff, Mark will have to approve the OpenGL changes, though the logic seems sound.

comment:2 Changed 13 years ago by anonymous

I'll look at the OpenGL stuff properly the next time I've summoned enough courage for a windows build. The patch however isn't correct. Simply disabling features is not a fix and tracking the thread that created the context is not needed.

As stated in the the referenced documentation, only one context can be current to a thread but it doesn't matter where that context was created. The root problem is probably a side effect of no longer calling QGLContext::doneCurrent and I suspect the fix is to call that before QGLContext::makeCurrent - on linux glxmakecontextcurrent will switch to the new context but wglMakeCurrent on windows is probably failing as it won't allow a second context to be made current.

comment:3 Changed 13 years ago by stuartm

Version: UnspecifiedTrunk Head

comment:4 Changed 13 years ago by robertm

Updated version of pathname.diff applied in bfd7c49ca

comment:5 Changed 13 years ago by robertm

Owner: changed from robertm to markk

io.diff applied in 079577077

comment:6 Changed 13 years ago by Github

MythPlayer?: Only set the video scan from the player thread.

First in a series of changes designed to ensure that OpenGL video playback is only (re-)initialised from the main UI thread, allowing us to safely use a single OpenGL context without the need for expensive context switching and locking (and fix a few bugs and allow VAAPI decoding)

Refs #9268

Branch: master Changeset: 805be5f7a9d3e25267298a3a13fea6152a37c30d

comment:7 Changed 13 years ago by Github

VideoOutputOpenGL: Refactor creation/destruction of resources.

Refs #9268

Branch: master Changeset: 4df9b74d8b02d441ae3bf39e5a4b518027542369

comment:8 Changed 13 years ago by markk

Ref 499a414bc798dbcd2d11

comment:9 Changed 13 years ago by Github

VideoOutputOpenGL: Use a shared OpenGL context for OpenGL video and UI.

This should fix:-

  • blank OpenGL video playback on OS X.
  • framebuffer 'confusion' where the driver gets stuck displaying a UI

context backbuffer during video playback and vica-versa. Seen on intel clarkdale and AMD with the proprietary driver.

This also clears the way for VAAPI integration and the removal of context locking and switching code that is reducing performance and breaking OpenGL rendering on windows.

In the medium term, integrated video and UI rendering is now straightforward.

Refs #9268 Refs #8593

Branch: master Changeset: 6846e140499e77432954d2d8ef56cabcbc6063e7

comment:10 Changed 13 years ago by Github

DVD: Refactor forced video aspect ratio code.

Instead of using custom code to force the aspect ratio during dvd playback (usually used to force still frames to 16:9), just monitor the aspect ratio within DVDRingBuffer and use it to override the stream aspect ratio in AvFormatDecoder?.

Other than simplifying the player code, this avoids another potentially buggy and costly call directly from the decoder thread into the player.

Refs #9854 Refs #9268

Branch: master Changeset: b944b041c8987ea135076c1af63bb905a50d7a1d

comment:11 Changed 13 years ago by Github

Store the video aspect ratio in the video buffers.

.. and use the buffer value to determine the video aspect ratio during playback.

This has the principle (user) advantage of actually synchronising aspect ratio changes with the actual change in the video stream (rather than 10-20 frames early).

From a code perspective, this further reduces calls from the decoder thread into the player, which cause significant playback interruption with cpu based playback and introduces thread related issues for hardware graphics contexts.

The 'video_codec_changed' parameter is removed from MythPlayer::SetVideoParams? (it has not been used since XvMC was removed), keyframedistance is set separately and an aspect ratio change no longer triggers a video output change directly - only when the video frame is about to be displayed.

Theoretically there is no reason to trigger SetVideoParams? for a frame rate change either but xrandr/display res changes are triggered by a combination of changes in video size and frame rate.

Ref #9268

Branch: master Changeset: 857d804b8f57cfff800bf22866ea60480fdfb697

comment:12 Changed 13 years ago by Github

Windows: Don't release the OpenGL context.

The release method was added to prevent lockups when the GL context is accessed from another thread but there should now be no circumstance under which any other thread makes the UI OpenGL context current (on windows at least). Not releasing makes OpenGL video rendering work again on windows when using OpenGL for the UI.

Refs #9268

Branch: master Changeset: 5813cdafe8ec5f573b6d640ef3d8423c0fdd2d76

comment:13 Changed 13 years ago by markk

Milestone: unknown0.25
Resolution: Fixed
Status: assignedclosed

The remaining OpenGL thread related fix is no longer needed. As previously mentioned, in master there should now only be one piece of code that tries to make the OpenGL context current to any other thread and that is for the VAAPI code. Given that VAAPI is linux only, the OpenGL context should only ever be accessed from the main UI thread on windows.

Note: See TracTickets for help on using tickets.