commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject [codec] [convert] Re: StatefulDecoders
Date Wed, 24 Mar 2004 04:32:31 GMT
Alex Karasulu wrote:

>>-----Original Message-----
>>From: Brett Henderson [mailto:jakarta@bretth.com]
>>    
>>
>>You're right, encoders and decoders are special types of filters.  But why
>>create a distinction between the two when there is no reason to.  If
>>encoders require different methods to decoders then by all means create
>>separate interfaces, but they are doing the same thing (transforming data)
>>so surely we can use the same interfaces for both purposes.
>>    
>>
>
>What do others think about this?  It sounds sensible but I can't seem
>to shake the sense of comfort in making the distinction between the two.
>For the stateless operation there we may not have symmetry between the
>decode and encode halves.
>  
>

To my mind encoding and decoding are not distinct operations: they both 
simply transform information from one format to another.  It seems "in 
the eye of the beholder" which format is "encoded" and which is 
"decoded".  On the other hand, the case of lossy transformations may 
lend some weight to naming the format that contains less/degraded 
information the "encoded" format.

Off the top of my head, I could imagine two video streaming applications 
that broadcast media in different formats.  I imagine that each 
application will allow many formats for source media and "encode" to 
each chosen streaming format.  If application A streams divx and 
application B streams ogg theora, the applications would disagree on 
which format to label "encoded".

I'm leaning towards a single set of interfaces for data transformation.  
I am also beginning to suspect that codec and convert may be 
converging.  Poking around the sandbox, I think compress might want to 
be assimilated as well.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message