tag:blogger.com,1999:blog-3573870775606428240.post1162736771561529166..comments2009-12-01T12:52:00.969-06:00Jonathan Thomashttp://www.blogger.com/profile/16385261268721516168noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-3573870775606428240.post-70056700788835755232009-12-01T12:52:00.969-06:002009-12-01T12:52:00.969-06:00@Vadim,<br />MLT can speed up and slow down video. In fact, there is not much that MLT can not do. There are some holes in the documentation, so sometimes you need to ask for help. But, just about everything I have dreamed up for OpenShot can be easily done with MLT. Thanks for the comment!Jonathan Thomashttp://www.blogger.com/profile/16385261268721516168noreply@blogger.comtag:blogger.com,1999:blog-3573870775606428240.post-67379590860632460682009-12-01T07:23:22.189-06:002009-12-01T07:23:22.189-06:00Sad that you had to move over, I&#39;ve already ran into limitations of the MLT framework (ie no speedup or slowing down of the video).<br /><br />Hope it just doesn&#39;t turn out to be a short-term advantage.Vadim Peretokinhttp://www.blogger.com/profile/05972553368691310521noreply@blogger.comtag:blogger.com,1999:blog-3573870775606428240.post-4997635738574846072009-03-17T09:38:00.000-05:002009-03-17T09:38:00.000-05:00First off, thanks for the comments. Just to clarify, the main reason I'm choosing MLT is based on 2 factors:<BR/><BR/>1) It works<BR/>2) It's easy to use<BR/><BR/>It only took me a few hours to have a working demo using MLT. I've spend months tinkering with Gnonlin and have nothing to show for it. I don't think these are shallow reasons for choosing a framework.<BR/><BR/>As far as communication, I don't think the facts are quite right. I've sent numerous emails to Gstreamer, Gnonlin, and Edward Hervey. I have asked many questions in the Gstreamer IRC. I'm a member of the Gstreamer Mailing list, as well as PiTiVi. I didn't just send a single email, and give up. My decision isn't just based on how responsive the MLT team is. It's just the icing on the cake.<BR/><BR/>Also, keep this in mind. The MLT framework is being actively improved... largely due to the involvement of Kdenlive. It's not some old, antiquated framework. If you do an honest evaluation of Gnonlin and MLT (which I feel that I did), you will see than MLT is better than Gnonlin in almost every way. Seriously, it's really good.<BR/><BR/>My suggestion to the Gnonlin team would be the following:<BR/><BR/>1) Improve the documentation for Gnonlin. Write examples in many languages, and showcase all the features. For example, if it supports transitions, then give some concrete examples of how to use them in multiple languages. Working code examples... not just theory. This would be a HUGE help to developers interested in Gnonlin.<BR/><BR/>Thanks,<BR/>-JonathanJonathan Thomashttp://www.blogger.com/profile/16385261268721516168noreply@blogger.comtag:blogger.com,1999:blog-3573870775606428240.post-40444783344631354382009-03-17T08:00:00.000-05:002009-03-17T08:00:00.000-05:00It sounds to me more like the main issue here was communication failure on the 'gnonlin community' side. Something, to be sure, that clearly needs to be addressed (e.g. by pointing people towards gstreamer-devel or the gstreamer irc channel).<BR/><BR/>None of the technical issues you mentioned look particularly severe, most likely bugs that shouldn't be too hard to fix if they are not fixed already. It would be great if you could file bug reports for the issues you ran into in any case (with a few more details), so we can fix them for the next guy who wants to write a video editor based on gnonlin.<BR/><BR/>I was a bit baffled by your one-man-show comment. You're certainly right that it looks like gnonlin is a one-man-show - although more like 1.5 now if you focus on recent commits; however, I'm not sure how swapping the one-man-show gnonlin, which is just a small component based on top of a very actively maintained and used GStreamer framework with a giant community, for MLT, where the *entire framework* is maintained by just one person (judging by the ohloh contributors list), is a good idea. Again, it seems like you're persuaded by your good communication experience (and presumably the fact that the documentation is better, or exists at all). Doesn't seem like the optimal approach to choosing the core component of a long-term software project to me :)<BR/><BR/>In any case, I hope you achieve what you set out to do, be it with MLT or GStreamer.Timnoreply@blogger.comtag:blogger.com,1999:blog-3573870775606428240.post-48866849065760078942009-03-17T04:01:00.000-05:002009-03-17T04:01:00.000-05:00Hi,<BR/><BR/> For starters, yes it seems like I'm the only one *involved* in GNonLin which is bad for the reasons you mentionned. The dead mailing-list/website is also my fault (I should have killed them aeons ago and pointed to the gstreamer website/ml). I think that has lead many people to believe there is a "GNonLin" community, whereas in fact it's just another GStreamer plugin. As to not having enough people knowledgeable about GNonLin... well.. it's just because not that many people seem to need non-linear functionalities in their applications (only audio/video editors need that). So it's kind of hard to push such an argument. Don't email/use dead websites/ml, join the GStreamer community !<BR/><BR/> As for switching to MLT away from GStreamer... it's sad. But let's get the record straight, Diva didn't switch away from GNonlin, it *never* used it ! It was internally redoing what GNonLin already provided... without the full knowledge of GStreamer. So yes, I know the frustration was insanely high for MDK and the rest of the Diva team about that, and understand why they switched, but here you just 'leave' GNonLin and GStreamer without any further look. You only got in touch with me by mail once, I wouldn't call that persistence. The whole point of GNonLin is to offer a simpler approach to using streams by allowing you to talk in terms of positions, duration and priorities (instead of nodes and graphs).... but still being able to combine that with the flexibility of GStreamer (i.e. viewing and encoding a timeline are just a different graph).<BR/><BR/> Is gnonlin complicated ? I guess it is somewhat, but isn't video editing too from a programming point of view ? Check out the number of video editors that have failed in the past. *PERSIST* !<BR/><BR/> Let's carry on to your 'main' problems.<BR/><BR/>* DV playback is choppy... wait. You're most likely not using GStreamer correctly or there's something completely screwed up in your system. DV support in GStreamer is pristine *and* fast.<BR/><BR/>* No mixing of mp3 with video ? What do you mean by that ? How did you do that ? Did you file a bug ?<BR/><BR/>* Transitions work, file a bug requesting an example of using transitions with gnonlin. We also have virtually all smpte transitions available through the smpte plugin. We still haven't got round to integrating it in pitivi right now since we're focusing on other priorities.<BR/><BR/>* GStreamer is complicated. Well... yes. It's the price to pay for a highly flexible framework, but once you understand the basic pipeline/element/signal principles, everything follows the same logic and you all of a sudden get access to an always increasing list of plugins. Using a higher-level/simpler-api framework comes with tradeoffs (you lose all the flexibility).<BR/><BR/>A final remark I just though about... you're using python right ? So... did you check out pitivi's code (git.pitivi.org) for how we use GNonLin ?<BR/><BR/>Please, don't leave GStreamer and GNonLin, come and ask questions, give comments, file bugs and we *will* be answering them (provided you don't use the dead website/ml).<BR/><BR/>Regards,<BR/><BR/> Edwardbilboedhttp://www.blogger.com/profile/00440155533873481574noreply@blogger.com