The amount of delay needed may depend on the size and format of the media file being loaded, so I’d avoid using CallLater() in favor of an event-driven model.
David
···
On Dec 31, 2011 4:50 PM, “Patrick Maher” patrick@maher1.net wrote:
I have not yet been able to get an event-driven approach to work. The code using EVT_MEDIA_LOADED, posted by Tim, should work but doesn’t because wx.Python doesn’t send the event—I think this is a bug. I’ve also tried using CallAfter, as suggested by Jad, but I haven’t got it to work for me, perhaps because I don’t understand how to use it correctly. I’ve attached my unsuccessful attempt and would be grateful if someone could say what I’ve done wrong.
Patrick
playtest4.py (773 Bytes)
The _LOADED event really should be sent, so if it isn't then it is probably a bug. Please create a ticket about it at trac.wxwidgets.org if there isn't already one there for it.
As a workaround try using a different backend, as shown in the attached.
playtest4.py (931 Bytes)
···
On 1/2/12 7:28 AM, Patrick Maher wrote:
I have not yet been able to get an event-driven approach to work. The
code using EVT_MEDIA_LOADED, posted by Tim, should work but doesn't
because wx.Python doesn't send the event---I think this is a bug. I've
also tried using CallAfter, as suggested by Jad, but I haven't got it to
work for me, perhaps because I don't understand how to use it correctly.
I've attached my unsuccessful attempt and would be grateful if someone
could say what I've done wrong.
--
Robin Dunn
Software Craftsman
Thanks Robin. When I run your program it prints “2.8.11.0 (msw-unicode)”. Pressing the button then gives:
calling Load
Load called
That’s all and it doesn’t play. The problem might be that I don’t have quicktime.
I’ve attached a program that creates a button that alternately loads and plays the specified file, printing out each time a LOADED and PLAY event is received. On my computer, the LOADED event is never recorded but the PLAY event is. If I specify the quicktime backend in this program then play no longer works for me.
I’ll look into creating a ticket but, since I’m new to this, I’ll first spend a little time learning how that works.
I’d still like to know why my attempt to use CallAfter didn’t work.
Patrick
playtest5.py (1.04 KB)
Sorry if I'm stating the obvious, but for wxMediaCtrl to work, you need
to have the proper player(s) installed and the video needs to be able to
play on your computer in the appropriate player. On Windows, you should
already have Windows Media Player, but you will also need the free
QuickTime Player for some formats (*.mov, *.mp4, *.m4v, etc.). On OS X,
you should already have the QuickTime Player. On Linux, you need to
install gstreamer. You also need to have the appropriate codecs
installed for whatever format the video and audio are encoded with.
David
···
On Mon, 2012-01-02 at 15:28 -0800, Patrick Maher wrote:
Thanks Robin. When I run your program it prints "2.8.11.0
(msw-unicode)". Pressing the button then gives:calling Load
Load calledThat's all and it doesn't play. The problem might be that I don't have
quicktime.I've attached a program that creates a button that alternately loads
and plays the specified file, printing out each time a LOADED and PLAY
event is received. On my computer, the LOADED event is never recorded
but the PLAY event is. If I specify the quicktime backend in this
program then play no longer works for me.I'll look into creating a ticket but, since I'm new to this, I'll
first spend a little time learning how that works.I'd still like to know why my attempt to use CallAfter didn't work.
Hi Patrick,
Here's a sample program I wrote a while back. It works on my Windows 7
computer, but I haven't tried it (recently) on other platforms. You'll
obviously need update the media file on line 10.
To add any other controls to this sample, you'll need to add Sizers,
etc., but this is the bare bones of the wxMediaCtrl.
David
Video_Test_Minimal.py (940 Bytes)
···
On Mon, 2012-01-02 at 15:28 -0800, Patrick Maher wrote:
Thanks Robin. When I run your program it prints "2.8.11.0
(msw-unicode)". Pressing the button then gives:calling Load
Load calledThat's all and it doesn't play. The problem might be that I don't have
quicktime.I've attached a program that creates a button that alternately loads
and plays the specified file, printing out each time a LOADED and PLAY
event is received. On my computer, the LOADED event is never recorded
but the PLAY event is. If I specify the quicktime backend in this
program then play no longer works for me.I'll look into creating a ticket but, since I'm new to this, I'll
first spend a little time learning how that works.I'd still like to know why my attempt to use CallAfter didn't work.
Patrick
Thank you, David. Prompted by looking at your program, I tested and found that EVT_MEDIA_LOADED is issued when the backend is WMP10 but not when it is DirectShow, which is the default on Windows. Robin’s contribution indicates that the LOADED event is also issued when the backend is QuickTime. So it appears that the problem of the LOADED event not being issued only arises when the backend is DirectShow. That narrows down the problem a lot but I think I should still create a ticket for the apparent bug with DirectShow.
Patrick
I wrote a really simple MP3 player with this control before. You can read about it here: http://www.blog.pythonlibrary.org/2010/04/20/wxpython-creating-a-simple-mp3-player/
Then I took the mplayer control to embed MPlayer in wxPython. It can play back all sorts of files: http://www.blog.pythonlibrary.org/2010/07/24/wxpython-creating-a-simple-media-player/
I don’t know if those will help you or not, but it’s worth a shot.
Thank you, David. Prompted by looking at your program, I
tested and found that EVT_MEDIA_LOADED is issued when the
backend is WMP10 but not when it is DirectShow, which is the
default on Windows. Robin's contribution indicates that the
LOADED event is also issued when the backend is QuickTime. So
it appears that the problem of the LOADED event not being
issued only arises when the backend is DirectShow. That
narrows down the problem a lot but I think I should still
create a ticket for the apparent bug with DirectShow.Patrick
Hi Patrick,
Your Windows version matters here.
If I understand things correctly, DirectShow works with older versions of
Windows Media Player (such as WMP 6.4) and WMP10 works with, well, Windows
Media Player 10 and later. I think Microsoft dropped support for older WMP
versions in Vista and Windows 7, rendering DirectShow inoperable.
OK, that might not be exactly the explanation, but that's how I explain it
to myself. I *know* that on my Windows XP box, I can actually see the WMP
differences when I have the control buttons visible through wxMediaCtrl, and
I know that DirectShow doesn't work on Vista. XP is old enough that
switching the default back end for wxMediaCtrl on Windows from DirectShow to
WMP10 makes sense to me.
Finally, I noted in your example code that you were trying to load an *.wma
file. *.wma files won't work with the QuickTime back end. I'd bet the
Load() fails if you try an *.wma file with the QuickTime back end, so the
EVT_MEDIA_LOADED event shouldn't fire because the media file can't be
loaded.
David
I have Windows 7, 64-bit, and the default backend (DirectShow, according to the documentation) works fine for me, with the single exception that it doesn’t issue the MEDIA_LOADED event.
Patrick
Hi guys,
I think you are forgetting something… The media file plays ok, but it’s the MEDIA_LOADED event that is not fired. (This is what is happening with me when I use the defaults on my Windows 7 machine…) In fact, you can play the file with a delay of less than 1 second instead of “on load”.
So, the problem is not with the backend you are using, but with the event being fired or not. I believe it is a bug.
See the attached file.
playtest.py (1.88 KB)
David wrote:
If I understand things correctly, DirectShow works with older versions of
Windows Media Player (such as WMP 6.4) and WMP10 works with, well, Windows
Media Player 10 and later. I think Microsoft dropped support for older WMP
versions in Vista and Windows 7, rendering DirectShow inoperable.
Well, this is playing a bit loose with the facts. DirectShow continues
to work perfectly well, even in Windows 8, and Windows Media Player is a
DirectShow application. Even Windows Media Center is a DirectShow
application. The technology is not going away.
For wma and wmv files, however, Windows Media Player can also use a
different playback path that bypasses DirectShow and makes a more direct
connection from the codec to the renderer. It's possible that's what is
going on here.
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
> If I understand things correctly, DirectShow works with
older versions
> of Windows Media Player (such as WMP 6.4) and WMP10 works
with, well,
> Windows Media Player 10 and later. I think Microsoft
dropped support
> for older WMP versions in Vista and Windows 7, rendering DirectShow
> inoperable.Well, this is playing a bit loose with the facts. DirectShow
continues to work perfectly well, even in Windows 8, and
Windows Media Player is a DirectShow application. Even
Windows Media Center is a DirectShow application. The
technology is not going away.For wma and wmv files, however, Windows Media Player can also
use a different playback path that bypasses DirectShow and
makes a more direct connection from the codec to the
renderer. It's possible that's what is going on here.
Thanks for the correction, Tim. I'm not surprised I don't have the details
exactly right.
I remember that the transition to Vista from XP was bumpy, but that was
several years ago and the details are hazy at best. From what I recall, it
was not straight-forward. I recall that the way WMV and WMA files were
encoded changed, and that newer files in those formats would only work with
WMP9 (yes, 9) and not DirectShow. I'm pretty sure there were formats that
allowed speed change under DirectShow but not WMP9 or WMP10. And I'm very
sure that there was a time when DirectShow wouldn't work with some of the
media files in my test suite on Vista no matter what so I had to disable
that option on that platform.
It's perfectly possible that the DirectShow problems I had have been fixed
since I last looked into the issue several years ago. I need to look into
it again, as that might allow me to support playback speed change with more
formats than I currently do. That would make some of my users very happy
indeed.
David
A ticket for this problem was created in 2009. It is ticket #10958 and has the title
wxEVT_MEDIA_LOADED doesn’t work in Windows Vista
It hasn’t been resolved and the last comment was 15 months ago. Since the title doesn’t accurately describe the problem I created a new ticket, #13838, with the title
MediaCtrl with DirectShow backend doesn’t issue EVT_MEDIA_LOADED
and a reference to the earlier ticket. But a few minutes later my new ticket was closed and marked as a duplicate of #10958 and the following comment was added to the latter:
According to #13828
this indeed happens only with DirectShow backend. I still have no idea about what exactly is the bug and how to fix it. Any help with this would be appreciated as I have no knowledge of DirectShow.
So I’m not hopeful that the bug will be fixed any time soon. Fortunately, we have several workarounds: Use a different backend or use CallLater to insert a delay.
Patrick
> If I understand things correctly, DirectShow works with
older versions
> of Windows Media Player (such as WMP 6.4) and WMP10 works
with, well,
> Windows Media Player 10 and later. I think Microsoft
dropped support
> for older WMP versions in Vista and Windows 7, rendering DirectShow
> inoperable.Well, this is playing a bit loose with the facts. DirectShow
continues to work perfectly well, even in Windows 8, and
Windows Media Player is a DirectShow application. Even
Windows Media Center is a DirectShow application. The
technology is not going away.For wma and wmv files, however, Windows Media Player can also
use a different playback path that bypasses DirectShow and
makes a more direct connection from the codec to the
renderer. It's possible that's what is going on here.
Tim,
Sorry for the long delay in responding, but I needed to find time to look
into this in more detail.
I'm using wxPython 2.8.12.1, and the wxMediaCtrl DirectShow back end does
NOT work on Windows Vista or Windows 7.
I modified my app so that the back end is configurable and tested it on
Windows XP with MPEG-1, AVI, and WMV files. The MPEG-1 and AVI files worked
in both back ends on XP, while the WMV file worked only with the WMP10 back
end, not the DirectShow back end. DirectShow allowed changing playback
speed for MPEG-1 and AVI (which I'm interested in) while WMP10 did not.
WMP10 did allow speed change for WMV.
I then repeated the test on a Vista 32-bit computer and on clean,
fully-updated Vista 64-bit, Windows 7 32-bit, and Windows 7 64-bit virtual
machines I have set up for testing purposes. In all cases, the WMP10 back
end played all three files but would not allow speed changed for the MPEG-1
file and speed test results for the AVI file were mixed, while the
DirectShow back end would not play any of the files.
My conclusion is that while the DirectShow technology may be alive and well
in Windows, the DirectShow back end for wxMediaCtrl, which is what the
original poster was asking about and is what I was referring to, does not
work on Vista and Windows 7.
David