[ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all time-related functions to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding what the issues involved were, but also for discovering solutions. I think this new version addresses pretty much all the points you raised. Everyone, please continue to provide feedback on what works, what doesn't, and features you'd like to see! While I don't have time to implement a cross-platform multimedia framework at the moment, I do want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

Kevin,

The new features work perfectly. Thanks so much for being so responsive to
my needs. I'm working now, between interruptions at least, on integrating
wxQtMovie into Transana, and it's going very smoothly so far.

There is one problem I see at present, which shows up in the wxQtMovie demo
program as well as within Transana. The movie playback I'm getting is very
jerky, not at all smooth. The audio track plays smoothly, but the video
seems to pause for most of each second, then very rapidly cycle through the
update of all the video frames, then pause for most of the next second, then
too rapidly cycle through the next set of video frames. I don't recall
seeing this under version 0.0.1, but haven't re-installed the old version to
check for sure.

Does anybody else see this? (My Mac is about 2 years old, maybe a little
more, but it's not severely under-powered or anything. I've seen it play
video smoothly under much more demanding circumstances.)

I notice that in the code I'm replacing, there is an idle time handler that
calls the Quicktime MCIdle method. I don't know if you're already handling
idle time processing, or if that's even on the right track, but my current
working hypothesis is that adding a wx.EVT_IDLE handler that calls MCIdle
might take care of the problem. However, I'll be the first to admit that's
mostly a guess. It's also not clear to me whether this needs to be handled
in wxQtMovie or if the MCIdle method needs to be exposed but the idle time
handling needs to be done in the end client program.

David

···

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Kevin,

I've attached my modifications to your demo programs "movie.py". It
demonstrates a couple of things of interest, and fixes a couple of minor
issues.

1. SetSize() should be called on self, not self.movie. It's a wx.Frame
method, not a Quicktime method. Thus, the window resizes to match a movie
when loaded now, while it did not before.

2. GetPlaySpeed() returns an integer value, or at least a
rounded-to-whole-number value, rather than the correct speed value. You
will notice this if you try my "increase speed" or "decrease speed"
functions in the Movie menu twice. You get values of 1.0 instead of 1.1,
and 0.0 instead of 0.9 when you call the function the second time.

3. SetTimeUnits() does not appear to have any effect at present. Despite
the TimeUnits being set to 1000 in your __init__() method, implying that
time units should be milliseconds (1000ths of a second), all time units in
the "move forward 10 seconds" and "move backwards 10 seconds" are
nonetheless full second units. That's why your initial SetCurrentTime(9000)
line, which I removed, fails. Notice that all GetCurrentTime() calls are
returned as integer seconds.

4. If we're going to have SetTimeUnits functionality (which I need, as 1
second accuracy in time positioning is not delicate enough for me!), we need
a matching GetTimeUnits() function so that things like my OnForward and
OnBackward methods can be properly implemented. (You need to multiply the
amount of time you want to move by the current TimeUnit to get the proper
value to adjust CurrentTime by.)

5. At least for me, the frame's resize handle in the lower right corner of
the frame covers the Quicktime "fast-forward" button. Not a big deal, but
it is noticeable.

Thanks for your hard work, and I look forward to version 0.0.3.

David

movie.py (5.27 KB)

···

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you

raised.

Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

OK - rather than me complain about this again, is there any way we can
work together on this and create a cross-platform media control?
Windows has it's own animation control, but linux/unix is going to be a
lot tougher.

Another question - what should we name the class?

The MFC version is CAnimateCtrl, so naming it wxAnimateCtrl would cause
the least amount of confusion among MFC users. However, for my own lib
I was planning on wxMediaCtrl.

This seems to be one of the complains of the average user is the lack of
functionality in this category.

Hi Ryan,

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you

raised.

Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

OK - rather than me complain about this again, is there any way we can
work together on this and create a cross-platform media control?

To be honest, I simply have no need for such a thing myself and already have a full plate with other things that I do need. I took on this project because a) part of the changes that broke David's code were changes I promoted and help implement, and b) there was no embeddable media player whatsoever on Mac, while there is one on Windows (WMP via ActiveX, at least). I also took on this project because the scope was small and manageable - I knew it would be a couple dozen hours of work or so, probably not much more. A cross-platform media control is a major project that will take months to complete in such a way that everything works well on Windows and Mac, let alone Linux. Developing for Mac Quicktime alone lets me take a lot of shortcuts like not even have to deal with things like GWorlds or manually set up Qt event handlers (in most cases), etc.

I totally agree with you that such a thing would be great to have, but I simply do not have the time to do it or contribute to it in any major way.

Kevin

···

On Sep 7, 2004, at 4:26 PM, Ryan Norton wrote:

Hi Kevin,

I totally agree with you that such a thing would be great to have, but
I simply do not have the time to do it or contribute to it in any

major

way.

Actually I was referring to me doing the non-mac ports - but I
understand :).

BTW your posts are amazingly eloquent! If you wrote a book on how to
use English better I'd most certainly buy it :).

Ryan

Hi Ryan,

Hi Kevin,

I totally agree with you that such a thing would be great to have, but
I simply do not have the time to do it or contribute to it in any

major

way.

Actually I was referring to me doing the non-mac ports - but I
understand :).

Then I'm a bit confused, because I thought that wxQtMovie is the Mac port? (And thus I thought the issue was making it work on Windows.) IIUC, all that would be needed to make a cross-platform framework would be to write a wrapper around wxQtMovie on Mac, and wxWMP (or whatever) on Windows. Then were you asking about collaborating on API design/wrapper functions?

In terms of making the Mac wxQtMovie port functions work correctly, I most certainly intend to follow through with that, and of course the code is wxWindows License so obviously I have no issues with sharing the code or someone improving upon it.

BTW your posts are amazingly eloquent! If you wrote a book on how to
use English better I'd most certainly buy it :).

Wow, no one's said anything like that to me before. Thanks! =)

Really, the main reason I write the way I do is that I feel miscommunication is one of the worst problems that plague any project, in fact I'd argue it's one of the core issues underscoring most every problem we face. Communication is such a natural and common thing that I feel people often don't see how important it really is and never really question whether or not they could actually communicate better. And I found that the most common factors (in my experience) that cause miscommunication are:

Note that by 'you' I don't actually mean 'you', (often it should mean 'I' :wink: - I'm just too lazy to make all this work in the third person.

1) shooting from the hip - responding immediately before 'digesting' the message, so one may end up responding to a point other than what the original poster made

2) taking it personally - many times people read between the lines to find things that aren't there, so it's good to question whether you're actually being insulted/attacked, or you just think you're being insulted/attacked. I've seen many an upset person over what was originally an honest mistake with no malice involved whatsoever.

3) thinking that others know what you mean - this is a common and honest mistake, but typically this leaves lots of ambiguity in the message and can cause lots of confusion as people interpret it in different ways

4) taking their eyes off the ball - people become so engrossed in discussion/debate that they forget what it is they were debating about and get hopelessly off-track

I've done all these things many times myself, and I ended up feeling I did more to hurt my specific goal than to help it, so when I respond to messages, I try to ask myself if I'm doing any of these things, and if so, I back off and try to think of a better and more objective way to say things. (And you'd be surprised how easy these things are to catch sometimes if you are checking for them.) It takes time, but sometimes spending an extra 20-30 mins on a message could prevent a flamewar (or at least stop it from spreading). There's only so much one can do, of course, but I hope that I'm able to express myself properly because I figure anything I can do to save others some time is time they can spend doing something more productive than arguing over something. :wink:

OK, my unsolicited rant's over, but that's really all there is to know about how I write, no book necessary - if I ever did write a book, I'd definitely write a book about programming. Or Japanese animation. :wink:

Thanks,

Kevin

···

On Sep 7, 2004, at 7:05 PM, Ryan Norton wrote:

Hi David,

Kevin,

I've attached my modifications to your demo programs "movie.py". It
demonstrates a couple of things of interest, and fixes a couple of minor
issues.

1. SetSize() should be called on self, not self.movie. It's a wx.Frame
method, not a Quicktime method. Thus, the window resizes to match a movie
when loaded now, while it did not before.

Actually, self.SetSize() doesn't quite work either, because it seems to include the title bar in size calculations. ;-/ (on my machine, the video was squished vertically about 20 pixels, the size of the title bar. I checked by loading a video into QuickTime and then laying it on top of the wx video window.) It seems a calculation adding approx. 20 pixels for the title bar height will be needed to make the feature work correctly.

2. GetPlaySpeed() returns an integer value, or at least a
rounded-to-whole-number value, rather than the correct speed value. You
will notice this if you try my "increase speed" or "decrease speed"
functions in the Movie menu twice. You get values of 1.0 instead of 1.1,
and 0.0 instead of 0.9 when you call the function the second time.

Fixed, thanks. I was just missing a step in the conversion process.

3. SetTimeUnits() does not appear to have any effect at present. Despite
the TimeUnits being set to 1000 in your __init__() method, implying that
time units should be milliseconds (1000ths of a second), all time units in
the "move forward 10 seconds" and "move backwards 10 seconds" are
nonetheless full second units. That's why your initial SetCurrentTime(9000)
line, which I removed, fails. Notice that all GetCurrentTime() calls are
returned as integer seconds.

After playing with this some more, I realized that SetTimeUnit must be called on each video load. If you add a SetTimeUnit call inside of the OnFileOpen handler, it should start working properly. It would seem to me that this is the appropriate behavior, unless we make SetTimeUnit a static method, in which case it should apply to all videos loaded after the call is made.

4. If we're going to have SetTimeUnits functionality (which I need, as 1
second accuracy in time positioning is not delicate enough for me!), we need
a matching GetTimeUnits() function so that things like my OnForward and
OnBackward methods can be properly implemented. (You need to multiply the
amount of time you want to move by the current TimeUnit to get the proper
value to adjust CurrentTime by.)

Oops, yes, I guess this would be a good idea, huh? :slight_smile: Easy enough.

5. At least for me, the frame's resize handle in the lower right corner of
the frame covers the Quicktime "fast-forward" button. Not a big deal, but
it is noticeable.

This isn't related to wxQtMovie, but is a general issue with writing Mac apps. The Mac drag-resizer control always appears on top of what's at the bottom left of the window. The easy 'cheater' way out of it is to simply create a status bar for the frame. You could even display the total time and current time in there to make it look like it wasn't a hack to fix the drag-resizer problem. :wink: I'll probably put this into the demo sooner or later, but I figured I'd mention in case you want to move ahead on your Transana version.

Thanks for your hard work, and I look forward to version 0.0.3.

I'm going to play with the idling issue (I'm only seeing the occasional stutter myself, but that doesn't mean that everything's working fine!) and see if I can work something out. Carbon handles that internally now, I believe, but I remember reading a note about optimizing the idle handling somehow... Anyways, once I've figured out a way to address this, and added GetTimeUnit(), then unless I hear further reports I'll assume it's time for a 0.0.3!

Thanks,

Kevin

···

On Sep 7, 2004, at 2:36 PM, David Woods wrote:

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

<movie.py>---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

>> I totally agree with you that such a thing would be great to have, but
>> I simply do not have the time to do it or contribute to it in any
> major
>> way.
>
> Actually I was referring to me doing the non-mac ports - but I
> understand :).

Then I'm a bit confused, because I thought that wxQtMovie is the Mac
port? (And thus I thought the issue was making it work on Windows.)
IIUC, all that would be needed to make a cross-platform framework would
be to write a wrapper around wxQtMovie on Mac, and wxWMP (or whatever)
on Windows. Then were you asking about collaborating on API
design/wrapper functions?

In terms of making the Mac wxQtMovie port functions work correctly, I
most certainly intend to follow through with that, and of course the
code is wxWindows License so obviously I have no issues with sharing
the code or someone improving upon it.

What I would love to see, but lack the technical skills to write, is a
common API, wxVideoPlayer or wxMovie or whatever, that would then be smart
enough to call wxQtMovie on Mac, wxWMP for most formats on Windows,
wxQtMovieWin for Quicktime video (and other formats Windows Media Player
doesn't support) on Windows, and wxWhateverMediaPlayerWorksBestOnLinux on
Linix platforms. I can see being able to specify a "preferred" media player
option on initialization and when loading a new video, as well as having
some internal logic that knows to send ((*.mov to wxQtMovieWin) and (*.avi
to wxWMP) on Windows) for example. With this generic, cross-platform
wxMovie infrastructure, I could see additional video components (VideoLan,
mPlayer, whatever) being added modularly with time as people needed them for
specific reasons or just wanted to expand the options available to include
their favorites.

This is essentially what we're trying to accomplish with Transana, where
we've got a common VideoWindow.py module that does little more than provide
a common API to video_msw.py and video_mac.py. Our long-range plans,
assuming we can find the money some day to hire someone more skilled than I
to do it, is to add Quicktime suppport on Windows and, if there's sufficient
demand and funding, some sort of video support on Linux. Unfortunately, at
the rate we're going, that will take several more years.

David Woods, Ph.D.
Transana Lead Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison
http://www.transana.org

Hi David,

> Kevin,
>
> I've attached my modifications to your demo programs "movie.py". It
> demonstrates a couple of things of interest, and fixes a couple of
> minor
> issues.
>
> 1. SetSize() should be called on self, not self.movie. It's a
> wx.Frame
> method, not a Quicktime method. Thus, the window resizes to match a
> movie
> when loaded now, while it did not before.

Actually, self.SetSize() doesn't quite work either, because it seems to
include the title bar in size calculations. ;-/ (on my machine, the
video was squished vertically about 20 pixels, the size of the title
bar. I checked by loading a video into QuickTime and then laying it on
top of the wx video window.) It seems a calculation adding approx. 20
pixels for the title bar height will be needed to make the feature work
correctly.

I didn't notice it, but do see what you mean. Which makes more sense,
having the SetSize(wx.Size()) accept the VIDEO size and adjust the frame to
it, or creating a seperate method SetSizeToMatchVideo(wx.Size(video's size))
which does this but leaves SetSize to behave like all other wx.Frames?

> 2. GetPlaySpeed() returns an integer value, or at least a
> rounded-to-whole-number value, rather than the correct speed value.
> You
> will notice this if you try my "increase speed" or "decrease speed"
> functions in the Movie menu twice. You get values of 1.0 instead of
> 1.1,
> and 0.0 instead of 0.9 when you call the function the second time.

Fixed, thanks. I was just missing a step in the conversion process.

Cool.

> 3. SetTimeUnits() does not appear to have any effect at present.
> Despite
> the TimeUnits being set to 1000 in your __init__() method, implying
> that
> time units should be milliseconds (1000ths of a second), all time
> units in
> the "move forward 10 seconds" and "move backwards 10 seconds" are
> nonetheless full second units. That's why your initial
> SetCurrentTime(9000)
> line, which I removed, fails. Notice that all GetCurrentTime() calls
> are
> returned as integer seconds.

After playing with this some more, I realized that SetTimeUnit must be
called on each video load. If you add a SetTimeUnit call inside of the
OnFileOpen handler, it should start working properly. It would seem to
me that this is the appropriate behavior, unless we make SetTimeUnit a
static method, in which case it should apply to all videos loaded after
the call is made.

That makes sense, sort of. Easy enough to implement, anyway.

> 4. If we're going to have SetTimeUnits functionality (which I need,
> as 1
> second accuracy in time positioning is not delicate enough for me!),
> we need
> a matching GetTimeUnits() function so that things like my OnForward and
> OnBackward methods can be properly implemented. (You need to multiply
> the
> amount of time you want to move by the current TimeUnit to get the
> proper
> value to adjust CurrentTime by.)

Oops, yes, I guess this would be a good idea, huh? :slight_smile: Easy enough.

Excellent.

> 5. At least for me, the frame's resize handle in the lower right
> corner of
> the frame covers the Quicktime "fast-forward" button. Not a big deal,
> but
> it is noticeable.

This isn't related to wxQtMovie, but is a general issue with writing
Mac apps. The Mac drag-resizer control always appears on top of what's
at the bottom left of the window. The easy 'cheater' way out of it is
to simply create a status bar for the frame. You could even display the
total time and current time in there to make it look like it wasn't a
hack to fix the drag-resizer problem. :wink: I'll probably put this into
the demo sooner or later, but I figured I'd mention in case you want to
move ahead on your Transana version.

Thanks. I'll mess with it a bit and see what I like.

> Thanks for your hard work, and I look forward to version 0.0.3.

I'm going to play with the idling issue (I'm only seeing the occasional
stutter myself, but that doesn't mean that everything's working fine!)
and see if I can work something out. Carbon handles that internally
now, I believe, but I remember reading a note about optimizing the idle
handling somehow... Anyways, once I've figured out a way to address
this, and added GetTimeUnit(), then unless I hear further reports I'll
assume it's time for a 0.0.3!

Yeah, it's pretty bad on my 733Mhx G4. Makes me seasick if I watch too
long. It wouldn't be acceptable to Transana users as it is now, and I don't
necessarily think they'll all have new hardware to run the program on.

I'll continue working on it today, and will let you know if I find anything
else.

Thanks, as always,
David

···

On Sep 7, 2004, at 2:36 PM, David Woods wrote:

> Hi all,
>
> I've uploaded a new version of wxQtMovie, which you can download from
> here:
>
> http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz
>
> What's changed:
>
> - Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
> size
>
> - SetPlaySpeed() now works!
>
> - GetMediaState() renamed to GetState() to be consistent with other
> functions
>
> - New functions:
> - GetDefaultMovieSize() - get the original movie dimensions
>
> - GetLoadState() - checks the load state of the movie and returns a
> wxMediaLoadState flag
> (see wxQtMovie.h or qtmovie.i for potential flag values)
>
> - SetTimeUnit( unit ) - sets how many units pass per second
> For example, SetTimeUnit( 1000 ) causes all
time-related functions
> to use milliseconds
>
> - Get/SetCurrentTime( ) - gets/sets current movie position
>
> - GetDuration() - gets the time length of the movie
>
> - Updated the demo to showcase all new features
>
> David, your emails were very helpful towards not only understanding
> what the issues involved were, but also for discovering solutions. I
> think this new version addresses pretty much all the points you raised.
> Everyone, please continue to provide feedback on what works, what
> doesn't, and features you'd like to see! While I don't have time to
> implement a cross-platform multimedia framework at the moment, I do
> want playing Qt movies to work properly on Mac. :wink:
>
> Thanks,
>
> Kevin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org
>
> <movie.py>-------------------------------------------------------------
> --------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

>
> I'm going to play with the idling issue (I'm only seeing the occasional
> stutter myself, but that doesn't mean that everything's working fine!)
> and see if I can work something out. Carbon handles that internally
> now, I believe, but I remember reading a note about optimizing the idle
> handling somehow... Anyways, once I've figured out a way to address
> this, and added GetTimeUnit(), then unless I hear further reports I'll
> assume it's time for a 0.0.3!
>

Yeah, it's pretty bad on my 733Mhx G4. Makes me seasick if I watch too
long. It wouldn't be acceptable to Transana users as it is now,
and I don't
necessarily think they'll all have new hardware to run the program on.

I'll continue working on it today, and will let you know if I
find anything
else.

Okay, the smoothness of playback problem seems to be resolved on my
computer. As long as I specify SetTimeUnit(1000) immediately following
LoadMovie(), video performance is acceptable. If that line is omitted,
performance is really bad. But for the moment, I guess you don't need to
mess with idle handling after all.

David

Kevin,

I'm not convinced that GetState() is working. It appears to return "0" no
matter what the state of the video is.

David

···

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all
time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Kevin,

I've attached a minor revision to my revision of your demo. I fixed up a
couple of minor things, such as the SetTimeUnit() call, and added a "Play
Segment" option.

I have two issues. First, if you load a video then immediately select "Play
Segment", what is supposed to happen is that the video position should jump
to 20 seconds into the video and the video should begin playing. On my
machine, it appears that what happens is that the video position is set to
20 seconds and begins counting up, but that it takes some time (10 to 20
seconds usually) for the video and audio to kick in, by which time I'm no
longer positioned at the 20 second point. You can also see similar problems
with the "Move forward 10 seconds" and "Move backwards 10 seconds" routines.
Random access to different positions in the video just isn't very
responsive.

Second, the desired functionality for "Play Segment" is that I should be
able to define both the start and end points of a segment of video and have
Quicktime play just that specified piece of the larger video. This can be
accomplished with the Quicktime SetMovieActiveSegment method. While I can
work around the absence of this method using a timer, I think it's cleaner
to let the media player handle it.

I've got the integration of wxQtMovie into Transana about 80% complete now.
The only thing I haven't messed with is the LoadState method. I'll have to
wait until tomorrow to do that.

David

movie.py (5.55 KB)

···

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all
time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Hi David,

[snip]

Actually, self.SetSize() doesn't quite work either, because it seems to
include the title bar in size calculations. ;-/ (on my machine, the
video was squished vertically about 20 pixels, the size of the title
bar. I checked by loading a video into QuickTime and then laying it on
top of the wx video window.) It seems a calculation adding approx. 20
pixels for the title bar height will be needed to make the feature work
correctly.

I didn't notice it, but do see what you mean. Which makes more sense,
having the SetSize(wx.Size()) accept the VIDEO size and adjust the frame to
it, or creating a seperate method SetSizeToMatchVideo(wx.Size(video's size))
which does this but leaves SetSize to behave like all other wx.Frames?

I prefer SetSizeToMatchVideo, so that there is a way to set size in the 'typical' manner.

Thanks,

Kevin

···

On Sep 8, 2004, at 7:58 AM, David Woods wrote:

Hi David,

[snip]

What I would love to see, but lack the technical skills to write, is a
common API, wxVideoPlayer or wxMovie or whatever, that would then be smart
enough to call wxQtMovie on Mac, wxWMP for most formats on Windows,
wxQtMovieWin for Quicktime video (and other formats Windows Media Player
doesn't support) on Windows, and wxWhateverMediaPlayerWorksBestOnLinux on
Linix platforms. I can see being able to specify a "preferred" media player
option on initialization and when loading a new video, as well as having
some internal logic that knows to send ((*.mov to wxQtMovieWin) and (*.avi
to wxWMP) on Windows) for example. With this generic, cross-platform
wxMovie infrastructure, I could see additional video components (VideoLan,
mPlayer, whatever) being added modularly with time as people needed them for
specific reasons or just wanted to expand the options available to include
their favorites.

This is essentially what we're trying to accomplish with Transana, where
we've got a common VideoWindow.py module that does little more than provide
a common API to video_msw.py and video_mac.py. Our long-range plans,
assuming we can find the money some day to hire someone more skilled than I
to do it, is to add Quicktime suppport on Windows and, if there's sufficient
demand and funding, some sort of video support on Linux. Unfortunately, at
the rate we're going, that will take several more years.

Why not just shoot off your VideoWindow.py module as a separate module, so that any wxPython user can use it? Worst case scenario, nothing happens, but the best case is that people start chipping in to fill the gaps. Making a true wrapper is really just tedious work (having function wxMediaPlayer.functionX call qt.functionA or wmp.functionB depending on what movie was loaded). Adding features like loading with preferred player and loading from different players wouldn't be difficult, and your VideoWindow.py is no doubt the closest thing wxWidgets or wxPython has to a cross-platform media player.

Also, something I didn't realize but in hindsight is rather obvious - there is an Apple QuickTime COM/ActiveX control on Windows, just like with Windows Media Player. So if someone just wrapped that, we'd be pretty much where everyone would like to be (well, sans Linux support, of course). There wouldn't be a C++ version, but actually for the moment I think that's just fine. Better to prototype and test the control and flesh out the technical matters all from within Python where you can do it much faster. Then, once the API is finished and solid, and most of the major implementation issues have been ironed out, someone can migrate the code to C++ if there's interest, which I'm rather certain there will be.

Just some thoughts to chew on.

Thanks,

Kevin

···

On Sep 8, 2004, at 7:37 AM, David Woods wrote:

Hi David,

After looking at it, I'm convinced too. ;-/ This is my fault, I only implemented state changing when you programmatically call functions like Play, Stop, etc. I'll look into how I can do this properly.

Thanks,

Kevin

···

On Sep 8, 2004, at 12:54 PM, David Woods wrote:

Kevin,

I'm not convinced that GetState() is working. It appears to return "0" no
matter what the state of the video is.

David

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Saturday, September 04, 2004 9:31 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi all,

I've uploaded a new version of wxQtMovie, which you can download from
here:

http://www.theolliviers.com/python/wxpython/wxQtMovie-0.0.2.tar.gz

What's changed:

- Movies can now be resized beyond 100%, wx's Get/SetSize adjusts movie
size

- SetPlaySpeed() now works!

- GetMediaState() renamed to GetState() to be consistent with other
functions

- New functions:
  - GetDefaultMovieSize() - get the original movie dimensions

  - GetLoadState() - checks the load state of the movie and returns a
wxMediaLoadState flag
    (see wxQtMovie.h or qtmovie.i for potential flag values)

  - SetTimeUnit( unit ) - sets how many units pass per second
      For example, SetTimeUnit( 1000 ) causes all
time-related functions
to use milliseconds

  - Get/SetCurrentTime( ) - gets/sets current movie position

  - GetDuration() - gets the time length of the movie

- Updated the demo to showcase all new features

David, your emails were very helpful towards not only understanding
what the issues involved were, but also for discovering solutions. I
think this new version addresses pretty much all the points you raised.
Everyone, please continue to provide feedback on what works, what
doesn't, and features you'd like to see! While I don't have time to
implement a cross-platform multimedia framework at the moment, I do
want playing Qt movies to work properly on Mac. :wink:

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

[snip]

> What I would love to see, but lack the technical skills to write, is a
> common API, wxVideoPlayer or wxMovie or whatever, that would then be
> smart
> enough to call wxQtMovie on Mac, wxWMP for most formats on Windows,
> wxQtMovieWin for Quicktime video (and other formats Windows Media
> Player
> doesn't support) on Windows, and wxWhateverMediaPlayerWorksBestOnLinux
> on
> Linix platforms. I can see being able to specify a "preferred" media
> player
> option on initialization and when loading a new video, as well as
> having
> some internal logic that knows to send ((*.mov to wxQtMovieWin) and
> (*.avi
> to wxWMP) on Windows) for example. With this generic, cross-platform
> wxMovie infrastructure, I could see additional video components
> (VideoLan,
> mPlayer, whatever) being added modularly with time as people needed
> them for
> specific reasons or just wanted to expand the options available to
> include
> their favorites.
>
> This is essentially what we're trying to accomplish with Transana,
> where
> we've got a common VideoWindow.py module that does little more than
> provide
> a common API to video_msw.py and video_mac.py. Our long-range plans,
> assuming we can find the money some day to hire someone more skilled
> than I
> to do it, is to add Quicktime suppport on Windows and, if there's
> sufficient
> demand and funding, some sort of video support on Linux.
> Unfortunately, at
> the rate we're going, that will take several more years.

Why not just shoot off your VideoWindow.py module as a separate module,
so that any wxPython user can use it? Worst case scenario, nothing
happens, but the best case is that people start chipping in to fill the
gaps. Making a true wrapper is really just tedious work (having
function wxMediaPlayer.functionX call qt.functionA or wmp.functionB
depending on what movie was loaded). Adding features like loading with
preferred player and loading from different players wouldn't be
difficult, and your VideoWindow.py is no doubt the closest thing
wxWidgets or wxPython has to a cross-platform media player.

Also, something I didn't realize but in hindsight is rather obvious -
there is an Apple QuickTime COM/ActiveX control on Windows, just like
with Windows Media Player. So if someone just wrapped that, we'd be
pretty much where everyone would like to be (well, sans Linux support,
of course). There wouldn't be a C++ version, but actually for the
moment I think that's just fine. Better to prototype and test the
control and flesh out the technical matters all from within Python
where you can do it much faster. Then, once the API is finished and
solid, and most of the major implementation issues have been ironed
out, someone can migrate the code to C++ if there's interest, which I'm
rather certain there will be.

Yeah, I was planning on doing that if no one else had addressed the issue
once I get the release of Transana 2.0 out. I've got at least a couple
hundred people who've contacted me about a Mac version of Transana and are
waiting none-too-quietly. I am also hoping that delivering an initial Mac
version (as well as an improved Windows version) will shake loose some
badly-needed funding for the project.

Until I do something formal, though, people are welcome to grab
"VideoWindow.py", "video_msw.py", "video_mac.py", and probably
"TransanaConstants.py" from our CVS on SourceForge.
http://www2.wcer.wisc.edu/Transana/Develop has links to our SourceForge page
and to Transana's module documentation for anyone who might be interested.
It's also got my e-mail address for anyone with questions about how to use
it.

David

Hi David,

Kevin,

I've attached a minor revision to my revision of your demo. I fixed up a
couple of minor things, such as the SetTimeUnit() call, and added a "Play
Segment" option.

I have two issues. First, if you load a video then immediately select "Play
Segment", what is supposed to happen is that the video position should jump
to 20 seconds into the video and the video should begin playing. On my
machine, it appears that what happens is that the video position is set to
20 seconds and begins counting up, but that it takes some time (10 to 20
seconds usually) for the video and audio to kick in, by which time I'm no
longer positioned at the 20 second point. You can also see similar problems
with the "Move forward 10 seconds" and "Move backwards 10 seconds" routines.
Random access to different positions in the video just isn't very
responsive.

Strange, I don't get these problems at all on my machine. There is a brief delay, but rarely more than a second. What is your CPU usage before and during the call to Play Segment? I may have to look at idle handling again...

Second, the desired functionality for "Play Segment" is that I should be
able to define both the start and end points of a segment of video and have
Quicktime play just that specified piece of the larger video. This can be
accomplished with the Quicktime SetMovieActiveSegment method. While I can
work around the absence of this method using a timer, I think it's cleaner
to let the media player handle it.

OK, I should be able to wrap this function without much trouble. I'll put this together with the LoadState fix and release a new version.

Thanks,

Kevin

···

On Sep 8, 2004, at 2:36 PM, David Woods wrote:

Kevin,

I have to admit I have no idea how to determine what my CPU usage is on a
Mac. I looked, but couldn't find it. If you'll share the secret, I'll be
happy to report back tomorrow.

I can say that I have NOTHING running but Python. I can also add that I'm
using MPEG-1 video rather than a Quicktime format, which might matter. I
have used 4 or 5 different video files and the behavior is consistent. I
just used a 27 minute MPEG-1 file, and it took 1 minute 14 seconds to start
playing from when I selected "Play Segement". It's a 733Mhz G4 machine.

David

···

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Tuesday, September 14, 2004 7:30 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: Re: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi David,

On Sep 8, 2004, at 2:36 PM, David Woods wrote:

> Kevin,
>
> I've attached a minor revision to my revision of your demo. I fixed
> up a
> couple of minor things, such as the SetTimeUnit() call, and added a
> "Play
> Segment" option.
>
> I have two issues. First, if you load a video then immediately select
> "Play
> Segment", what is supposed to happen is that the video position should
> jump
> to 20 seconds into the video and the video should begin playing. On my
> machine, it appears that what happens is that the video position is
> set to
> 20 seconds and begins counting up, but that it takes some time (10 to
> 20
> seconds usually) for the video and audio to kick in, by which time I'm
> no
> longer positioned at the 20 second point. You can also see similar
> problems
> with the "Move forward 10 seconds" and "Move backwards 10 seconds"
> routines.
> Random access to different positions in the video just isn't very
> responsive.

Strange, I don't get these problems at all on my machine. There is a
brief delay, but rarely more than a second. What is your CPU usage
before and during the call to Play Segment? I may have to look at idle
handling again...

> Second, the desired functionality for "Play Segment" is that I should
> be
> able to define both the start and end points of a segment of video and
> have
> Quicktime play just that specified piece of the larger video. This
> can be
> accomplished with the Quicktime SetMovieActiveSegment method. While I
> can
> work around the absence of this method using a timer, I think it's
> cleaner
> to let the media player handle it.

OK, I should be able to wrap this function without much trouble. I'll
put this together with the LoadState fix and release a new version.

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Hi David,

Kevin,

I have to admit I have no idea how to determine what my CPU usage is on a
Mac. I looked, but couldn't find it. If you'll share the secret, I'll be
happy to report back tomorrow.

Go to /Applications/Utilities/Activity Monitor.app to get CPU usage.

It should bring up a window showing CPU usage (there are tabs on the bottom half of the screen you can use to switch between CPU/memory/etc.). If the window doesn't appear automatically, just go to the menubar and select "Monitor->Show Activity Monitor".

I can say that I have NOTHING running but Python. I can also add that I'm
using MPEG-1 video rather than a Quicktime format, which might matter. I
have used 4 or 5 different video files and the behavior is consistent. I
just used a 27 minute MPEG-1 file, and it took 1 minute 14 seconds to start
playing from when I selected "Play Segement". It's a 733Mhz G4 machine.

Actually, this *does* matter. Loading up an MPEG-1 file gives me the same performance problems, while other files (MOV, AVI) play just fine. In fact, I have a hard time just playing the file - hitting play does not start the movie immediately.

I'll play with manual idling and see if that helps any. Thanks!

Kevin

···

On Sep 15, 2004, at 3:02 PM, David Woods wrote:

-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Tuesday, September 14, 2004 7:30 PM
To: wxPython-dev@lists.wxwidgets.org
Subject: Re: [wxPython-dev] [ANN] wxQtMovie-0.0.2

Hi David,

On Sep 8, 2004, at 2:36 PM, David Woods wrote:

Kevin,

I've attached a minor revision to my revision of your demo. I fixed
up a
couple of minor things, such as the SetTimeUnit() call, and added a
"Play
Segment" option.

I have two issues. First, if you load a video then immediately select
"Play
Segment", what is supposed to happen is that the video position should
jump
to 20 seconds into the video and the video should begin playing. On my
machine, it appears that what happens is that the video position is
set to
20 seconds and begins counting up, but that it takes some time (10 to
20
seconds usually) for the video and audio to kick in, by which time I'm
no
longer positioned at the 20 second point. You can also see similar
problems
with the "Move forward 10 seconds" and "Move backwards 10 seconds"
routines.
Random access to different positions in the video just isn't very
responsive.

Strange, I don't get these problems at all on my machine. There is a
brief delay, but rarely more than a second. What is your CPU usage
before and during the call to Play Segment? I may have to look at idle
handling again...

Second, the desired functionality for "Play Segment" is that I should
be
able to define both the start and end points of a segment of video and
have
Quicktime play just that specified piece of the larger video. This
can be
accomplished with the Quicktime SetMovieActiveSegment method. While I
can
work around the absence of this method using a timer, I think it's
cleaner
to let the media player handle it.

OK, I should be able to wrap this function without much trouble. I'll
put this together with the LoadState fix and release a new version.

Thanks,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org