VideoHelp Forum
+ Reply to Thread
Page 3 of 3
FirstFirst 1 2 3
Results 61 to 69 of 69
Thread
  1. Member
    Join Date
    Sep 2016
    Location
    United States
    Search PM
    Raymond here, I'm not sure why there's so much anger / conflict at play, but I do apologize for any misunderstandings or misstatements. A quick background: My company, Future Ware, was incorporated in the early eighties, and then reincorporated as ZPEG about 3 years ago. My work with video started in 1982 working in a joint effort among IBM, Microsoft and Intel, resulting the the development of the Indeo codec. I also assisted in a technical capacity to the original MPEG group, which met at the time there in Princeton.
    In 1996 (only 20 years ago!) I was struck by the inspiration for ZPEG compression, which ideas has been recently adapted into a video pre-processor that is particularly applicable to any motion estimation compressor engine. That is the idea I have shared on this forum.
    I also would like to thank all involved in the discussion for helping improve the idea. We have changed the way we quantize low-level values and have fixed a rounding problem in calculating color quantization as a direct result of your input. I have learned (I guess I should have known) that the technique does not work well with variable frame rate compression. I have also increased the size of files one may submit to the ZPEG demo page to 4GB, to make the demonstration far more usable. I am currently working on adding user control knobs for temporal and color space quantizer adjustments.
    OK, as to the "challenge"! I will look at this video, but with the caveat that the technique does not work well with synthesized material (unsurprisingly, I would suggest). I am today adding to the FAQ section of the site a detailed example of how to visually evaluate the compression advantage which is tuned to we who wish our eyesight was better (I speak only of myself!).
    Thank you all once again for your interest and participation.
    Quote Quote  
  2. ^^^You just have to "love" this guy!

    It took you 20 years, during which time you have a Doctorate in Digital Compression, to realize that it doesn't work with VFR and that there was a rounding error in calculating color quantization, an error that you blamed on ffmpeg when it was first brought to your attention.

    You also say that your "technique" doesn't work with "synthesized material", if you mean computer generated graphics, ToS is live action footage mixed with special effects and it's never before been compressed. One would think that this would be a perfect show case for your "technique" but more importantly why would "synthesized material" not work well with your "technique", I would think material like a cartoon or Big Buck Bunny would be full of redundancies for your software to exploit.

    I think the answer is obvious, your theories are those of a mad man, the implementation is that of a chimp, and your explanation is that of a charlatan.

    Here's my prediction, even if we gave you another 20 years you still wouldn't be able to provide a binary that did what you claim.
    Quote Quote  
  3. It doesn't work well with computer generated material because that material usually lacks grain/noise. Regardless of how he gets there, the end result of his processing is mostly noise reduction. If there's no noise the material won't benefit.
    Quote Quote  
  4. Member
    Join Date
    Sep 2016
    Location
    United States
    Search PM
    Here are the results for the a segment of the test sequence "tears". I broke the y4m file into 3 GB bite-sized pieces which I can then process using my demo site. I chose a segment at random, number 8, and processed it. The results came back as 22% file size reduction when compressed to 12 Mbs (which I figured was pretty close to an average QP of 18. Its actual average QP was 22.81, so a little low on the bandwidth). Additional segments are available to test at an address like:
    https://zpeg-videos.s3.amazonaws.com/tears/tearsofsteel-4k.008.y4m
    The segment numbers range from 000 to 058

    The results are as follows:

    Job is complete
    Full Rate: 12,000,000
    Optimized Rate: 9,339,179
    Savings: 22.17%
    Unprocessed @ 12,000,000
    Pre-Processed @ 9,339,179
    Informational Renderings:
    Pre-Processed @ 12,000,000
    Unprocessed @ 9,339,179
    Sample playback commands:
    cvlc -width 4096 -height 1714 -R --no-video-title-show --no-autoscale 81.proc.optimized.mp4
    ffplay -x 4096 -y 1714 -i 81.proc.optimized.mp4
    Input Parameters
    Your email =
    Your file = tearsofsteel-4k.008.y4m
    Your job number: 81
    Width = 4096
    Height = 1714
    Frame Rate = 24.000
    Color Format =4:2:0
    Scan Type =Progressive
    Bitrate In =2,021,916,672
    File Characteristics
    UHD Resolution
    Low frame rate
    Target Bit Rate for your content is: 12,000,000
    Compression Parameters
    Pre-Process to quality -18vB
    Compress using x264 to file format mp4
    Compress speed: medium
    Compress to Estimated Target Bit Rate Quality: 12,000,000
    Compress to Estimated Target Bit Rate Quality: 12,000,000
    Visually Equivalent Bandwidth after Preprocessing: 9,339,179

    jagabo is correct to point out that synthesized material is lacking in the fine detail or noise that pre-processing benefits by removing. The point of ZPEG pre-processing technology (which is closer to two years old, being a recent developmental idea) is that it does the mathematically ideal job of removing all imperceptible artifacts, as it applies a human visual model to the decorrelated transform domain. You can't please all the people all the time, but I am hoping to develop an approach that saves bandwidth while being imperceptible to the average viewer.

    The "binary" is available for all comers to use - on the demo site!
    Last edited by raymondwestwater; 23rd Nov 2016 at 19:52.
    Quote Quote  
  5. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Stop calling it that. You are NOT providing a binary (for download), you are providing an online processing service. Currently it is free, because you are using would-be customers as beta testers. But free for how long?

    One problem with your offer is that it is based on presenting only tailored results - tailored by a blackbox service with parameters that are hidden, so there is no way to objectively test with a proper, agreed range of material.
    True open scientific discourse (paraphrasing some of the intent of your OP) allows for sharing of source data: source code, raw data, hypotheses/assumptions, etc.

    You probably would still have takers if you just truthfully stated the premise of your temporary beta-tested offering: HVS-modeled data reduction pre-processing as a paid-for, proprietary service. But you would surely instill more respect for your forthrightness.

    Scott
    Last edited by Cornucopia; 23rd Nov 2016 at 22:10.
    Quote Quote  
  6. I recommend people just use the hardware based encoders (Intel Quick Sync, Nvidia NVEnc, etc.) if they want to remove noise/grain and small, low contrast detail. The results will be similar and you'll save a lot of time.
    Quote Quote  
  7. Originally Posted by raymondwestwater View Post
    Here are the results for the a segment of the test sequence "tears". I broke the y4m file into 3 GB bite-sized pieces which I can then process using my demo site. I chose a segment at random, number 8, and processed it. The results came back as 22% file size reduction when compressed to 12 Mbs (which I figured was pretty close to an average QP of 18. Its actual average QP was 22.81, so a little low on the bandwidth). Additional segments are available to test at an address like:
    https://zpeg-videos.s3.amazonaws.com/tears/tearsofsteel-4k.008.y4m
    The segment numbers range from 000 to 058

    The results are as follows:

    Job is complete
    Full Rate: 12,000,000
    Optimized Rate: 9,339,179
    Savings: 22.17%
    Unprocessed @ 12,000,000
    Pre-Processed @ 9,339,179
    Informational Renderings:
    Pre-Processed @ 12,000,000
    Unprocessed @ 9,339,179
    Sample playback commands:
    cvlc -width 4096 -height 1714 -R --no-video-title-show --no-autoscale 81.proc.optimized.mp4
    ffplay -x 4096 -y 1714 -i 81.proc.optimized.mp4
    Input Parameters
    Your email =
    Your file = tearsofsteel-4k.008.y4m
    Your job number: 81
    Width = 4096
    Height = 1714
    Frame Rate = 24.000
    Color Format =4:2:0
    Scan Type =Progressive
    Bitrate In =2,021,916,672
    File Characteristics
    UHD Resolution
    Low frame rate
    Target Bit Rate for your content is: 12,000,000
    Compression Parameters
    Pre-Process to quality -18vB
    Compress using x264 to file format mp4
    Compress speed: medium
    Compress to Estimated Target Bit Rate Quality: 12,000,000
    Compress to Estimated Target Bit Rate Quality: 12,000,000
    Visually Equivalent Bandwidth after Preprocessing: 9,339,179

    jagabo is correct to point out that synthesized material is lacking in the fine detail or noise that pre-processing benefits by removing. The point of ZPEG pre-processing technology (which is closer to two years old, being a recent developmental idea) is that it does the mathematically ideal job of removing all imperceptible artifacts, as it applies a human visual model to the decorrelated transform domain. You can't please all the people all the time, but I am hoping to develop an approach that saves bandwidth while being imperceptible to the average viewer.

    The "binary" is available for all comers to use - on the demo site!
    You know, I try and be nice to you but you are just hell bent on forcing me to mock you, and I resent you for that, I really do, considering tomorrow is Thanksgiving and all, but in the spirit of giving and since you seem to want it so bad, I will be nice enough to accommodate your desire for ridicule.

    The results came back as 22% file size reduction when compressed to 12 Mbs

    This is a nonsensical claim, it makes no sense in the context of the test sample I provided. Here is the Media Info output for the test sample I provided:

    Format : YUV
    Duration : 12 min 14 s
    Bit rate : 2 022 Mb/s
    Width : 4096 pixels
    Height : 1714 pixels
    Display aspect ratio : 2.40:1
    Frame rate : 24.000 FPS
    Color space : YUV
    Chroma subsampling : 4:2:0
    Scan type : Progressive
    Compression mode : Lossless
    Bits/(Pixel*Frame) : 12.000
    Stream size : 173 GiB (100%)

    You were supposed to take the original, process it with your software, then encode both the original and the processed version with x264 crf 18 and compare the two, if the processed version was 30% smaller (meaning it had used 30% less bit rate) then you would have proven that your software functioned as you claimed. Instead you cheat by encoding to a target bit rate that by your own admission you arrived at by estimating what crf 18 would use (what you based this estimate on is anyone's guess) and you messed the test up by breaking the test file into 8 smaller segments, these are the shenanigans of charlatan; if you give someone a chance to prove his claims by offering a simple test and he takes that test and twists it around so that it no longer resembles the test that person is a con artist. It's like when a person is being interviewed and he is asked a question that he doesn't want to answer he "pivots" and answers something else.

    It's called a scam, pure and simple.

    The "binary" is available for all comers to use - on the demo site!

    As has been pointed out, NO IT IS NOT! What you offer is the equivalent of someone going to a car dealership and being offered a test drive but when it comes time for the test drive you are not allowed to drive the car, only the salesman drives the car and then only for 2 blocks around the dealership.

    The point of ZPEG pre-processing technology (which is closer to two years old, being a recent developmental idea)

    Your Linkedin profile makes the claim that you have been working on this for 30 years by stating that you have worked for ZPEG.com since 1986.

    I'm curious Raymond, what exactly is the end game here? What is it you're hoping to accomplish? Is this thread like a dry run, a dress rehearsal for when you try to sell this service, to see what kind of objections you may get?

    It seems to me if your algorithm actually worked as you claimed a much better approach would be to either approach existing encoder developer's like the x265 people or the x264 people and offer them your algorithm or alternatively fork the project(s) and create a variant that incorporates your code into the encoder.

    You must realize that even if your software did what you claim, a free standing filter that requires massive raw source files and outputs massive raw files has a very limited market appeal.

    Maybe someone else can explain it to me, but doesn't it seem to everyone else that if this thing actually worked as Raymond claims that it would be much more useful as a patch for x264 or x265 than the way he's trying to promote it now?
    Quote Quote  
  8. Member
    Join Date
    Sep 2016
    Location
    United States
    Search PM
    Perhaps you are confusing QP with CRF? Constant rate factor (CRF) processing attempts to develop a stream at the rate that in some sense is "equivalent quality", as calculated by bandwidth estimation based on QP and an undocumented application of the compressor-specific human visual model. In other words, the results are difficult to predict, as they are not reproducible across compressors or video content. So what we did in our original experiments was to compress each stream multiple times, once at each of many different quantization parameters (QP). This truly compares apples to apples, as it injects the exact same amount of error into each quantization. And our results under this compression are quite good! If you'd like me to pre-process a yuv clip or two and post for consumption by your encoder, I can do that.
    The clients that we work with have all objected to QP or CRF analysis on the grounds that real-world applications are CBR (constant bit rate). So we developed a test methodology that compresses streams to the same bit rate, then calculates the advantage produced by the pre-processing.
    Which. I might add, greatly exceeds that of the most expensive compressors, particularly Har***ic and Ar**s, with which we have tested extensively.
    I do not plan to release this project open source at this time, although I have published the details of the algorithm. And we are speaking with x265 and other open source communities to figure out a way we can help one another. But it seems more likely I could afford to put this into the public domain after I manage to obtain some sort of sponsorship...
    Virtually every transcoder must decompress and re-compress its streamed content. Often by conversion in SDI, which makes it particularly easy to include this module in-line with a commercial transcoding workflow. Even more so for a file encoding workflow.
    Last edited by raymondwestwater; 23rd Nov 2016 at 22:06.
    Quote Quote  
  9. Member
    Join Date
    Sep 2016
    Location
    United States
    Search PM
    If I may speak to my "end game", it is to gain clarity through dialog with video experts. And while I disagree with argument by polemic and invective in principal, I do admire a good turn of phrase, such as:
    "your theories are those of a mad man, the implementation is that of a chimp, and your explanation is that of a charlatan"

    Scott, there is no financial gain to be reaped from a pay-per-process service, the savings are incremental and make sense only in the context of a Google or a Netflix. The only market I can see worth mining is sale to the majors. If all goes well, it is my hope the technology can be supported as an open-source project as part of a deal of this type. There is certainly room in my world view for cutting a special deal of some kind with early adopters...
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!