Is there a way to re-encode an inefficiently encoded file without losing quality and reducing file size?
Let's say you have a video file encoded with high bitrate with the ultra-fast preset in H.264 because you couldn't afford CPU at that time. Now you have a huge file mostly because it was encoded quickly. You are now two days later with access to a good CPU and GPU. If you re-encode that file to save space then you are going to lose quality because even AV1 with a high bitrate is lossy (and you want to reduce that high bitrate) Otherwise, you can try transcoding using lossless compression but during my testing, this is making the file way bigger no matter what I tried. So basically, I can lose quality, or keep the big original file... Do you know a better way? Is there a way to re-encode that inefficiently encoded file without losing quality and reducing file size? Best regards Stéphane Archer
What about using a hash to check your existing against your possibly new / possibly matching file. If it's a match don't run ffmpeg on it. Assuming i'm understanding what you're trying to achieve, it would seem better practice not to touch the file with ffmpeg when you can avoid it.
On Sep 30, 2023, at 16:43, Stéphane Archer <archerstephane@gmail.com> wrote:
Let's say you have a video file encoded with high bitrate with the ultra-fast preset in H.264 because you couldn't afford CPU at that time. Now you have a huge file mostly because it was encoded quickly.
You are now two days later with access to a good CPU and GPU.
If you re-encode that file to save space then you are going to lose quality because even AV1 with a high bitrate is lossy (and you want to reduce that high bitrate)
Otherwise, you can try transcoding using lossless compression but during my testing, this is making the file way bigger no matter what I tried.
So basically, I can lose quality, or keep the big original file... Do you know a better way? Is there a way to re-encode that inefficiently encoded file without losing quality and reducing file size?
Best regards
Stéphane Archer _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
I'm not sure I understand what you mean, do you mean a hash like md5 and sha1? Could you please elaborate and simplify a bit? On Sat, Sep 30, 2023 at 7:51 PM MediaMouth <communque@gmail.com> wrote:
What about using a hash to check your existing against your possibly new / possibly matching file. If it's a match don't run ffmpeg on it. Assuming i'm understanding what you're trying to achieve, it would seem better practice not to touch the file with ffmpeg when you can avoid it.
On Sep 30, 2023, at 16:43, Stéphane Archer <archerstephane@gmail.com> wrote:
Let's say you have a video file encoded with high bitrate with the ultra-fast preset in H.264 because you couldn't afford CPU at that time. Now you have a huge file mostly because it was encoded quickly.
You are now two days later with access to a good CPU and GPU.
If you re-encode that file to save space then you are going to lose quality because even AV1 with a high bitrate is lossy (and you want to reduce that high bitrate)
Otherwise, you can try transcoding using lossless compression but during my testing, this is making the file way bigger no matter what I tried.
So basically, I can lose quality, or keep the big original file... Do you know a better way? Is there a way to re-encode that inefficiently encoded file without losing quality and reducing file size?
Best regards
Stéphane Archer _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
-- Best Regards, Stephane Archer
On Sep 30, 2023, at 17:47, Stéphane Archer <archerstephane@gmail.com> wrote:
I'm not sure I understand what you mean, do you mean a hash like md5 and sha1? Could you please elaborate and simplify a bit?
I checked-- I was referencing this from your OP
Is there any good reason why FFmpeg which sees that the video file input and output match every single characteristic doesn't copy the stream to avoid useless reencoding? Basically doing "-vcodec copy" automatically.
Based on that I was assuming you had existing files and arriving files new files that might or might not match your existing files (Your actual situation may be different. Might be helpful if you can provide more context about what you're trying to achieve.) But to answer your question re hash: yes an md5 or sha. I cobbled up a quick algorithm but instead of solving the problem it reveals a logic flaw Take the following ExistingFile = some file you might want to update NewFile = The file that might update it. ExistingFileHash = shasum -a 512 /path/to/ExistingFile NewFileHash = shasum -a 512 /path/to/NewFile if(NewFileHash <> ExistingFile){ delete ExistingFile (or archive it, depending on your workflow) ffmpeg -i ExistingFile -whateversettings NewFile **Here's the logic flaw** } else { Don't do anything to the ExistingFile } * An Existing File that was transcoded ffmpeg would never match hashes with a new file. or if it did match, it would seem there's no reason to transcode it. So it sounds like there's more to the story of what you're trying to achieve. Are you maybe instead trying to see if the metadata of a NewFile matches stored metadata of an Existing file, and if not, then do a transcode?
Every time you transcode, you lose more quality, same as making a VHS to VHS tape copy. If space is an issue, buy a Series 40 nVidia card that supports AV1 encoding. Transcode your blu-ray source directly to AV1 for the smallest file at the highest quality. True lossless file sizes are FAR larger than those found on a blu-ray, which are H264 encoded. On Saturday, September 30, 2023 at 04:51:30 PM PDT, MediaMouth <communque@gmail.com> wrote: What about using a hash to check your existing against your possibly new / possibly matching file. If it's a match don't run ffmpeg on it. Assuming i'm understanding what you're trying to achieve, it would seem better practice not to touch the file with ffmpeg when you can avoid it.
On Sep 30, 2023, at 16:43, Stéphane Archer <archerstephane@gmail.com> wrote:
Let's say you have a video file encoded with high bitrate with the ultra-fast preset in H.264 because you couldn't afford CPU at that time. Now you have a huge file mostly because it was encoded quickly.
You are now two days later with access to a good CPU and GPU.
If you re-encode that file to save space then you are going to lose quality because even AV1 with a high bitrate is lossy (and you want to reduce that high bitrate)
Otherwise, you can try transcoding using lossless compression but during my testing, this is making the file way bigger no matter what I tried.
So basically, I can lose quality, or keep the big original file... Do you know a better way? Is there a way to re-encode that inefficiently encoded file without losing quality and reducing file size?
Best regards
Stéphane Archer _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
вс, 1 окт. 2023 г., 02:43 Stéphane Archer <archerstephane@gmail.com>:
Let's say you have a video file encoded with high bitrate with the ultra-fast preset in H.264 because you couldn't afford CPU at that time. Now you have a huge file mostly because it was encoded quickly.
You are now two days later with access to a good CPU and GPU.
If you re-encode that file to save space then you are going to lose quality because even AV1 with a high bitrate is lossy (and you want to reduce that high bitrate)
Otherwise, you can try transcoding using lossless compression but during my testing, this is making the file way bigger no matter what I tried.
So basically, I can lose quality, or keep the big original file... Do you know a better way? Is there a way to re-encode that inefficiently encoded file without losing quality and reducing file size?
may be try two-pass encoding?
Best regards
Stéphane Archer _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
participants (5)
-
Andrew Randrianasulu -
Bruce Gavin -
Media Mouth -
MediaMouth
-
Stéphane Archer