Release of gstreamer win32 port is near ....

[ChristianHJW]

Hi,

it has been comparably silent from us for a couple of weeks, mainly because we all had to fight with real life issues ( especially Mosu and myself ), and the core devs around robux4 were working hard on setting up a new server configuration for matroska.org ( bigger part is hosted on a powerful Russian server now .... big thanks to Haali :) !), overworking the website completely and also on the

win32 port of Gstreamer ! ( codename : Winstreamer, but the Gstreamer guys dont like that a lot ;) )

This weekend it seems robux4 finally had a real breakthrough, he has some basic functionalities working. Unfortunately his last CVS commit to Gstreamer CVS broke the Linux builds :D, but the guys are working on this already.

I am turning to you with a couple of questions that should help us to set the right release date. Please give us an idea on how we should proceed now.

Thanks

Christian
matroska project admin

[stax76]

I voted for "I am a multimedia app developer, but not really interested in Gstreamer". I'm skeptical that Matroska, GStreamer, Linux etc. is so much better, so much required or so much easier etc. than MP4, DShow, Windows etc. I'm not a expert in C/C++/COM+/Linux and I'm not a expert in any AV formats and frameworks, my knowledge is rather sketchy, so consider my vote as not much important. If you guys produce something that makes things easier for me you can be sure you have all my support. I'm not ignorant to those things or think I'm right, I examine constantly what fits my needs best, what's the easiest solution and when it's time I'm making the switch. Only thing I know is what I've done so far with C/C++ and COM+ was much harder compared to managed API's and managed code in VB .NET. I hope your API's are gone be managed without C/C++/COM+ semantics, rich, easy to use and well documented with example applications. If that's the case more developers will be able working with it.

[filewalker]

I recently read athttp://gstreamer.freedesktop.org/ about it.

Which benefits, do you think, will Matroska have with Gstreamer instead of DShow framework?
Will it be a breakthrough in some issues for Matroska?

Cu filewalker

[Koepi]

Is this really a poll about vaporware chris?

I thought you knew better in the meantime.

[stax76]

"Which benefits, do you think, will Matroska have with Gstreamer instead of DShow framework?
Will it be a breakthrough in some issues for Matroska?"

there are probably a lot benefits like it's open source, so if it sucks, you have problems or whatever you can work on it, you can port GStreamer filters to WinStreamer which would also be a big benefit.

[bond]

where is the "i am not going to vote on chris' polls anymore until i see a working binary of what he always promises" ;)

[Mosu]

Originally posted by bond
where is the "i am not going to vote on chris' polls anymore until i see a working binary of what he always promises" ;)

That one would be unvotable in one of Chris' polls, wouldn't it? ;) (yes, I know what you meant)

[robUx4]

Originally posted by Koepi
Is this really a poll about vaporware chris?

I thought you knew better in the meantime.

Last time I heard about vapourware it was about Matroska that was a silly idea that would never work...

GStreamer on Windows definitely works from the current CVS (and is now compatible with the Linux build). I created a Matroska file with it, no coding required. (OK the file is not playing fine because I don't know the right command to use)

I will release the binaries shortly so that everyone can give it a try.

(BTW, Windows is officially supported by the GStreamer ppl)

[robUx4]

Originally posted by bond
where is the "i am not going to vote on chris' polls anymore until i see a working binary of what he always promises" ;)

Now you can vote (http://mukoli.free.fr/gstreamer/gstreamer-win32-alpha1.rar).

[Hiro2k]

Where is the "I'm a mod so I need to see this first!" :p

Let's see what we can do with this new alpha release.

[robUx4]

Originally posted by Hiro2k
Where is the "I'm a mod so I need to see this first!" :p

Let's see what we can do with this new alpha release.

Not much I'm afraid (http://thread.gmane.org/gmane.comp.video.gstreamer.devel/11456). But it's a good start. It's quite windows friendly for developpers now. So people like me should not be afraid to work on it anymore :D

[ChristianHJW]

Originally posted by Hiro2k Let's see what we can do with this new alpha release. ... as robux4 said, not a lot yet. That was exactly the point of the poll, to make a decision based on it when we should release it.

Windows Devs interested in what can be done with Gstreamer can now dive fully into the code and play with it, for advanced users there are not enough plugins compiled/working yet, and unexperienced users like me ( who need a GUI ;) ) simply cant do anything with it.

Based on the results of the poll, i had planned to talk to the guys when we will make it public. Of course, all the 'vapourware' talk forced us to release what we have. I really wonder how much the matroska team has to suffer until this shit will finally stop ....

[BlackSun]

I wish I was able to post in the private forum again to get some things clear :rolleyes:

There is some stupid comments there (yeah like mine)

[Lefungus]

I'm glad Gstreamer for windows has been released. Gsreamer has lots of momentum under *nix variants. New-generation audio/video players will or are currently using it. Porting gstreamer on win32 means we can finally see a viable cross-platform framework to work on. Both platforms will benefit from it.

[unmei]

i think there should be a "libintl2.dll" in the package. I copied and renamed intl.dll to that name and it works somehow this way. Also the plugins give no popup if they are copied into the bin folder (but functionality seems the same in either folders).

Apart from that, the mka i demuxed to mp3 gives the very feeling from when playing with mkxds 14 or 15 months ago -- it plays, choppy, but it the hell of plays. Both in foobar and winamp. COOL!

[robUx4]

Why did you need libintl2.dll ? It's not in my PATH and not in these dir and I have no problems. Or maybe it's the reason why there are some strange warnings ? (I have libint-2.dll but no libintl2.dll on my computer and it's not in my PATH)

What kind of popup are you talking about ? When you add a plugin in plugins/ you have to re-run gst-register.exe.

Thx for testing, I'll add much more plugins for the next release.

[Kurosu]

It's good to know that a project increases the number of platfoms on which it works, especially one which fills a huge gap. I'm sure people that have written input/output plugins for very specific platforms will see the benefit of having an universal framework (yet not codec interface).

I understand that this poll might help RobUx4 to decide where he should invest his free time, but maybe the Matroska constant references were a bit too numerous ;)

Overall, RobUx4, you has my full (moral :p) support to continue your work on both projects, although, not as an user, I think Gstreamer is more in need of your help. Let's see where it will take us, and hope it'll help the coming of other universal (or at least working on many mainstream platforms) tools!

[ChristianHJW]

Originally posted by Koepi Is this really a poll about vaporware chris?I thought you knew better in the meantime.

No its not. You owe me an apology Koepi, i leave it to you when you want to give it to me, and to the whole matroska team. Even powerful supermods of extremely influential webforums should be able to apologize if they made a mistake, and in public.

Show us you have the nuts to do that.

Christian
matroska project admin

[alexnoe]

[ shit inserted by someone else who couldn't make up an own post ] guys, plz cool down, lets get back to the topic! it doesnt help anyone to "mehr öl ins feuer zu schütten"!
and it especially doesnt help anyone if a thread about gstreamer turns into a flamewar and everyone forgets about discussing and testing it

edited :D
[ end bullshit ]
-----------------

Pfui, Bond. Schäm dich. Shame on you. Honte à toi. I would have expected that from someone, but not from you. It should be comprehensible even for some people even more stupid than some here that you chose the wrong post to edit. :angry: :scared: :eek:

[unmei]

OK, more details coming
(1) copy the content of /bin into C:\gstremer\bin and the content of /plugin into C:\gstreamer\plugin (i don't copy registry.xml now as it build in another place later and was not overwritten the first time)

note these things are long now, conclusion is at end of (7) and fix is doing (8).

(2) run gst-register.exe
-> results in this popup
http://www.hta-bi.bfh.ch/~seilf/doom9/gst_01.png

and nothing being done. (yes you were right, not libintl2.dll, but libintl-2.dll)

(3) copy intl.dll to libintl-2.dll (now i have BOTH a libintl-2.dll and intl.dll in my bin folder, which are the same)

(4) rerun gst-register
output (probably copped on top by console buffer):

[..]
** (process:3292): CRITICAL **: unimplemented vararg field type 38282751
[repeat several times]
** (process:3292): CRITICAL **: unimplemented vararg field type 1899767295
[repeat even more times]
** (process:3292): CRITICAL **: unimplemented vararg field type 38282751
[repeat several times]
** (process:3292): CRITICAL **: unimplemented vararg field type 1899767295
[repeat several times]
** (process:3292): CRITICAL **: unimplemented vararg field type 1897670143


** (process:3292): CRITICAL **: unimplemented vararg field type 1900029439


** (process:3292): CRITICAL **: unimplemented vararg field type 1899767295


** (process:3292): CRITICAL **: unimplemented vararg field type 1897670143
[..39 and ..95 then alternate a lot of times]
[and finally]
Rebuilding global_registry (c:\gstreamer/registry.xml) ...
Added plugin gstaudiofilter with 0 features.
Added plugin gstaudio with 0 features.
Added plugin gstspider with 2 features.
Added plugin gstoptscheduler with 1 feature.
Added plugin gstelements with 13 features.
Added plugin gstbytestream with 0 features.
Added plugin riff with 0 features.
Added plugin matroska with 2 features.
Added plugin avi with 2 features.
Rebuilding user_registry (C:\Documents and Settings\hekisa/.gstreamer-0.8/registry.xml) ...
Loaded 9 plugins with 20 features.

C:\gstreamer\bin>

(5) gst-inspect

gstspider: spider: Spider
gstspider: spideridentity: SpiderIdentity
gstoptscheduler: opt: An optimal scheduler using no cothreads
gstelements: aggregator: Aggregator pipe fitting
gstelements: fakesrc: Fake Source
gstelements: fakesink: Fake Sink
gstelements: fdsink: Filedescriptor Sink
gstelements: fdsrc: Disk Source
gstelements: filesrc: File Source
gstelements: filesink: File Sink
gstelements: identity: Identity
gstelements: md5sink: MD5 Sink
gstelements: shaper: Shaper
gstelements: statistics: Statistics
gstelements: tee: Tee pipe fitting
gstelements: typefind: TypeFind
matroska: matroskademux: Matroska demuxer
matroska: matroskamux: Matroska muxer
avi: avidemux: Avi demuxer
avi: avimux: Avi multiplexer
gstcoreelements: queue: Queue
gstcoreelements: thread: Threaded container
gstcoreelements: pipeline: Pipeline object
gstcoreelements: bin: Generic bin

(6) C:\gstreamer\bin>gst-launch filesrc location="Opening theme -full.mp3" ! matroskamux ! filesink location="test.mka"
->results in this popup
http://www.hta-bi.bfh.ch/~seilf/doom9/gst_02.png
and the following output to console:

Starting parse
Entering state 0
Reading a token: Next token is token IDENTIFIER ()
Shifting token IDENTIFIER, Entering state 2
Reducing stack by rule 1 (line 503), IDENTIFIER -> element
Stack now 0
[..]
Stack now 0 14
Entering state 28
Next token is token IDENTIFIER ()
Shifting token IDENTIFIER, Entering state 2
Reducing stack by rule 1 (line 503), IDENTIFIER -> element

** (process:2268): CRITICAL **: how to remove plugins?

** (process:2268): CRITICAL **: Factory for `matroskamux' has no type. This probably means the plugin wasn't found because the registry is broken. The plugin GStreamer was looking for is named 'matroska' and is expected in file 'c:\gstreamer/plugins/gstmatroska.dll'. The registry for this plugin is located at 'c:\gstreamer/registry.xml'
Error: popping token IDENTIFIER ()
Stack now 0 14 28
Error: popping nterm link ()
Stack now 0 14
Shifting error token, Entering state 27
Reducing stack by rule 31 (line 639), chain error -> chain
Stack now 0
Entering state 14
Reading a token: Next token is token LINK ()
[etc]
Now at end of input.
WARNING: erroneous pipeline: no element "matroskamux"
Trying to run anyway.
RUNNING pipeline ...
Execution ended after 1028 iterations (sum 921000000 ns, average 895914 ns, min
0 ns, max 50000000 ns).

C:\gstreamer\bin>

the resulting mka plays perfect (without stuttering) in TCMP but foobar2k says its a invalid matroska.
MKInfo says it has no level 0 node and matroska properties do not show up (both are older versions but see below)
TCMP console:
> File will be opened now !
..
> Core: Adding MPEG Layer-3 Decoder
> Core: RenderFile()...
...
> We should be playing now.
> Everything seems to be ok, birds are singing...
> Matroska CDL: A Matroska file is starting playback
> Matroska CDL: Searching tracks for a video track
> <===== Leaving LoadMediaFile. 1

BUT if i rename the file to .mp3
winamp plays the file and has correct file info. my winamp doesnt know about matroska..
AND foobar also plays and recognises this file with .mp3 extension
which leads me to the conclusion the ouptput is NOT matroska but a normal mp3 with btw is on the byte the same size as the input mp3.

(7) C:\gstreamer\bin>gst-launch filesrc location="Shonen Knife - Konnichiwa.mka" ! matroskademux ! filesink location="test2.mp3"
->The same popup and it also does something.
The resulting file this time seems to be a valid MKA (not mp3) with the same size as the input.

Conclusion at the moment these two operations are simply coping the file 1:1

(8) adding the plugins folder to windows PATH

(9) same input as (6) (attempt mp3 to mka muxing)
console:
** (process:3988): CRITICAL **: unimplemented vararg field type 38282751
[above is repeated a dozen of times]

Stack now 0 14 28
Entering state 8
Reading a token: Next token is token LINK ()
Reducing stack by rule 27 (line 570), element -> chain
[..etc, nothing that looks like warning or error..]
Entering state 15
Now at end of input.
RUNNING pipeline ...
Execution ended after 1027 iterations (sum 1753000000 ns, average 1706913 ns, mi
n 0 ns, max 40000000 ns).

the resulting file is now slighly larger and seems to be a valid matroska. It doesnt play in foorbar (no decodable streams found).
TCMP plays it choppy after a very long load time. TCMP console:
> Opening C:\gstreamer\bin\test.mka
> Matroska CDL: Found Matroska File
..
> Bitrate: 0 KB/s
> Extension: MKA
> Codec:
> EncodingStyle:
> Comment:
> Extended:
> [Error] : Identifier expected
> Checking header...
> Prepare to summon filters...
..
> File will be opened now !
..
> Core: Adding MPEG Layer-3 Decoder
> Core: RenderFile()...
> Core: RenderFile() rendering time: 501ms
> The operation completed successfully.
..
> We should be playing now.
> Everything seems to be ok, birds are singing...
> Matroska CDL: A Matroska file is starting playback
> Matroska CDL: Searching tracks for a video track
> Matroska CDL: Found a video track
> <===== Leaving LoadMediaFile. 1

and finally MKVinfo thinks

(MKVInfo) + EBML head at 0
(MKVInfo) + Segment at 32
(MKVInfo) |+ Seek head at 44
(MKVInfo) | + Seek entry at 56
(MKVInfo) | + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo) at 66
(MKVInfo) | + Seek position: 96 at 73
(MKVInfo) | + Seek entry at 84
(MKVInfo) | + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks) at 94
(MKVInfo) | + Seek position: 139 at 101
(MKVInfo) | + EbmlVoid (size: 26) at 112
(MKVInfo) |+ Segment information at 140
(MKVInfo) | + Timecode scale: 1000000 at 152
(MKVInfo) | + Duration: 0.000s at 159
(MKVInfo) | + Muxing application: GStreamer at 170
(MKVInfo) |+ Segment tracks at 183
(MKVInfo) | + A track at 195
(MKVInfo) | + Track number: 1 at 204
(MKVInfo) | + Track type: video at 207
(MKVInfo) | + Default duration: 9223372036854.775ms (0.000 fps for a video track) at 210
(MKVInfo) | + Video track at 222
(MKVInfo) | + Pixel width: 16 at 231
(MKVInfo) | + Pixel height: 16 at 234
(MKVInfo) | + Codec ID: V_MPEG1 at 237
(MKVInfo) | + Name: Video at 247
(MKVInfo) |+ Cluster at 256

(10) same input as (7) (attempt matroska demux)

output: again fist a couple of the vararg critical warnings, then a normal start

Stack now 0 14 28
Entering state 8
Reading a token: Next token is token LINK ()
Reducing stack by rule 27 (line 570), element -> chain
[..]
Stack now 0
Entering state 15
Now at end of input.
RUNNING pipeline ...
ERROR: from element /pipeline0/matroskademux0: Could not demultiplex stream.
Additional debug info:
d:\perso\programmes\gstreamer\gst-plugins\gst\matroska\ebml-read.c(184): ???: /p
ipeline0/matroskademux0:
Invalid EBML ID size tag (0x0) at position 4135 (0x0)
Execution ended after 1 iterations (sum 0 ns, average 0 ns, min 0 ns, max 0 ns).

Now this doesn't work, and no ouptput file is generated.
This is probably normal, i.e it would also not yet work if i had the real libintl-2.dll and my paths and everything were set up as on the developers computers.

------------------------
Summary: for tests, further than what is said in the readme, add the plugins directory to your windows PATH.
And the libintl-2.dll is required but missing in the package. This can be patched in a dirty way by a dummy (mine was a copy of the intl.dll). It seems to work somehow.
Developers should please check if libintl-2.dll is actually required. If yes please include it in a future package. If not, find the place that erronuously wants to load it and remove that useless statement.

[edit]forgot the images..

[robUx4]

New release package (http://mukoli.free.fr/gstreamer/gstreamer-win32-alpha2.rar). This time with many more plugins (much more to come). This is just the same thing with more plugins and some fixes in some plugins. This time you might be able to do some nice manipulations of audio and video files. But I haven't tested anything yet (I have seen a bug with gst-register in the release build, though).

It's still a debug build. So you might need the MSVCR71d.dll file.

edit: includes 59 internal plugins and 6 core ones

[Neo Neko]

Anyone have a copy of msvcr71d.dll etc? I would like to test but I don't have and have not found that DLL yet.

[unmei]

here (http://homepage.hispeed.ch/mieru/doom9/MSVCR71D.DLL)

now i am really surprised i have such a file for once. I wonder what installed it if it's not part of XP itself..

[edit]
Now there is another missing DLL, libiconv-2.dll which the now included libintl-2.dll depends on (sorry robux) :rolleyes:
probably next time libiconv-2.dll depends on onother libXY-2.dll ...

I did exactly the same two commands as last time:
I still get those

CRITICAL **: unimplemented vararg field type <varying number>

messages.

Other than that, the muxing of mp3 into mka still works with about the same success. Fb2k doesnt play it except when i rename it to mp3 (but its clearly a matroska file, not a raw mp3).
MKVinfo and the shellextension report track type V_MPEG1 and a huge duration. TCMP plays it with *.mka extension but doesnt display a duration.
What i think is new TCMP sees a ID3v1 tag with the info that was in the mp3 (i think attached ID3 is not ok for matroska, shouldn't that go into matrsoka tags..)

Demuxing of mka (made with mkvmerge not gstreamer) into mp3 still doesn't produce a file.

Could you include some primitive help file with what one can do already?
Most likely you always have
filesrc location="file" ! function ! filesink location="otherfile"
also i guess all the middle parts of output lines of gst-inspect are valid function names.
Example:
gsttags: vorbistag: vorbis tag extractor
-> function name = "vorbistag"
Also, how to configure these functions? I guess some of them need parameter..
CLI-parameter, configfile or how is it done?

[robUx4]

Yeah, there is an alpha3 available with libraries all built by myself with MSVC. So there won't be any compatibility problems anymore.

I'm currently in the process of unifying the build of all these libraries, have debug info for all, etc. That will be very usefull to work. I'll make a webpage describing how to do this.

About the GStreamer problems, I just have compiled more libraries. So the same problem remains. But once I will get a better working environment, it will be way easier to track these bugs/problems.

There is a GStreamer documentation available (http://gstreamer.freedesktop.org/documentation/). I'll update the build process for Win32 when everything is ready. But that will be next week...

edit: to configure a plugin it's like when you use location="file.mp3", it's in the command line. With gst-inspect you can know which parameter are available for a given plugin.

[robUx4]

I uploaded new alpha4 in my webspace (http://mukoli.free.fr/gstreamer/).

There are 4 packages :
- 2 for GStreamer (Release and Debug builds) -> install in c:\
- 2 for the dependencies (Release and Debug builds) -> install in c:\

All were compiled with MSVC7 with the correct system DLL dependencies. That should help track bugs when they appear. (.pdb files are provided with the Debug build of dependencies)

No feature or plugin was added this time.

I will publish a new compilation guide tomorrow for both GStreamer and the dependencies. As well as make patches available for all the stuff I've modified in each library...

edit: corrected the link

[Zarxrax]

So um... what exactly *IS* this, why do we need it, and how will it help matroska? From the faq on the Gstreamer site, it sounds like its something like a foundation to build things like media players on top of :confused:

[robUx4]

You could build a player, a video editor or something like mkvtoolnix with GStreamer. And because of the plugin nature it allows many things that are not possible yet and you don't have to develop everything yourself (there are already many things done that could improve what you can put in Matroska and How). It also works on Linux and OS X unlike DirectShow (more devs, more bugs fixed, cleaner code).

Of course right now for the end user it's not much interresting. It's only good for devs who want to evaluate what is possible or not and maybe give Matroska or GStreamer some help.

[Neo Neko]

Originally posted by Zarxrax
So um... what exactly *IS* this, why do we need it, and how will it help matroska? From the faq on the Gstreamer site, it sounds like its something like a foundation to build things like media players on top of :confused:

Gstreamer is to directshow what Linux is to Windows. Better of course. :D Gstreamer will function much as directshow does. Only it will not actively block you from transcoding or repackaging formats as directshow does. If Gstreamer can parse or decode it you can do anything with it.

As to how it will help you or others. Well that is almost immesurable. Gstreamer will allow such things as VFR Matroska and MP4. Offering space savings over current technology. Software that uses it will not need the hacks that much of the software we currently use requires. Further it will all be cross platform. You can encode with it under Windows, Linux, Mac OS, BeOS, Syllable, SkyOS, QNX, BSD, ReactOS, Haiku, your Linksys router, some automotive computers, and even your toaster. Where as Directshow only lets you encode under Windows. Alot of the current Divx etc standalones are often Linux based. They then write their own custome decoding app that lacks ASP features and then sell it to you. With Gstreamer all they have to do is build an interface around it and they are off. You could technically then drop in any decoding modules for any format you wish on your settop! There are already Gstreamer based companies starting to crop up. How many directshow based ones are there? :D

[virus]

Originally posted by Neo Neko
Gstreamer will function much as directshow does. Only it will not actively block you from transcoding or repackaging formats as directshow does. If Gstreamer can parse or decode it you can do anything with it
Cool.
But what kind of support should we expect under Win32? As far as I understand, all the editing apps need to be rewritten on top of GStreamer... this may require years. And how many developers and/or companies are ready to move away from the M$ frameworks and throw away their working code?

Example: Avery Lee refused to add DShow support to VDub. What makes you think that he will accept to rewrite VDub to support GStreamer? I'm still very doubtful about GStreamer's ability to break trough and gain acceptance under Win. Look at the containers: MP4 is far superior, but people still use AVI. Almost nobody adds support for MP4 to their apps. And that's much simpler than supporting a completely different framework, I guess. So, what's the real usefulness of the whole GS port right now?

[Hiro2k]

Originally posted by virus
Example: Avery Lee refused to add DShow support to VDub. What makes you think that he will accept to rewrite VDub to support GStreamer? I'm still very doubtful about GStreamer's ability to break trough and gain acceptance under Win. Look at the containers: MP4 is far superior, but people still use AVI. Almost nobody adds support for MP4 to their apps. And that's much simpler than supporting a completely different framework, I guess. So, what's the real usefulness of the whole GS port right now?

To Test

[Neo Neko]

Originally posted by virus
Cool.
But what kind of support should we expect under Win32? As far as I understand, all the editing apps need to be rewritten on top of GStreamer...

Honestly that all depends. You will be able to interface with Gstreamer through any number of programming languages. Many of which are cross platform. Python, PERL, Java, Mono(or the lesser known copy cat .net :D ) to name just a few of the cross platform ones. The only large hurdle on any OS are the windowing toolkits and APIs. [Funny thing is that gstreamer programs don't require fancy GUIs. Thay could be all text based] But that is not much of a hurdle. Using cross platform languages you generally have uniform cross platorm libraries and APIs to do this with nowadays. And even with non-cross platform languages you still have such libraries and API. wxWidgets for example. There is plenty of POSIX software avalible on Windows GUI and CLI alike. Anyhow MS Windows not just Win32 is an official target platform so support for it should be quite good.

Originally posted by virus
this may require years. And how many developers and/or companies are ready to move away from the M$ frameworks and throw away their working code?

Who said anyone had to throw away code? If you can run MS Windows programs without MS Windows under Linux why not use Directshow filters in Gstreamer? It is gonna happen you know. That will mean that the code is not portable. But it allows them time to play and breathe as they port their code. In other words not the end of the world. ;) Linux has a history of programs doing that sort of thing. Ever seen Mplayer?

Originally posted by virus
Example: Avery Lee refused to add DShow support to VDub. What makes you think that he will accept to rewrite VDub to support GStreamer?

Well to address this we first need to remember why Avery refused to rewrite Virtualdub for Directshow. IIRC it was because Directshow was flaky and gave the application programmer little control in general over how the graph was constructed or what filters to use and their priority. Not to mention that it would mean that Virtualdub would actually be less portable. I can run Virtualdub pretty good under Linux ATM. Anyhow Gstreamer is actually setting out to be better in those areas than Directshow. And it WILL be fully cross platform to boot. So the question is not "if" Avery or someone else will either port it or re-write it for Gstreamer. But rather "when". And on that front I would say the answer is soon. As soon as Gstreamer hits 1.0 I suspect something will pop up rather quickly. Even if it is not from Avery.

Originally posted by virus
I'm still very doubtful about GStreamer's ability to break trough and gain acceptance under Win. Look at the containers: MP4 is far superior, but people still use AVI. Almost nobody adds support for MP4 to their apps.

That is a pattent misconception, a red herring, or a just plain apples to oranges comparison. AVI has alot more support simply because it has been around longer. And almost everybody is either adding or planning to add MP4 support to thier apps.

Originally posted by virus
And that's much simpler than supporting a completely different framework, I guess. So, what's the real usefulness of the whole GS port right now?

Actually it should be much harder to support a different format than a slightly different framework like Gstreamer. Gstreamer much like Directshow is a simple framework to provide a uniform interface to many different modules. The modules themselves is where all the complex stuff happens. Which is the whole reason for such a framework in the first place. Keep coders from re-inventing the wheel, and make it easy to use.

Microsoft will almost always have the upper hand because of their illegal monopoly and the way they use it to illegally leverage themselves into other markets and illegally destroy their competition. Thankfully that is just the sort of thing opensource and more specifically the GPL and similar licenses are made to combat.

[virus]

gotta love Neo Neko's "point-after-point" refutations :D

Originally posted by Neo Neko
If you can run MS Windows programs without MS Windows under Linux why not use Directshow filters in Gstreamer?

Well, but if you're gonna use your good old filters unchanged then where's the point in switching to GS? With a DS filter you still have all the weaknesses of DS, unless you change the filter interface to GS and add the new features that GS supports but DS not (or, at least, that's what I understand from your previous statement "GS will function much as DS does"... I don't really know the differences in detail ;)).
So I assume some work is needed. Opensource coders do it for free in their spare time... no one can force them to do that work. And no one can ask them to code everything in a few weeks/months ;)

So the question is not "if" Avery or someone else will either port it or re-write it for Gstreamer. But rather "when". And on that front I would say the answer is soon

VDub is more than a simple example, since VDub/VDubMod are very widely used. We can even push it a little and say "if VDub(Mod) doesn't support feature X, nobody will ever use it". This is off-topic, but I must admit I have no longer faith in VDub(Mod) as a program that drives the acceptance of future technologies... the development is too slow and concentrated on useless things like hardware acceleration for resizing... considering all the serious bugs in the 1.5.10 revision (which is 8 months old) which nobody cares to fix ("will be fixed in 1.6.0"... what if it's ready in 2006?) you can understand why I look forward to a new tool that replaces VDub(Mod) altogether.
Maybe written on top of GS, and possibly in C/C++ (you know, writing a performance-oriented app in Java is probably not that a good idea ;))

AVI has alot more support simply because it has been around longer. And almost everybody is either adding or planning to add MP4 support to thier apps.

I must have missed something here... MP4 is part of a standard which has been approved long time ago (years...). I don't see many integration of MP4 into the most used tools right now. I fear the same delay can happen for GS... and as you said M$ will probably push strongly against a new non-M$ framework, too. :rolleyes:

[robUx4]

Not to mention that many many devs are working on the Linux version of GStreamer and the plugins. Windows users can benefit of all this code for free. And the Linux guys will soon benefit from a wider user and developper audience with the Windows port. So everybody is happy (and working) !

GStreamer is now included GNOME, BTW. And I think it might be added to KDE too (don't quote me on that one). SO I guess that's the missing thing everybody was waiting for. And it's progressing quickly.

[RedDwarf69]

Stupid question: A plug-in will work in every system or there will be different plug-in's for windows and linux?

[robUx4]

Windows DLL and UNIX .so files are incompatible. You have to have a plugin for your platform. But most of the time plugins will be available on both platforms, as long as they are compilable.

BTW, windows will be officially supported by GStreamer by the 0.8.5 version. I'll make Release and Debug builds from that source.

[Mosu]

Originally posted by RedDwarf69
Stupid question: A plug-in will work in every system or there will be different plug-in's for windows and linux?

You cannot use a single _binary_ pluging on both systems of course. But unless the source code is platform dependant (e.g. a DirectX video output plugin) you can compile them on both platforms.

So basically the answer is 'yes, a plug-in will work on every system'.