Home > Archive > Compression > August 2005 > compressing compressed video
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
compressing compressed video
|
|
|
| Is it possible to noticeably compress already compressed video (DivX/MPEG)
even futher using a loseless compression program? Which programs offer the
highest compression radios in this case?
copx
| |
| Jim Leonard 2005-08-18, 5:55 pm |
| copx wrote:
> Is it possible to noticeably compress already compressed video (DivX/MPEG)
> even futher using a loseless compression program?
Yes, but not by much if at all. The most lossless compression I have
seen of an .AVI occured because the PCM audio was uncompressed. The
only .AVIs you'll see major compression occur is when there is so much
redundant information in a frame or series of frames that the AVI CODEC
output itself contains redundancies. For example, take a 20-second
stretch of pure black video, encode it to .AVI using any codec you
want, then compress further with ZIP or something. Most likely, it
will compress further.
> Which programs offer the
> highest compression radios in this case?
Depends on the source material. Try a few.
| |
| James Sungjin Kim 2005-08-20, 2:55 am |
| copx 쓴 글:
> Is it possible to noticeably compress already compressed video (DivX/MPEG)
> even futher using a loseless compression program?
The noticeble compression is not possible in that case, since the basic
principle of the loseless compression is the same as the lossy
compression. Remind that the principle of the lossless compression is to
allocate the less number of bits to the more common word until reaching
the entropy of information as closely as possible.
However, vice versa is possible in many cases since the way of the lossy
compression is to allocate more less bits to the comman words than that
by the lossless one, which leads the information rate to below of the
entopry rate until satisfying certain thresholds or conditions.
-James
| |
|
|
"James Sungjin Kim" <kimsj@mobile.snu.ac.kr> schrieb im Newsbeitrag
news:de6kqb$rai$1@news2.kornet.net...
> copx ? ?:
>
> The noticeble compression is not possible in that case
Yep, that's the result of my practical attempts too.
Using 7zip maximum compression (the most I'm willing to tolerate as far as
compression/decompression requirements are concerned) I didn't even manage
to reach 1% compression (on a DivX movie) :(
copx
| |
| Chris Johnson 2005-08-21, 9:55 pm |
| Thus one time, at band camp, James Sungjin Kim wrote:
> copx 쓴 글:
>
>
>
> The noticeble compression is not possible in that case,
True.
> since the basic
> principle of the loseless compression is the same as the lossy
> compression.
Not true.
The reason why DivX/XviD/MPEG/MP4, et al, (also JPEG) don't compress
further using a standard archival package is not due to the lossly
compression, but due to the final layer of lossless compression applied
to the lossy data stream. The results from the lossy stage are
typically quite compressible, so running something like LZH over the
output before it's turned into a file is built into the standards.
Trick is, this lossless compression has to be decoded in real time in
order for the video to play smoothly, so there's a practical limit as to
how compressed it can be. This decidedly average compression layer
effectively blocks further lossless compression.
Not wanting to sound too much like an ad for Stuffit, but the latest
version of the Stuffit archiver can roll back that final lossless
compression stage in JPEGs, then compress the original lossy stream much
more effectively. However, to view the JPEG you need to unpack it first
and recreate the original file.
This "recompression" technique should be able to be applied to all
manner of lossy compression formats, but it does add a costly (in time)
extra stage to both the creation of the file and any attempt to view it.
As such, it's really only useful if the viewing of a video can occur
well after transmission (not great for live stuff).
Unfortunately Allume, the company that produces Stuffit, hasn't been
able to release support for any new file formats since their JPEG
compression technique was released at the beginning of the year, about
six months ago. I fear also that they've patented the technique and may
be in a position to stop other programmers or companies from developing
a solution for popular video formats.
| |
| James Kim 2005-08-28, 6:55 pm |
| Chris Johnson wrote:
> Not true.
>
> The reason why DivX/XviD/MPEG/MP4, et al, (also JPEG) don't compress
> further using a standard archival package is not due to the lossly
> compression, but due to the final layer of lossless compression applied
> to the lossy data stream. The results from the lossy stage are
> typically quite compressible, so running something like LZH over the
> output before it's turned into a file is built into the standards.
Not true is not true:
Your talking is purly based on implementational points of view. However,
my previous explanation coresponds to theoretical principles. Regardless
of its actual implemenation method, the principle of lossy compression,
which has been illustrated in my previous thread, can not be changed.
-James (^o^)
| |
| beaker 2005-08-30, 6:55 pm |
| copx wrote:
> Is it possible to noticeably compress already compressed video (DivX/MPEG)
> even futher using a loseless compression program? Which programs offer the
> highest compression radios in this case?
>
> copx
>
>
Maybe.
I recall once some compressed video in an AVI format which seemed to
zip/gzip/etc a lot more than expected, but this was just due to
inexperience and bad packaging in the AVI format at the time (search for
'junk chunks').
| |
| Chris Johnson 2005-08-30, 9:55 pm |
| This one time, at band camp, James Kim wrote:
> Chris Johnson wrote:
>
>
> Not true is not true:
>
> Your talking is purly based on implementational points of view. However,
> my previous explanation coresponds to theoretical principles. Regardless
> of its actual implemenation method, the principle of lossy compression,
> which has been illustrated in my previous thread, can not be changed.
>
> -James (^o^)
Your "principle" of lossy compression compression is irrelevant. What's
more, you're talking about implementation as much as I am. No lossy
video compression system produces a perfectly compressed data stream in
one black-box maneuver. You're mixing up file formats with individual
processes. The initial lossy treatement of the video stream always
results in a data stream that benefits from lossless compression, but
has very little time to do it.
As such, a compression program that can roll back any lossless stages
and take as long as it needs to efficiently pack the lossy data is able
to compress an existing video file quite considerably, without any loss
in quality. The cost is that a time consuming process it required at
the other end while a valid video file is recreated before it can be
watched.
As such, if there was a video file format that didn't implement any
lossless compression after the lossy stage was completed, the playable
files would be larger than existing files, but they would compress into
(PAQ/RAR/7z) archives much smaller than anything typically being
distributed today.
If either a "recompresser" for video files, or a "lossy uncompressed"
video format is created, video files currently being distributed around
the 'Net could experience a significant reduction in size.
| |
|
| Your time consuming discussion is reasonable (as an answer to the
original question) while your indivisual process concept looks very
irrelevant.
Since video compression as one of lossy schemes is more sensetive to
the playing time, it is highly requried to implement as the
frame-by-frame structure. However, theoretically the same structure can
also be applied to lossless schemes. Moreover, actually it has been
more-or-less took account in lossless schemes but for different reasons
such as reducing the computational complexity. Refer again Huffman
coding and its implementation.
-James (^o^)
|
|
|
|
|