This code generates an H.264 file (-c libx264 switch).
It doesn't work. I've tried -i A Christmas Carol (1999) 4K Upscale AI.mkv -preset slower -c:v libx264 -crf 17 -c:a aac -b:a 192k A Christmas Carol (1999) 4K Upscale AI.mp4Originally Posted by rgr
AND
ffmpeg -i A Christmas Carol (1999) 4K Upscale AI.mkv -preset slower -c:v libx264 -crf 17 -c:a aac -b:a 192k A Christmas Carol (1999) 4K Upscale AI.mp4
neither works. They say no such file or directory. Am I putting the command in wrong ?
Think about this. Once bread becomes toast, you can't make it back into bread.
Use quotation marks in names as I wrote earlier.
ffmpeg -i "A Christmas Carol (1999) 4K Upscale AI.mkv" -preset slower -c:v libx264 -crf 17 -c:a aac -b:a 192k "A Christmas Carol (1999) 4K Upscale AI.mp4"
Good lord, I'm dense...
Think about this. Once bread becomes toast, you can't make it back into bread.
How long does this take ? It looks like the speed is .05x. If the file is 3.97gb, won't it take forever ? It's been a couple hours so far. I can't check the progress as the cmd doesn't say anything about the time it'll take and the resulting file doesn't have a size to it yet.
Think about this. Once bread becomes toast, you can't make it back into bread.
It depends on the speed of your computer. The size of the resulting file can be estimated based on the bitrate, but why?
It uses -preset slower, depending on your cpu it may take a while.
4k video, even slower.
You could change it to -preset medium, should be much faster
with the trade-off of a bit larger final file (medium preset is the default if it's not specified
at all)
Could have set this up in HB or Vidcoder in about 5 minutes
Some people like to learn the command line but not everyone
Last edited by davexnet; 23rd Oct 2024 at 12:50.
Yes, because he placed emphasis on quality, and slower offers higher quality.
A slower preset does not mean a smaller file. Quite the opposite - the file is usually larger.with the trade-off of a bit larger final file (medium preset is the default if it's not specified
at all)
Interesting, I see in H.264 the slow preset often produces a smaller file than medium - slower behaves differently?Yes, because he placed emphasis on quality, and slower offers higher quality.
A slower preset does not mean a smaller file. Quite the opposite - the file is usually larger.with the trade-off of a bit larger final file (medium preset is the default if it's not specified
at all)
In HEVC, I've noticed they get bigger as they get slower
Here's a short test I did this morning with a 720p, 20 minutes short clip encoded to H.264
The only thing changed in the encode was the choice of preset
Last edited by davexnet; 23rd Oct 2024 at 16:29.
What does the time part of it mean ? It looks like 00:00:00.0 Right now it's 00:10:42.17
Also, it is at 911105 kib. what's kib ? What is the file size going to end up being ?
Think about this. Once bread becomes toast, you can't make it back into bread.
time is estimated time, bitrate-kbits is the average bitrate.
You can also look at speed and fps to infer the amount time it will take
I understood the kbits part. I was wondering about the Kib part. From what I could find, it's some weird way of measuring the size of the file.
About the estimated time thing....is that estimated until the file is finished encoding ? Because the number keeps going up.
bitrate is about 11000 and the fps is 1.6.....not sure what that means.
Think about this. Once bread becomes toast, you can't make it back into bread.
speed= and fps= are directly related. (It's just math)I understood the kbits part. I was wondering about the Kib part. From what I could find, it's some weird way of measuring the size of the file.
About the estimated time thing....is that estimated until the file is finished encoding ? Because the number keeps going up.
bitrate is about 11000 and the fps is 1.6.....not sure what that means.
if the original play back rate of your file is 24 fps (typical movie)
and speed =2x, fps should be 48 fps.
It means the encode time will be half that of the original movie playback time
Put up a screenshot of this window see we can see what you're referring to
EDIT fix erroneous info - "time" is the progress counter, the location in the file currently processing
Last edited by davexnet; 25th Oct 2024 at 11:24.
here's the screenshot...speed= and fps= are directly related. (It's just math)I understood the kbits part. I was wondering about the Kib part. From what I could find, it's some weird way of measuring the size of the file.
About the estimated time thing....is that estimated until the file is finished encoding ? Because the number keeps going up.
bitrate is about 11000 and the fps is 1.6.....not sure what that means.
if the original play back rate of your file is 24 fps (typical movie)
and speed =2x, fps should be 48 fps.
It means the encode time will be half that of the original movie playback time
time= is not accurate, ignore it.
any other questions put up a screenshot of this window see we can see what you're referring to
Think about this. Once bread becomes toast, you can't make it back into bread.
What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
Last edited by davexnet; 23rd Oct 2024 at 18:24.
are kibibytes the same as kilobytes ? Any idea as to how big the final file is going to be ? The source file is about 3.97 gb. It's been encoding for about 6 or 7 hours now...What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
Think about this. Once bread becomes toast, you can't make it back into bread.
The size of the source is irrelevant. In any operation like this, the file is internally uncompressed before being encoded and recompressed.are kibibytes the same as kilobytes ? Any idea as to how big the final file is going to be ? The source file is about 3.97 gb. It's been encoding for about 6 or 7 hours now...What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
You can infer the final size and get a ball park figure.
Using the frame= in the display, the actual frame count of the source and the current size you can
do a rough calculation for final size. (I'lll leave the math to you)
Don't leave the math to me. Do you know how long it's been since I've done any math ? 1998 was the last time I did any math. If I tried, it wouldn't end well....The size of the source is irrelevant. In any operation like this, the file is internally uncompressed before being encoded and recompressed.are kibibytes the same as kilobytes ? Any idea as to how big the final file is going to be ? The source file is about 3.97 gb. It's been encoding for about 6 or 7 hours now...What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
You can infer the final size and get a ball park figure.
Using the frame= in the display, the actual frame count of the source and the current size you can
do a rough calculation for final size. (I'lll leave the math to you)
Also, I don't know the frame count of the source....
Last edited by Spottedfeather; 23rd Oct 2024 at 20:03.
Think about this. Once bread becomes toast, you can't make it back into bread.
To get the frame count from the source open it in vdub2 and you'll see it at the bottom right on the timelineDon't leave the math to me. Do you know how long it's been since I've done any math ? 1998 was the last time I did any math. If I tried, it wouldn't end well....The size of the source is irrelevant. In any operation like this, the file is internally uncompressed before being encoded and recompressed.are kibibytes the same as kilobytes ? Any idea as to how big the final file is going to be ? The source file is about 3.97 gb. It's been encoding for about 6 or 7 hours now...What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
You can infer the final size and get a ball park figure.
Using the frame= in the display, the actual frame count of the source and the current size you can
do a rough calculation for final size. (I'lll leave the math to you)
Also, I don't know the frame count of the source....
For an approximation:
a - total frame count from the source
b - frame= from the ffmpeg window
c - size= from the window
d - final size
d=(a/b) * c (divide this result by 1024 to get the size in MB's)
I just checked and it was at 61000 frames or so. I did what you suggested and checked the frame number of the original file...which was something like 168000.To get the frame count from the source open it in vdub2 and you'll see it at the bottom right on the timelineDon't leave the math to me. Do you know how long it's been since I've done any math ? 1998 was the last time I did any math. If I tried, it wouldn't end well....The size of the source is irrelevant. In any operation like this, the file is internally uncompressed before being encoded and recompressed.are kibibytes the same as kilobytes ? Any idea as to how big the final file is going to be ? The source file is about 3.97 gb. It's been encoding for about 6 or 7 hours now...What is your question?
If you're talking about size=,
it is the current size of the output in K bytes (you'll see it increases as the encode progresses)
You can infer the final size and get a ball park figure.
Using the frame= in the display, the actual frame count of the source and the current size you can
do a rough calculation for final size. (I'lll leave the math to you)
Also, I don't know the frame count of the source....
For an approximation:
a - total frame count from the source
b - frame= from the ffmpeg window
c - size= from the window
d - final size
d=(a/b) * c (divide this result by 1024 to get the size in MB's)
I'm sorry, but the file was encoding for at least 9 hours and it only got to 61000 frames. That is NOT happening. There is no way that I'm going to be doing this for 3 days.
Guess I'm just out of luck in getting an mp4 that will play on my PS4.
I don't know why people use mkv. My computer can't play them and my playstation can't play them, either.
Think about this. Once bread becomes toast, you can't make it back into bread.
it took 9 hours to get 61000 frames on the slower setting. the source file is 168000 frames. Would changing the speed to encode faster lower the quality ? I'm confused. If I were to change the speed in that setting, what would I put exactly ?
Think about this. Once bread becomes toast, you can't make it back into bread.
Why don't you scale it to 1080p and use a faster preset?
Try Handbrake. If you need some help setting it up, provide a short clip from your source file.
On my PC, with its old AMD FX CPU and 8GB of DDR3, I get about 15 fps encoding 4k scaled down to 1080p using the "faster" preset
See if this file plays OK on your device
Last edited by davexnet; 23rd Oct 2024 at 22:14.
Use clever FFmpeg-GUI.
Start it an follow the instructions.
Then load your carol.mkv and follow the steps shown below.
[Attachment 83067 - Click to enlarge]
The file you posted plays fine. Won't I lose quality if I have it at 1080 instead of 4K ? The movie is a 4K upscale from the, I presume, 480p dvd.
If I were to use a faster preset, how would I go about that ?
Think about this. Once bread becomes toast, you can't make it back into bread.
Look in the command line rgr gave you
Change -preset slower to -preset medium
It is clearly written that it converts the 24th minute of the film. And you probably know how long the film is.
I actually tried fast and it got about 5 times faster than slow. So only about 8 or 9 hours to encode...which failed badly. I can watch the mp4 on my computer, which is good since my computer doesn't play mkv....but it doesn't work on my PS4. The file will show up on the PS4. I can click it, and get the standard Playstation symbols spinning around as it loads. After a few seconds, I can hear the intro music start....then it says it can't play the file.
Honestly, I have no idea what to do at this point. I first converted the mkv to an mp4 because that's what playstation can use. It wouldn't play because it was H.265, which playstation DOESN'T play. I then converted it to mp4 but one that was H.264, which playstation DOES play....and it still doesn't work.
Think about this. Once bread becomes toast, you can't make it back into bread.
Read post #53
Use Avidemux to create a few minutes clip from your source, use the clip in your conversion tests.
Have you ever successfully played a 4k file on your ps4?
Does this demo play?
Resize to 1920x1080:I actually tried fast and it got about 5 times faster than slow. So only about 8 or 9 hours to encode...which failed badly. I can watch the mp4 on my computer, which is good since my computer doesn't play mkv....but it doesn't work on my PS4. The file will show up on the PS4. I can click it, and get the standard Playstation symbols spinning around as it loads. After a few seconds, I can hear the intro music start....then it says it can't play the file.
Honestly, I have no idea what to do at this point. I first converted the mkv to an mp4 because that's what playstation can use. It wouldn't play because it was H.265, which playstation DOESN'T play. I then converted it to mp4 but one that was H.264, which playstation DOES play....and it still doesn't work.
ffmpeg -i "A Christmas Carol (1999) 4K Upscale AI.mkv" -preset slower -vf "scale=-1:1080" -c:v libx264 -crf 17 -c:a aac -b:a 192k "A Christmas Carol (1999) 4K Upscale AI.mp4"
Create first test file (super fast):
ffmpeg -i "A Christmas Carol (1999) 4K Upscale AI.mkv" -preset slower -vf "scale=-1:1080" -t 10 -c:v libx264 -crf 17 -c:a aac -b:a 192k "A Christmas Carol (1999) 4K Upscale AI-TEST.mp4"
View Profile
View Forum Posts
Private Message
Quote
