Re: Helix Player virtual team meeting

Danilo Segan wrote:

Please note that I consider any discussion on these issues here Gnome
related -- if they're not, this should be moved to some other list.

I simply pressed the 'reply all' button, i didnt start copying several lists on this topic ;-) .... feel free to delete my email for any lists you dont think it is appropriate to.

ChristianHJW <christian matroska org> writes: :

The filter will link to the Real DLLs once Realplayer ( or
alternatives' ;) ) are installed.

This fails miserably if you're not using Intel x86 architecture. And
the last time I heard, Gnome was not Intel x86-centric (it would be
even wrong to call it "Intel-centric", since Intel makes ARM and
Itanium processors which share little with x86 -- ok, Itanium does
support executing x86 code, but nevertheless).
I dont like this solution either, thats why i was recommending to Real Networks to change at least the license for the decoders and parsers. It doesnt hurt them at all, as the format is reverse engineered anyhow, so it makes only sense to offer the official decoder libraries to OSS developers, so that frustration with incompatibilities is avoided. A normal user, when trying to play a Real Media file on his *nix box, wont know that the format was reverse engineered. So if playback fails he will believe real Networks is the one to blame, releasing crappy libs ;) ....

I have a 700 MB encoding of Titanic ... Try doing this with any
other codec around ;) .

Depends on what quality you get. I can imagine a lossy codec (that's
probably the kind that you've used) that will make even smaller
output. Let me describe very simple algorithm.
- set "count" to zero
- for every input byte, increase "count" by 1
- output "count"
This is a lossy compression algorithm which indeed saves some of the
original data properties (i.e. a number of bytes), yet, the quality
of video you might get with it is VERY bad, even though anything can
be "lossy-compressed" to few bytes with this "algorithm". ;)
So, your point here seems moot, since subjective feel of quality
degradation is more than important that simple "compression" ratio
(700MB/Titanic :). Cheers,Danilo "Getting my point across" Segan
Danilo, i am doing video compression since several years now, and i am also project admin of a multimedia related project. If you try to encode this movie, which has a very low compressability also ( especially the iceber scenes at the end ), with ANY MPEG4 based code, and this is the Director's cut with 4 hrs and with almost DVD resolution, you will get nothing but a blocky mess.

Dont misunderstand me, i am not in bed with Real Networks at all ( in fact, we had a fair bit of discussion in the past, because their license also forbids to put RV9 into any other container format, but fortunately none of our tool developers ever had to sign the license agreement to get hold of a working Real demuxer lib ;-) ), but to leave out proper support for RV9 on GNOME would be plain wrong IMHO. In the bitrat range of 100 - 1000 kbps this codec will simply give unrivalled results. If you want to get an impression of the difference, load these samples here : .

You will find 2 matroska sample files of very challenging material ( Matrix RL Trailer ), one encoded with very latest XviD ( 1.0 beta 2 ) about one week ago, and the other with RV9 about 2 months ago, both without prefiltering ! To play them on Linux you currently need mplayer ( compiled with libmatroska/libebml ) with the Real DLLs included, as there is no RV9 Gstreamer plugin so far ( this will hopefully change ). The XviD file should play fine on Gstreamer HEAD, thanks to BBB's matroska plugin. Both samples have 11 text subtitle tracks ( SRT, unicode ) in many different languages and 1 HE-AAC ( SBR AAC ) audio stream, dont know if this works on mplayer or gstreamer already.

Real N should really consider to make the parser and decoder libraries available as L-GPL, or maybe another special license limited to non-commercial use only, it would simply help the wide spread use of their format IMHO. QPL comes to mind, as i think i heard its compatible with L-GPL ( not sure ), but forbids forks as well as unauthorized commercial use in closed source programs. For Gstreamer, that way simply the RV9 gst-plugin could be licensed as QPL as well i guess, the license pro's to clarify please .....

Just my 2 cents ....

Best regards

matroska project admin

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]