Talk:Video compression

message: The page seems redundant with (and inferior to) the video codec page. Cat5nap 05:42, 7 Apr 2005 (UTC)
replies: text: Video compression can be seen as the process of encoding. Video codecs are the tools for the process. Shawnc 04:15, 10 October 2005 (UTC)

text: Video compression should have introductory material on methods of compression.  Video codec is a different but neighboring subject. If there is redundant material then perhaps someone should make the articles more distinct.  This video compression article can be improved with more visual queues as in diagrams that explains the compression process.  Daniel.Cardenas 23:58, 2 July 2006 (UTC)
thread_title: Is this page useful?

message: The article says that lossless video compression is not used. Why?
:Because lossless compression can't achieve nearly the compression ratio that lossy compression can, say 2:1 - 3:1 with lossless versus 100:1 - 200:1 with lossy. AlyM 23:57, 3 January 2005 (GMT)
: Any lossless compression system will sometimes result in a file (or portions of) that is as large and/or has the same data rate as the uncompressed original.  As a result, all hardware in a lossless system would have to be able to handle uncompressed video as well.  This kills off much of the benefit of compressing the data at all.  For example, digital videotape can't vary it's data rate easily so dealing with short bits of maximum-data-rate video would be more complicated then something that was fixed at that rate all the time. Algr 23:59, 10 March 2006 (UTC)
replies: text: AlyM's explanation is a lot clearer and more accurate, I think; I'll add it to the article.  Tempshill (talk) 06:07, 28 March 2008 (UTC)
thread_title: Lossless Video Compression

message: Anyone who is tech savvy already knows what video compression is, so this article should be written for a non-technical audience.  (Or at least keep the detailed stuff to the end.)  I've pulled a lot of buzzwords to reflect this, and replaced them with simple descriptions. Algr 08:47, 18 June 2006 (UTC)
thread_title:  Technical level 

message: "Without data compression, either the picture would look 30 times worse"
This sentence hardly fits any scientific criterion. Since there is no mathematical
critetrion of 'how good the picture looks like', it makes no sence to use the number 30 here.
:Retracting my previous comment as it was totally wrong, I missed the most recent item in the article history.  The above issue has now been addressed. AlyM 20:14, 18 August 2006 (UTC)
thread_title:  That's not scientific...  

message: There's a merge tag suggesting a merge with the B pictures article.  One page points the discussion of that merge suggestion here, while another directs the same discussion to take place on Talk:B pictures.  The actual discussion has been taking place there, not here.  Summarizing - Basically, no one (so far) is supporting the suggestion to merge the articles.   -Mulligatawny 20:52, 9 October 2006 (UTC)
thread_title:  Merge Discussion 

message: Aside from the players/codecs/filters, are there any means of generating a non-compressed file from a compressed one? (Similar to the decompression of ordinary archive files to get to the original documents inside.) -- Jokes Free4Me 10:31, 22 March 2007 (UTC)
thread_title:  Decompression? 

message: Is a lossless compression equal to raw video? It seems to me that "lossless" compression is a term that contradicts itself. My understanding is that any form of compression is throwing out information. Is raw video itself really raw?- or does it undergo some form of compression when brought into the computer (via firewire for example). Also I have a question about the new HD cameras that compress files into MPG format on a REV PRO discs or flash cards. When the files are "uncompressed" for editing how is the information "reconstructed"?
-Nick````  —Preceding unsigned comment added by 207.29.128.130 (talk) 15:21, 3 October 2007 (UTC)
thread_title:  Lossless vs Raw Video Files 

message: All mentioned compression techniques use frames, but there's also frameless compression: FrameFree--87.162.47.66 (talk) 17:39, 22 July 2008 (UTC)
thread_title:  Frameless compression? 

message: From Ten Steps to a Successful IP Surveillance Installation: Step 2 (section: Other considerations):
:Some courts believe that evidentiary video should be based on individual frames, not related to each other or manipulated. This would eliminate MPEG because of the way the information is processed.
Just thought it should be documented somewhere.  — Dispenser 23:31, 6 September 2008 (UTC)
replies: text: MPEG standards do not actually require inter-picture prediction to be used, and some uses of MPEG standards do not use such encoding techniques.  Whether that article should be considered a reliable source or not, and the exact circumstances of such a court decision may also be worth further discussion. I don't notice any specific court decisions cited in the article.  As one interesting case in particular, the pictures decoded using the H.264/MPEG-4 AVC standard have exactly-specified results with no decoder precision tolerance for implementation-specific approximations.  This may help provide some assurance that the decoded pictures are exactly what the encoder intended to be recorded (whether they use inter-picture prediction or not).  A nearby statement that you didn't quote from the article says "Proprietary compression also comes into consideration if the surveillance video will potentially be used in court. If so, using industry standard compression ensures that video evidence will be admissible."  Note that there is no formal industry standard specification for "Motion JPEG", and note also that there is no exact specification of the result that will be obtained by a JPEG decoder (since the standard allows for implementation-specific inverse-transform approximation errors). That is not to say that MPEG is great or that JPEG is not — just that the subject is not so clear cut. —Cat5nap (talk) 21:47, 7 September 2008 (UTC)
thread_title:  Court admissible codecs