[gst-devel] Re: Helix Player virtual team meeting

[ChristianHJW]

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 :

http://samples.matroska.org/matrix/ .

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

Christian
matroska project admin
http://www.matroska.org