Beta testers needed for vastly different new transcoder, goDromo Media Transcoder

[concalma]

Hello, we are looking for beta testers to try out this new, probably very different to what's out there these days, transcoding tool. You can read all the details of how you can help here: http://godromo.com/gmt/beta/beta-testing but from that page,

What is goDromo Media Transcoder?
goDromo Media Transcoder, or gMT, is an extremely versatile, web based, socially configured, native speeds transcoder. It’s a free service, that allows you to create your own video/audio processing tools and share it with others, all from the web, without having to download anything, with just a few clicks of the mouse.

How does it work?
A profile is created using the gMT editor (http://godromo.com/gmt/editor). With it you can configure over 300 settings (http://godromo.com/gmt/doc/settings) and formats (http://godromo.com/gmt/doc/formats) that will determine the behavior of gMT when it’s run. Once a profile has been created, you can run it visiting it’s public url with your browser.

Then some magic happens.

gMT determines what browser and what operating system you are using, and it will load in your browser a version of ffmpeg/vgtmpeg that has been compiled specifically for your system. Using the settings from the original profile you created ffmpeg/vgtmpeg is run. This is a native process in your computer so it runs as fast as ffmpeg would if you would run it as a standalone application. Better yet, when gMT is run, you don’t have to deal with any of this, the web GUI manages everything for you.

Read all the details about how you could help us on our beta testing info page http://godromo.com/gmt/beta/beta-testing. Specially welcome feature requests, and bug reports.

We want to make gMT a extremely useful and versatile tool, that's rock solid, fast and easy to use.

Thanks for your help.

[setarip_old]

HI!

Once a profile has been created, you can run it visiting it’s public url with your browser.

1) Can it also be configured to run as a standalone application, without having to rely on access to a/your website?

2) Does the installation of your version of ffmpeg/vgtmpeg interfere with versions of ffmeg that may already be installed on the user's system?

[Ghitulescu]

Supposingly items 1 and 2 being not fulfilled...
3) Will the service remain free also after the beta-testing?
4) What would be the advantages of a such system for off-line users (eg I am converting my own videos not having the intention to share them)? For such users, one time download of the needed tools would suffice ... not to mention that your system might fail due to its own (presumptive) sucess (imagine 7 billion users simultaneously accessing your site).

[CruNcher]

Ehh yeah questionable what this should become i mean no cloud involved just creates a ffmpeg with the "best" options for me and runs it in a browser very questionable what for a purpose this has ?
Though if the ultimate goal is to create P2P like system from this native encoder running with connection to the server as scheduler for the reuquired connections (mostly measuring account data) to the other clients it would become interesting (the first cloud P2P encoder) :D
And then you could also think about crazy ideas how to commercialize this on different parts of the chain (x$ per fragment,time,frames,advertising, points, bonus, credits and what not) :) peers could become workers for the clients (persons/companies) and with a central system measuring data needed for accounting would be a breeze.
So im pretty sure this is just the first step to test the Setup Phase on the peers side and overall working ;)
Also looking @ the backend of this being native java driven it should be no problem to get the native encoder that's compiled out ;)

First issue:
Doesnt work in 64 Bit Firefox (Java was not detected)

[concalma]

First issue:
Doesnt work in 64 Bit Firefox (Java was not detected)

I will answer your other questions later, but in order for this to work on a 64 bit browser, I'm assuming windows, you need 64 bit java intalled. Go here:

http://java.com/en/download/manual.jsp

and install the "Windows 7, XP Offline (64-bit)" java version. Both 32 and 64 bit java installs live together on the same system. If you are on MacOS X should work just fine.

[concalma]

1) Can it also be configured to run as a standalone application, without having to rely on access to a/your website?


We think the advantage of having a browser based app is that it will be available across all your machines, with consistent behavior, that is always updated and there is nothing to install is a big bonus. Given that internet connections are pretty common these days seem's like the line can be blurred between a web app and standalone app. If you run gMT you'll see there is a 'use later' button. You can drag this to the desktop or wherever you want in your OS and essentially use this as a standalone app. gMT should work on any browser, but a browser that does page sandboxing like Chrome or IE9 is highly recommended (http://godromo.com/gmt/doc/recommended-browsers).


2) Does the installation of your version of ffmpeg/vgtmpeg interfere with versions of ffmeg that may already be installed on the user's system?


Absolutely not. When you use gMT for the first time a version of the tools is cached in temporary folder in your computer. The tools are completely self contained and independent from everything else in your system so you can rest assured there will be no conflicts in and out. This is a strong design decision we have made, having lived trough windows codec hell a few times over myself, gMT is independent and runs on its own. Nothing is really installed, just a few files cached in a temporary folder, that if the OS deletes, gMT will download again next time you use it. gMT will use the cached files if they are there, so startup time will be minimal most of the time and nothing will get downloaded if you already used the tool once.

Actually, gMT can run different versions of itself concurrently without problems (bugs permitting, of course). This is also a design feature, see the rationale for this (http://godromo.com/gmt/doc/version-lock) and why using version lock with gMT here (http://godromo.com/gmt/doc/version-lock)

[smok3]

very interesting and exactly something i would do if i had the knowhow. I think in this stage it is important to tell users that no video is uploaded to your servers, that we are dealing with a cloud app, the transcoder (in this order).

p.s. seems to be working javaless as well (natty 64bit running chromium).

[concalma]

Hello Ghitulescu,

Supposingly items 1 and 2 being not fulfilled...
3) Will the service remain free also after the beta-testing?

Yes, we have all intentions to keep the service free after beta testing. Actually the tools are all live and ready to go and anyone out there can use them, but I'm calling a 'beta testing' phase because only a small group of people have used gMT and I'm sure there are issues.

As far as revenue model goes, we are more interested right now in finding out if there is any interest in the new architecture we are proposing, and getting feedback from the community to help us shape the architecture. We do have some advertising on the site to help pay the hosting/engineering costs but we would really like to keep this as open and free as possible.


Supposingly items 1 and 2 being not fulfilled...
4) What would be the advantages of a such system for off-line users (eg I am converting my own videos not having the intention to share them)? For such users, one time download of the needed tools would suffice ... not to mention that your system might fail due to its own (presumptive) sucess (imagine 7 billion users simultaneously accessing your site).

First let me assure you that the tools are downloaded only once and cached in a temporary folder in your computer, and unless the folder is deleted by either the OS or you, the startup time and data usage after the first time will be minimal. It's all automatic and the user doesn't have to do anything. gMT will figure out what's best to do so speeds are faster. The system is designed to scale and should stand its own under load.

Also, from a community point of view, this is NOT about sharing videos but rather sharing your own tools or configurations of gMT between all of us can get ready to go tool, making the 'how do I convert this to that' as simple as sharing a link with someone.

Even for the single user scenario, where you go and create profile with gMT for self comsuption, the advantages of gMT vs the traditional 'downloaded tool model' are many:

Configure once, use forever
An essential part of the design of gMT is the idea of a 'persistent tool' in which you can rely on no matter what computer do you use, anytime, anywhere. If you one day decide to move to a Mac or Linux from Windows, the profiles you created with gMT two years ago will be there, behaving the same way. If you move back to windows your profiles will be the same. Long gone will be the days where you had to download little pieces of software on every machine, configure them and go. The version lock (http://godromo.com/gmt/doc/version-lock) feature is part of this philosophy.

Instant availability
If you make changes to your gMT profiles those changes will be available instantly to all your own computers without having to install anything.

Easier to configure, easier to run
Let's face it. Some of the video conversion tools are not the easiest thing to use. Ffmpeg while extremely versatile and powerful has so many parameters that 'getting it right' can be tricky.

Like when you want to get something done and have someone helping you. The old way equivalent of this would be you downloading a tool, installing it and having your friend or someone telling you how to configure it. We want to simplify that. Your friend will give you a URL and you will use it.

Tool isolation
Most tools out there tend to have dependencies, they install things in your computer, or things that are installed are incompatible with the tool. Windows programs tend to be a notorious example of this. gMT is designed to run in isolation with no dependencies, to eliminate chances of something break. Better yet, you can run multiple versions of gMT simultaneously, without any issue.

I'm sure there are more benefits, but this question gave me the idea that we can include all this into the FAQ. Thanks.

[concalma]

Ehh yeah questionable what this should become i mean no cloud involved just creates a ffmpeg with the "best" options for me and runs it in a browser very questionable what for a purpose this has ?

Please read my reply to Ghitulescu about what we consider the benefits of goDromo Media Transcoder when compare to traditional downloadable tools. I'll update the FAQ online to reflect this.


Though if the ultimate goal is to create P2P like system from this native encoder running with connection to the server as scheduler for the reuquired connections (mostly measuring account data) to the other clients it would become interesting (the first cloud P2P encoder) :D ...
So im pretty sure this is just the first step to test the Setup Phase on the peers side and overall working ;)


We are open to all ideas on how to improve this and a P2P transcoding system has crossed my mind and it's in the realm of possibilities.

One important thing to note is that gMT doesn't pretend to be a GUI over ffmpeg. We have forked ffmpeg into vgtmpeg because that was the easiest way to get a big chunk of functionality in place but goDromo Media Transcoder should be seen more about what it does than how it does it, meaning that we may add functionality that is outside the realm of ffmpeg but still be integrated into gMT as a cohesive whole. Meaning that the user should be more interested about what gMT can do than how it actually does it.




First issue:
Doesnt work in 64 Bit Firefox (Java was not detected)

I'm assuming you don't have 64 bit java installed in your system, windows I'm assuming. Go here http://java.com/en/download/manual.jsp and install 64 bit java. 64bit and 32bit java can coexist happily on windows.

[concalma]

very interesting and exactly something i would do if i had the knowhow. I think in this stage it is important to tell users that no video is uploaded to your servers, that will are dealing with a cloud app, the transcoder (in this order).

p.s. seems to be working javaless as well (natty 64bit running chromium).

Hello 'smok3'. Thanks a lot for your advice, I didn't realize people may think that somehow this is uploading your content anywhere. Everything stays local.

The linux install you are using must have OpenJDK installed otherwise it wouldn't run. I do check that gMT runs well on Ubuntu as it's my main development platform for all this thing. The compile farm and our automated QA regression system also runs Ubuntu but there is more eyes on making sure that things work as expected on the Windows/MacOS X side.

And yes, getting this thing to work was easier said than done, but now it's getting done and hopefully getting better :)

[smok3]

yeah, i was wrong, i have java:
java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

[RandomEngy]

"but if the concept caches on"

*catches

Certainly an interesting idea... I'll give it a spin when I get home. Is Java the shell here that you're using to invoke native code that does the heavy lifting for encoding?

Oh and FYI the motion lines to the left of Dromo look a little bit goofy... like a kid's drawing making a car go fast or something.

[concalma]

"but if the concept caches on"

*catches

Certainly an interesting idea... I'll give it a spin when I get home. Is Java the shell here that you're using to invoke native code that does the heavy lifting for encoding?

Oh and FYI the motion lines to the left of Dromo look a little bit goofy... like a kid's drawing making a car go fast or something.
Java provides multiple things.

A way to enable a native web app. There is Google's NaCl that tries to solve the native web app dilemma but is very Chromeish and even Firefox doesn't seem to believe in that model. Java provides the ability to run native code through the use of signed java apps in the java plugin, so we've gone through the trouble of getting the app signed by GlobalSign to make sure people can trust the app. We totally recommend that people take a look at this page (http://godromo.com/gmt/doc/security) with information about the signature credentials that guarantees that the app is legit.

The Java side of gMT also provides multiple logistics. Caching of native binary bundles so startup time is minimal once things are cached, local configuration store, and most importantly a lot of the heuristics of behind the transcoding policies between the input media, the defined profile through the gMT profiling system and the output media. Most of it is not currently documented but I plan to add docs online about a lot of these things as/if we progress forward.

Obviously all the heavy lifting is done with native code on vgtmpeg, our augmented ffmpeg fork, which allows us to use wonderful things like SIMD assembly, multithreading x264 encoding and all those things you can only do with native code, in a reasonable amount of time, that is.



Oh and FYI the motion lines to the left of Dromo look a little bit goofy... like a kid's drawing making a car go fast or something.
It was supposed to be something like '..making a car go fast or something' but definitely not goofy. Frankly, I haven't spent much time on the design of the site and I'm spending more on coding of gMT than anything else. That said, we thought it would be cool to have a mascot, Dromo, and there is actually a backstory about him that's related to the motion lines. But we'll have to delve into those matters some other time.

[Selur]

http://godromo.com seems to be down,..

[concalma]

http://godromo.com seems to be down,..
Thanks for the report. There was a problem with some changes we released on the server. Should be fixed now. Sorry for the inconvenience.