«

Denkedran Joe a écrit :
> So my idea was to put the question to all of you what to do in case of
> uncompressibility? Any ideas?

Hi,

Generally, a compression algorithm may be optimized for a type of data, or for a
"packet" of data (ie with dynamic table building huffman compression, with
different algorithms for video, sound or exe files, etc).

If you can find two (or more) complementary algorithms (or sets of fixed
parameters for a single algo) that covers the whole flows, you can dynamically
switch between them, without transmitting the parameters.

The known of the data flow may help you. Ie, if you may have to transmit an
already compressed packet, your problem may have not any solution.

Hans-Peter Diettrich wrote:
> cms wrote:
>
>> It isin't right to applicate lossless algorithms to
>> fixed-bandwidth systems.
>
> Depends on the algorithm. E.g. RLE will never cause an increase in
> size, what's sufficient even for use with fixed-bandwidth channels.

Nit. Depends on the data. You have to have something to separate
a repetition count from a new value, which implies a lost char (or
more) somewhere. However, any such expansion can be expected to be
small.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

CBFalconer <> writes:
> Hans-Peter Diettrich wrote:
> > cms wrote:
> >
> >> It isin't right to applicate lossless algorithms to
> >> fixed-bandwidth systems.
> >
> > Depends on the algorithm. E.g. RLE will never cause an increase in
> > size, what's sufficient even for use with fixed-bandwidth channels.
>
> Nit. Depends on the data. You have to have something to separate
> a repetition count from a new value, which implies a lost char (or
> more) somewhere. However, any such expansion can be expected to be
> small.

Most RLEs can be caused to explode horribly, simply by
peppering the file with the value used as the escape code(s).
Packbits solves this problem, and it will never expand
more than a small fraction, as it escapes both blocks
of literals and runs.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

>> So my idea was to put the question to all of you what to do in case of
>> uncompressibility? Any ideas?

How about sending the excess data by post?

What makes this an electronics problem anyway?

<> wrote:
>
> How about sending the excess data by post?

Joker!

> What makes this an electronics problem anyway?

The hardware implementation on an FPGA plattform makes it an electronics
problem. So, think again! Next time you better come up with a more
sophisticated answer...

>> How about sending the excess data by post?
>Joker!

>> What makes this an electronics problem anyway?
>The hardware implementation on an FPGA plattform makes it an electronics
>problem. So, think again! Next time you better come up with a more
>sophisticated answer...

Let me put it more clearly. You fail to distinguish the separate
problems of algorithm and implementation. There is nothing
specifically electronic about this problem, so it doesn't concern
FPGAs in general nor VHDL in particular.

If you don't like what's on TV, does that make it an electronic
problem?