Re: [wx-dev] wxMovieCtrl
Vaclav Slavik
> >I must have missed it, I didn't notice any talk about including
> > this in the library proper on wx-dev. Any pointers?
>
> You're, uh, kidding, right?
No Ryan, I'm not. Neither of the threads you refer to talk about
including such classes in CVS at all, let alone in the core library.
OTOH, it's been said several times in the past on this list that
video classes are not suitable for the core -- IIRC one of the times
in reply to you, but I may be confusing persons.
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
Mart Raudsepp
> No Ryan, I'm not. Neither of the threads you refer to talk about
> including such classes in CVS at all, let alone in the core library.
> OTOH, it's been said several times in the past on this list that
> video classes are not suitable for the core -- IIRC one of the times
> in reply to you, but I may be confusing persons.
As an alternative, how about having it in core and not building it by
default.
At least in the 2.4 series there are quite a bunch of classes that need
to be explicitly enabled with --enable-<name> to build them. Or set to
enabled in setup.h in other platforms.
Just an idea that makes things easier when wx is built by hand and
wxMovieCtrl is needed but might make things hard when a distro packages
it without wxMovieCtrl but then requires it.
What happened with the policy of getting rid of all contrib's and not
add any new, anyway?
--
With regards,
Mart Raudsepp
Project manager of wxMUD
E-mail: le...@dustbite.net
http://wxmud.sourceforge.net/
Julian Smart
> I'd rather propose a separate "media" library (in addition to "core",
>"net", "html", ...). Although wxMovieCtrl is a rather small class, I'm sure
>many more things could be added to it in the future. So why not start it
>right now?
>
> In any case, I am against inclusion of wxMovieCtrl -- useful as it is --
>in the core for the same reasons as Vaclav.
Possibly there's some confusion here -- core as in not in contrib,
versus core as in the separate 'core' library (distinct from net etc.)
So I think you're advocating that the files stay where they are,
but are added to a separate 'media' library, except in monolithic
builds. Sounds good to me.
Regards,
Julian
Kevin Ollivier
On Nov 7, 2004, at 3:36 AM, Julian Smart wrote:
[snip]
> Personally I don't have Vaclav's reservations about
> it not being eligible for core (any less that wxSound,
> for example). OTOH I wouldn't have a problem with it
> being in contrib/src/media or similar (replacing
> mmedia).
I think we really need to come up with a way of letting developers
easily create and package third party extensions. I agree with your
idea that wxMovieCtrl is a good addition overall, but the thing I don't
like is that it's in core while at the same time:
1. It's complete API isn't finished or determined
2. It is still very much at a basic state
3. It does not work on all 3 platforms.
What this means is that...
> wxHtmlWindow can play animated GIFs... so why
> not movies... it can be viewed as another way of
> giving the user a more interesting experience, and
> attracting developers. I know if I was looking at
> libraries now and saw wxMovieCtrl listed in the wxWidgets
> documentation, that would excite me, if I didn't know exactly
> what I was going to use it for yet.
... developers who see the class are then likely to get frustrated
because it only halfway meets their needs. And again, we're talking
volunteer effort, so will this be polished, stable and complete for 2.6
(which is fast arriving)? Who knows? I know nothing can be perfect on
the first try, but I think we need more strict standards for committing
to wxWidgets proper, especially with an impending stable release, and
this doesn't even have any sort of GTK implementation yet at all.
Not to mention, I actually would have done (and actually, started
doing) the solution quite differently - in part because of an issue
Ryan himself brought up before: what if you want to use wxQTMovie on
Windows? Ryan's current solution doesn't allow for multiple backends
for wxMovieCtrl, even though that will definitely eventually be a
desired feature. (RealPlayer via ActiveX? VideoLan? etc.) What I had
thought would be the best solution is to first write specific backends,
like wxQTMovie, wxDirectShowMovie, wxGStreamerMovie, etc. and then
consolidate the APIs under one wrapper API. So if we have multiple
video players accessible on one platform, each could be used. I had
said this in discussions Ryan was a part of, too, BTW. In fact, that's
why I named what I was working on wxQTMovie instead of wxMovieCtrl...
But it seems Ryan has decided that wxWidgets should not do things this
way.
Please forgive me for being a *bit* frustrated with how all of this has
come about, but I can't help but feel any other way when someone simply
has a tendency to simply ignore my ideas (or call them "religious
arguments") whenever they don't mesh with his, and just does something
else and even commits it without at least attempting a discussion
first. Where's the teamwork?
Anyways, back to the matter at hand, I think a more sustainable
solution to this problem in general is to make it easy to create third
party components (template project folder with sample Bakefile
template, SWIG .i file, setup.py build script, etc. - just "insert
files, C++ flags and linker flags here" then bake it) so that they can
be developed outside of the wxWidgets tree, and then once the component
has reached maturity, and if the developer(s) agree to it, we can look
at the idea of moving it into wxWidgets. I was actually about to
attempt this using wxQTMovie as a sample program...
I personally think wx should move towards the idea of "add-on" library
packs anyways, and wxMovieCtrl would be a perfect candidate for it. (A
class that's incredibly useful for some apps, but not needed by many
others.) One way or another, I think we need to have more stringent
standards for putting things into CVS than whenever a developer decides
(on their own) that it's ready to be in wxWidgets proper.
Thanks,
Kevin
Kevin Ollivier
On Nov 7, 2004, at 3:54 PM, Ryan Norton wrote:
> Hi Kevin,
>
>> Please forgive me for being a *bit* frustrated with how all of this
>> has
>> come about, but I can't help but feel any other way when someone
>> simply
>> has a tendency to simply ignore my ideas (or call them "religious
>> arguments") whenever they don't mesh with his, and just does something
>> else and even commits it without at least attempting a discussion
>> first. Where's the teamwork?
>
> OK - now I'm frustrated.
>
> I asked you (IIRC more than once) on the wxpython-dev if you wanted to
> help -
> http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?12:mss:1466:200409:
> hiifljfodoniaobmpbhf
And you talked to me like I was being unreasonable just because I
didn't do what you wanted me to do. From your message, you obviously
felt you had the right to "complain" because I wasn't dedicating my
time to collaborating with you on a cross-platform media framework. My
time is my time, I have other obligations, and if my reaction was a bit
strong, well, I was reacting to the way you talked to me.
> You said NO -
> http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?12:mss:1468:200409:
> hiifljfodoniaobmpbhf
I said I didn't have time to help (specifically, at that time). Not
having time, having more immediate concerns to address, doesn't mean I
have no interest in any of this at all. It just means I have a
full-time job, and other responsibilities.
And, I didn't exactly stop even discussing the subject. I also stated
(in other messages in this thread) how I saw this whole thing coming
together, and I never heard you say it was a bad idea or something was
wrong with it, or even really discuss it. See here for one of my
statements along these lines:
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?12:mss:1414:200408:
jfkcbjeaboicmockjddh
In fact, I didn't even flat out reject your offer for collaboration,
really I was more confused than anything on if you wanted me to
incorporate wxMediaGraph into wxQTMovie or what exactly you were
referring to by collaboration. When I realized I was probably mistaken
about something, I asked you about it, here:
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?12:mss:1470:200409:
hiifljfodoniaobmpbhf
Apparently you forgot, missed or never read that message, because you
never replied and answered my question. Please don't talk like I'm
being unreasonable when the conversation stopped/broke down at your
end.
But in any case, my main point for writing all this isn't about me. My
point about teamwork isn't about you discussing (or not discussing)
things with *me*, it's about discussing things with the *wx-devs*
before committing a new class. Regardless of what happened on
wxPython-dev, *hardly anyone here read about it* nor did they have a
chance to comment on what you were about to do. Any other dev could
have had a similar concern, and would similarly have had to voice that
concern *after* a commit.
[snip]
> I havn't tested the seeking methods (Length/Tell/Seek) but everything
> else
> is quite "polished" now. I even threw in some stuff for DoGetBestSize
> for
> sizers...
Are you saying you've committed methods that you didn't even test?
*Please* don't do this.
>> I personally think wx should move towards the idea of "add-on" library
>> packs anyways, and wxMovieCtrl would be a perfect candidate for it. (A
>> class that's incredibly useful for some apps, but not needed by many
>> others.) One way or another, I think we need to have more stringent
>> standards for putting things into CVS than whenever a developer
>> decides
>> (on their own) that it's ready to be in wxWidgets proper.
>
> Maybe everybody has the wrong idea about wxMovieCtrl - it was meant to
> be a
> simple "one-shot" class for running animations, not a solve-all.
Well, then I'd argue it'd be a lot less confusing to call it wxVideo
then, not wxMovieCtrl.
> I definately don't want to make it pluggable, and least not for now -
> that's
> going a bit far. Besides, wxQTMovie on windows doesn't have any real
> practical use
Except in the rare case someone's writing something like a video
preview window (which I would like to eventually put into EClass, and
DVDStyler would probably be able to use it too), or like Transana, a
transcription application, where the ability to deal with more video
formats is a definite plus.
It's not an immediate need, no, but it is something I'd like to keep
the door open for, and I don't see any reason why we couldn't or
shouldn't do that.
> - all it could play is .mov and nothing else (that and .wav,
> but wxSound already does that :)).
Actually, I play AVIs and DiVX files on my Mac using QT all the time.
Granted, your point is taken about Windows video APIs being a better
choice, but it most certainly can play a lot more than what you say.
Kevin
Julian Smart
>That's a great idea - I'd be more than happy to maintain it.
>
>BTW is having something like --with-media or something better maybe? Just a
>thought.
I think it's --enable-xxxx usually for this kind of feature. I'm
not sure if we need one setting for the overall library, plus
one each for each feature, or just one setting per feature (e.g.
--enable-mediactrl, --enable-audio, etc.)
We could also include contrib/src/animate (an animated GIF player,
extensible to other similar kinds of flip-book animation).
Regards,
Julian
Julian Smart
>OTOH I don't quite understand why
>did this code have to be removed from the cvs very soon after being added
>to it in this case.
Indeed, I find it very disappointing especially after spending time
looking at it and commenting on it :-(
Regards,
Julian
Kevin Ollivier
On Nov 8, 2004, at 12:42 AM, Julian Smart wrote:
[snip]
> Sure, I would have been happy to see this too. OTOH, a candidate
> implementation followed by discusssion and fast iteration to
> a satisfactory result can work too. Discussion in the absence of
> code can sometimes become morale-sapping.
Actually, I was talking about a simple review of the API design and
general implementation before it was committed. In the absence of code,
certainly, a discussion can sometimes be confusing and frustrating, but
a copy and paste of even just the header file would have been enough to
get people's comments.
[snip]
>>> you never know what interesting consequences will follow from it.
>>
>> But you mean to say that a little quality assurance would not yield
>> *more* interesting or positive results?
>
> QA often happens in wxWidgets after code has been submitted for
> contemplation by others. It's certainly happening with wxMovieCtrl.
> I believe we already had some discussion of movie classes,
> but the balance of implementation versus discussion is something
> people will have different views on.
I'm all for implementation, but with at least a little discussion
before committing that implementation, to ensure everyone is happy with
the API and the overall approach of the solution. It is, of course, up
to you and the other core devs as to whether or not this is a good
thing to do, but I think it would avoid situations like this in the
future. (And not have any significant downsides of its own, except
possibly a day or two's delay.)
[snip]
> A fully-fledged movie player would be great but I think it won't take
> much extra effort to add the necessary controls to wxMovieCtrl,
> as options (definately optional, controlled by styles). So whether
> the user interacts with the movie via built-in controls, or via
> app-defined ones, it seems fine to use the same basic class. After
> all, some existing wxControl-derived classes are simply for display:
> e.g. wxStaticXXX.
I've already commented on the problems with this approach using
multiple back-ends, so I won't repeat them here. Unfortunately, I'm in
the awkward position of trying to argue for a different design after
the implementation has already been committed (and some are happy with
it), and there's also the fact that most people on here don't know
about Transana and the solution that David Woods already put together
for this (on the Python side, though). So we're not quite on the same
page, I don't think.
Anyways, all I can say is that it's a question of whether or not
discussion before committing is something that is desired or in fact
necessary. I've seen some cases in the past where a commit of new code
or major changes to existing code before anyone has had a chance to
review it has caused quite a bit of frustration for some people, and I
think it's morale-sapping when people see these problems occurring, and
reoccurring, and nothing is done to correct the course or improve
things. But maybe I'm the oddball here and everyone else thinks the
current approach has no problems to speak of. If that's the case,
certainly, I'll stop my objections here.
Thanks,
Kevin
Ryan Norton
> I hope Ryan's going to put the classes back (or someone else can).
> It's insane to throw away working code people have been wanting.
> But I understand it's not always easy to maintain motivation.
I thought everybody wanted me to remove it!
I'm so confused...
Anyway, just tell me when and I'll upload them again.
Oh, and I added the ability to play URLs too in my local copy (w/some bugs
on the mac side).
As an actual API question - Should Tell/Length/Seek be
GetPosition/GetDuration/SetPosition maybe?
Ryan
Vadim Zeitlin
JS> It used to be the case that submitting incomplete, but
JS> useful, code was a valuable way of participating in
JS> the project and getting help from others.
Sorry but this is different. I'm absolutely not against submitting
incomplete code, but I'd like to discuss the code before submitting it.
We should learn from the past mistakes instead of continuing as we always
did (even though this is not true: many changes were discussed on the list
before being committed and even written as far back as 1997).
JS> Give the guy a break, this class is already looking good -- sure it'll
JS> be better in due course but looking over the top of one's specs
I didn't see the specs, this is the problem...
Regards,
VZ
Ryan Norton
> Ryan Norton wrote:
>
> > Load() unloads whatever is playing (if any) and [attempts] to
load/stream
> > the new movie in the control.
> >
> > There is a default constructor, and quick constructors like other
controls
> > that call Create(). If the user specifies a string that isnt empty to
> > create (via fileName) or one of the constructors it starts playing the
movie
> > immediately, otherwise (after Load, for instance) the user needs to call
> > Play manually [this gives it the "one-shot" functionality I wanted].
>
> I think that following wxSound's pattern would be nice, where an
> explicit call to Play() would be needed in either case.
Hmmm... OK. I thought the one-shot thing would be nice, but I can do
that....
>
> > GetState() determines whether the movie is playing,stopped or paused
(the
> > difference between the last two is highly artificial).
> >
> > enum wxMovieCtrlState
> > {
> > wxMOVIECTRL_STOPPED,
> > wxMOVIECTRL_PAUSED,
> > wxMOVIECTRL_PLAYING
> > };
> >
> > There's also a EVT_MOVIE_FINISHED event that does what it implies :).
>
> Are there any other notifications that are possible and would make sense
> to have?
I'm not sure - any ideas? (AFAIK the only thing the system does natively is
stop the movie when its done).
TIA,
Ryan
Ryan Norton
> For wxQTMovie I just created a wxMediaLoadState enum and a
> GetLoadState() function to query it. Unfortunately, I couldn't find a
> QT callback that I could hook into to get notified when the file
> finished loading.
On QT you can use PrePrerollMovie and use the callback from that -
http://developer.apple.com/documentation/QuickTime/APIREF/preprerollmovie.htm.
See the code sample of PrerollMovie at
http://developer.apple.com/documentation/QuickTime/APIREF/prerollmovie.htm.
Ryan
Vadim Zeitlin
RN> I raised my objection with wxVideo earlier in the thread that it implied
RN> that it might not be able to play sound-only files (eventually I'll throw in
RN> HasSound and HasVideo for wxMovieCtrl).
I don't know, video doesn't exclude sound for me. OTOH you do say usually
video playback and not movie playback and you can definitely play other
things than movies (live sport broadcasts inside wxPython demo, anybody? ;-)
RN> As for seperating the two - my idea was to just make a window style for it
RN> (I can't really think of a good name at the moment but I'm leaning towards
RN> something like wxWITH_CONTROLLER).
This is because you think about it from QT point of view and QT supports
buttons natively. OTOH I'm thinking about the Unix version where you surely
won't have any buttons and wxVideoCtrl could be a much simpler class than
wxVideoFrame/wxVideoWindow.
RN> The problem with making a movie-only class is that the user would have to do
RN> the nasty stuff like he would have to remember to resize the movie every
RN> time his window resized
Why? Surely the control would resize the video to fit its size
automatically?
RN> plus there is a lot of stuff on mac that makes it difficult to make
RN> useful
But IMO the movie without controls is even more useful than movie with
controls. So we do need to make it work, anyhow.
RN> However, I don't have any real objection to such a thing - we can always
RN> seperate the functionality later, too.
Once API exists you can't easily change it.
RN> I've sort of been taking the wxSound approach with backends in that I only
RN> really create one when I need one (on mac for example there probably will
RN> never be anything else besides QuickTime).
This is not incompatible with backend-based design. You will simply have a
single backend for Mac -- no problem.
RN> > You just need to add a wxVideoBackend class providing all the necessary
RN> > methods (i.e. Play(), Stop(), Seek(), ...) and move your implementation in
RN> > it while keeping a simple "wxVideoBackend *m_impl" pointer in the public
RN> > class. Like this it will be possible to simply switch backends later.
RN>
RN> Right - I was planning on RTTI lookup for those - did you just want me to
RN> call them explicitly instead (i.e. if(can't load with directshow backend)
RN> use another one?)
Sorry, I don't understand this one?
RN> > RN> bool Create(wxWindow* parent, wxWindowID id,
RN> > RN> const wxString& fileName, const wxString&
RN> label =
RN> > RN> wxT(""),
RN> > RN> const wxPoint& pos = wxDefaultPosition,
RN> > RN> const wxSize& size = wxDefaultSize,
RN> > RN> long style = 0, const wxString& name =
RN> > RN> wxPanelNameStr);
RN> >
RN> > I think label is unneeded. It only makes sense for wxVideoFrame IMO.
RN>
RN> MSWCreateControl wants a label parameter though....
It will be always empty for this class.
RN> > Is it worth to use wxTimeSpan here? I would have thought that just an
RN> > "unsigned long seconds" would do, but maybe there is some reason to use
RN> > wxTimeSpan.
RN>
RN> Natively (though DirectShow & QT) I can get better than microsecond
RN> precision - so it makes sense to do milliseconds here.
Yes, I should have written milliseconds instead of seconds. But the point
remains...
RN> I used wxTimeSpan just for user convenience (easy way to specify seconds vs.
RN> milliseconds etc.)
Multiplying by 1000 isn't very hard, and nobody is going to specify
durations in weeks or months here.
RN> maybe I should just use a wxLongLong....
Probably no need: unsigned long is ~4e9 and this is longer than any movie
clip.
Regards,
VZ
Robin Dunn
>
> wxMediaCtrl ?
+1
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Julian Smart
>Å ukasz Michalski wrote:
>
>>wxMediaCtrl ?
>
>+1
+1 also.
Julian
Ryan Norton
>
> > On Tue, 9 Nov 2004 15:16:40 -0800 Ryan Norton <wxpro...@comcast.net>
> > wrote:
> >
> > RN> I've sort of been taking the wxSound approach with backends in
> > that I only
> > RN> really create one when I need one (on mac for example there
> > probably will
> > RN> never be anything else besides QuickTime).
> >
> > This is not incompatible with backend-based design. You will simply
> > have a
> > single backend for Mac -- no problem.
> >
> to begin with. There is Windows Media Player for OS X (which is a
> HORRIBLE program) and there is also VideoLAN client which is nice
> because it supports just about everything.
>
> I can easily see wanting to eventually use a VideoLAN backend on OS X.
> The m_impl design is definitely the way to go.
Oh no... this is not what backends are for with it - eventually I might have
something to do something like that, but it's not going to be as clunky as a
backend for wxMediaCtrl (plus backends for it are not public in any way).
Ryan
Ryan Norton
> RN> Well, I'm assuming how to actually use the backend(s) is left up to me
then?
>
> I think backends should be identified by name with the default name being
> an empty string meaning "choose the default one".
Do you mean as an argument to Create(), like where the label argument was
maybe?
After this issue is resolved I'll go ahead and commit the base files and
maybe a sample...
Ryan