Sep 3, 2010
Managed Commons including WebM subproject is at Github
Sorry, forgot to update here that the Managed Commons project now resides at Github: http://github.com/monoman/Managed-Commons
It includes the WebM subproject, that will allow reading/writing WebM files/streams generally and decode/play such streams in Moonlight.
Little time to work on it, so the progress is very slow, but if you want to contribute, please do: Fork it at Github and send those fantastic Pull Requests.
Also please post issues there to help guide/prioritize development, I'm trying to first be able to read the Matroska files, them I'll start the decoder and pump some video data, and last plug it into Moonlight. Writing streams/files has low priority at this point, unless someone really want to develop a video producing app, or a slideshow-to-video converter and want to contribute code and testing to that end.
It includes the WebM subproject, that will allow reading/writing WebM files/streams generally and decode/play such streams in Moonlight.
Little time to work on it, so the progress is very slow, but if you want to contribute, please do: Fork it at Github and send those fantastic Pull Requests.
Also please post issues there to help guide/prioritize development, I'm trying to first be able to read the Matroska files, them I'll start the decoder and pump some video data, and last plug it into Moonlight. Writing streams/files has low priority at this point, unless someone really want to develop a video producing app, or a slideshow-to-video converter and want to contribute code and testing to that end.
May 24, 2010
Trying to Bring WebM Support into Moonlight
First step: porting Matroska's JEBML (a Java parser for EBML) to C#. EBML is the "binary xml" format that is the basis for the Matroska (thus WebM) container.
I tried to convert libebml2 (written in C) to C#, but it is too "unobjectifiable" and so I searched a bit more for some easier path. Didn't look at some of the C++ parsers available, but JEBML although looking a bit abandoned of late seems to model the main concepts and surely is a good starting point. JEBML is LGPL-licensed which should not compromise the whole effort.
Going with renaming .java files to .cs, and doing wholesale Find&Replace, but have to stop now, while it doesn't even compile yet. Tomorrow I hope to fix it into a somewhat compilable state, and then, I'll need to move to .NET system classes, and use generics to slim down the whole thing.
The sources so far were uploaded into my Managed.Commons group, later I'll decide if add a project on Google Code, or GitHub.
http://groups.google.com/group/managedcommons/web/Managed.Ebml.rar
I tried to convert libebml2 (written in C) to C#, but it is too "unobjectifiable" and so I searched a bit more for some easier path. Didn't look at some of the C++ parsers available, but JEBML although looking a bit abandoned of late seems to model the main concepts and surely is a good starting point. JEBML is LGPL-licensed which should not compromise the whole effort.
Going with renaming .java files to .cs, and doing wholesale Find&Replace, but have to stop now, while it doesn't even compile yet. Tomorrow I hope to fix it into a somewhat compilable state, and then, I'll need to move to .NET system classes, and use generics to slim down the whole thing.
The sources so far were uploaded into my Managed.Commons group, later I'll decide if add a project on Google Code, or GitHub.
http://groups.google.com/group/managedcommons/web/Managed.Ebml.rar
May 4, 2010
Experimenting with Twitter's Blackbird Pie, retwitting Sergio's opposition to mandatory registration to have access to Internet here in Brazil, as says a proposed set of laws:
Sou contra o cadastro obrigatório para acessar a Internet no Brasil. E você? #marcocivil
samadeu
Apr 12, 2010
Some comments on new iPhone OS 4 TOS
Well, for starters, I'm one of the very pissed MonoTouch developers, that hated all the news (mostly speculative) on the restrictions Apple is possibly bringing to iPhone development.
I'm not sure that MonoTouch will be effectively prohibited as a development platform for iPhone/iPad, but the signs are very indicative of that.
Following the discussions on blogs (and comments) and Twitter, I'm impressed by how many people is on the same boat as me, and how heated is the criticism on Apple's move.
It is contrasting to see Miguel's or Unity's calmness, so far.
Anyway this post is about one item most discussions seem to neglect or are plainly wrong about:
I'm not sure that MonoTouch will be effectively prohibited as a development platform for iPhone/iPad, but the signs are very indicative of that.
Following the discussions on blogs (and comments) and Twitter, I'm impressed by how many people is on the same boat as me, and how heated is the criticism on Apple's move.
It is contrasting to see Miguel's or Unity's calmness, so far.
Anyway this post is about one item most discussions seem to neglect or are plainly wrong about:
- Some arque that Apple can't simply prohibit some very successful apps from being further developed/distributed under the new agreement, because that would cost them money to reimburse customers that have bought those apps. That is partially false: the agreement I've been obliged to sign indeed says that Apple can, at any time, yank my app from the Apple Store and much worse they can uninstall it from all the iPhones/iPads out there which have it installed, and that any costs advent from angry customers are on my back. So they may lose on future sales if the app was very successfull, but leave all the other costs of their one-sided decision to the developers, so it is kind of an easier decision for them to make, at least in the USA.
Mar 4, 2010
My little library Mono.GetOptions is being abandoned by Mono
The biggest lump of code I've contributed to Mono, the Mono.GetOptions library is now being erased from the project.
It wasn't perfect and it's successor Mono.Options is a very capable replacement even if it doesn't do all the tricks Mono.GetOptions did in its prime.
Mono.Options is friendly to C# 3.0 features like lambdas, which allows writing code as terse as Mono.GetOptions allowed without using reflection and being a somewhat large dependency, the two main gripes Miguel had with my little library.
The last of Miguel gripes was about versioning (keeping more than one version in the fold) as some of the needed fixes and planned evolutions for Mono.GetOptions would mean breaking changes, which are better handled by consumers of the library by having distinct major versions with its separate APIs and attached series of minor releases.
That gets even more complex as you consider that Mono.GetOptions evolution also was tied to Mono releases.
If memory doesn't fail me, it was Mono.GetOptions and also other libraries imported into the project like SharpZipLib (which is still a problem as Mono is carrying two versions of it, and in this general cleanup process it is going over now we are trying to get rid of at least one of them), that prompted Miguel to change policy and ask for most non core libraries to be developed and released independently from Mono, even if developed by Mono hackers or used in some Mono utility. Better a package dependency (a soft one if possible) than the maintenance burden of embedded libraries.
Well let me quit reminiscing. Farewell my kid...
But if you are a loyal user of Mono.GetOptions what should you do?
You can:
It wasn't perfect and it's successor Mono.Options is a very capable replacement even if it doesn't do all the tricks Mono.GetOptions did in its prime.
Mono.Options is friendly to C# 3.0 features like lambdas, which allows writing code as terse as Mono.GetOptions allowed without using reflection and being a somewhat large dependency, the two main gripes Miguel had with my little library.
The last of Miguel gripes was about versioning (keeping more than one version in the fold) as some of the needed fixes and planned evolutions for Mono.GetOptions would mean breaking changes, which are better handled by consumers of the library by having distinct major versions with its separate APIs and attached series of minor releases.
That gets even more complex as you consider that Mono.GetOptions evolution also was tied to Mono releases.
If memory doesn't fail me, it was Mono.GetOptions and also other libraries imported into the project like SharpZipLib (which is still a problem as Mono is carrying two versions of it, and in this general cleanup process it is going over now we are trying to get rid of at least one of them), that prompted Miguel to change policy and ask for most non core libraries to be developed and released independently from Mono, even if developed by Mono hackers or used in some Mono utility. Better a package dependency (a soft one if possible) than the maintenance burden of embedded libraries.
Well let me quit reminiscing. Farewell my kid...
But if you are a loyal user of Mono.GetOptions what should you do?
You can:
- Migrate to Mono.Options (or even use it's code directly as Miguel advocated some time ago because it is a lot slimmer than my library).
- You can keep a copy of a Mono.GetOptions binary around to distribute with your solution (not an option for open source projects that would like to be accepted into Debian/Ubuntu).
- Tell me you would like to see Commons.GetOptions, my own fork of it, get on the air and fly high. Version 1.0 of it has just the namespace change in it, so your migration effort would be minimal. See the Managed Commons group for more information.
Subscribe to:
Posts (Atom)