#417 Full Compression with Convert To FPS - Problem

[Anonymous]

A. Encode with full compression using x264 codec with Convert to FPS to half the original FPS. The encoded video output is is half the size with new FPS. This is how all Virtualdub builds work and every other editor encoder works.

B. When use the Remove Frames Filter to remove all duplicate frames. For when every other frame is a duplicate of the proceeding frame.

Then encode at the same video bitrate as original video. x264 Full Encode and with Convert to FPS set to half of the original FPS. Why then is the encoded output video always same size as the original. I think this is the bug.

It is as if the frames with using the Remove Frames filter somehow are not been removed from the video when it is encoded. That they are been hidden and are still in and part of the video. what use is this.

Can Remove Frames Filter be fixed so it can do what it says it can do that is Actually Remove Video Frames Permanently. So they are left in the encoded output video. Only need to Remove Frames to reduce file size while keeping the same bitrate as the video source.

[Anton Shekhovtsov]

Are you sure there is no mistake in the test? Can you for example encode A and B with lossless intermediate codec, then compare both results parameters and frame by frame? It is not possible to remove frames and leave them at the same time, they would be visible in the output.

[isidroco]

If you have a 30fps video h264 compressed and you reencode it erasing all even frames, you'll end up having final size reduced by 10% at most. Size would decrease to half if video was UNCOMPRESSED. H264 (and others) works reducing size by encoding only whats changed from previous (and future) frames. So on slow motion, any almost identical frame (as in 30fps) doesn't take any space at all. So if your point is to reduce video final size, discarding every other frame won't work as you expected. You may try using h265, and use more agressive compression (diminishing quality).

[Anonymous]

isidroco I have read you answer to this question above a few times over. The previous and future frames that could have such impact effect to leave frames when they will be always removed using the remove frames filter.

So if use frame serve from avisynth script where frames already have been removed there is no way for Virtualdub to know previous and future frames.

If not an avisynth script in VD2 I still don't see how with remove frames previous or future frames could be an issue. Or even equate into the compression when VD2 remove frames would have already removed them.

Lets say for example a video 10000 frames at 50fps progressive all other frames are duplicate frames. Remove frames filter finds all and so after setting 25fps in Frames setting also so remove frames filter works correctly. So end up with 5000 frames progressive 25fps. Where does previous or future frames figure in this equation.

Please explain further in an easy way so we can learn what your explaining here. Maybe we are missing something.

[isidroco]

Hi, I think your intention is to reduce video size by eliminating every other frame. There's a filter collection for VDub by JPSDR https://github.com/jpsdr/Filtres_JPSDR/releases/tag/20210430 it's RemoveFrames allows to eliminate n frames in a given m period. But that would reduce size as you expect only on a compressor with all keyframes (as MJPEG) . Advanced compressors (as H265, etc) picks up from frame server a whole chunk of frames (let's say 250) and THEN compressed them all together, only first KEY frames are independant, all the rest are derived from each other. So in a static scene, only first frame would occupy space, all the 249 remaing frames don't take any space at all. In a high motion scene you can save some space, but even there by the way the whole group is compressed your final compressed video would probably occupy 80% of the original.
The real reason you would like to reduce frames is to view video on a slow device which would not be able to keep up on lets say 60fps. Or to restore original 24fps of a movie.
H264 lets you choose the quality / size, that's what you can use to reduce size (and quality).

[Anonymous]

I do not use H265 as a codec it also has very few players support. Those players that now do support H265 playback have limitations in place OS and platform.

H264 wins easily because it placed no limitations and so reason H264 is used everywhere and H265 isn't or will be. A lemming likes to fly but only ever manages to die and so seems does H265.

There will someday there will be another codec that will take the H264 crown, another codec that is without limitations also. But it won't be H265 with all its imposing limitations, that makes it unappealing and unusable. Gives no trust to users who also could be future targeted limitations..

[isidroco]

My answer stands for all compressors which uses previous and optionally future frames as a base to achieve high compression as XVID, DIVX, H264. H265 was an example, H264 works exactly the same way. H265 doesn´t have limitations, players and devices have. New codecs won´t be able to improve a lot. Eventually new hardware will be able to encode decode faster, but size improvements will be marginal. h265 have same quality at a smaller size, at the prize of high cpu use. But maybe a 30% size saving is not practical if you can´ t directly use it in your devices. You always loose quality when transcoding. So if you already have h264 material it´s better to keep it as it is.

[Anonymous]

New codecs won't be able to improve, I would say that just yet computers ever evolving. Just need someone with different ideas to move compression into another direction. That said as you say its about hardware as always was to decode the frames fast enough. Encoders already use CPU or today GFX. There was a great con GFX devices of long ago with AGP when they touted capabilities such as a zillion of GFlops and a whole lot more besides more but didn't do encoding why was that I sometimes wonder!. I mean their GFX processing power, far outreached any computer of the day even, so they claimed.

Was it VLC that mainly compromised all others or was it H265 themselves that said VLC maybe H265 for all I know. Happy with H264 and yes will stay with it.

Keep H264 I couldn't agree but if the file size is doubled for duplicate frames there is no reason for that or reason to keep such large video. Yes we can decimate could be used to reduce the file size by half. But needed are the correct frames to be removed so enter Remove Frames.

Remove Frames is a decimate process it can remove all the real correct duplicate frames. It would better placed in Frame Rate Options as a Decimate process then also allowing it to be used with Direct Copy.

Then also it needs be able to allow us to batch job it so we can add as many videos as needed. Then be able to run batch and have Remove Frames process to find all duplicate frames in all videos. Babysitting anything with computers is unheard of today and should not be needed to be done. Even if batch just to do Remove Frames process itself for a batch of many videos would a great start using VD2 batch manager.

Also Remove Frames for Virtualdub no hardship there I guess for that to happen why keep it contained to one software, let it out to run free let it make something of it self. It wants to be happy and have a future also I'm sure.

[isidroco]

You still don't get it. Duplicate frames don't take any space at all on H264. You won't reduce file size by decimating. As I tried to explain before. A whole bunch of frames are compressed taking in account very little is changed from one frame to another. You can erase 4 every 5 frames on all video, and final h264 size would still be 99% of the original h264 you tried to reduce. Please stop insisting on this.