[gst-devel] Re: Helix Player virtual team meeting
christian at matroska.org
Sun Dec 14 01:49:12 CET 2003
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 at matroska.org> writes:
>>Realsplitter.ax : http://sf.net/projects/guliverkli
>>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 ....
matroska project admin
More information about the gstreamer-devel