This was one of the reasons I started freaking out at the file size.
Even jpeg'd Chapter Three alone is currently sat at 800mb. (So 1.7gb in totes for all three) Which with another seven chapters to go is unsustainable regardless.
One thing you might consider is increasing the compression somewhat on your JPEG's. If you're using the JPEG's that come directly out of Daz Studio, they're rendered at a very low compression level. (Deliberate, to keep quality up.) But small decreases in JPEG quality can have very significant effects on file size, while making relatively little difference in visual quality.
You can't do this directly with Daz Studio (AFAIK) but you can with other tools. A command line tool that you can script to do things in batch is
You must be registered to see the links
. To just drop the quality level on a JPEG, it's as simple as
Code:
magick input.jpg -quality 85% output.jpg
You can play with the percentages, of course - I've found 85% works well for me, and it reduces the JPEG size by about 4:1 or 5:1.
But all this stuff is useful. I just need to decide which way to jump. Currently it's looking as though I'm going to have to suck it down and just re render with a smaller number of frames
It's always better to have the choice, and to don't have works to do, so:
[whatever.bat]
Code:
@ECHO OFF
DEL magick.lst
FOR %%f IN ( *.jpg ) DO ECHO %%f >> magick.lst
FOR /F "tokens=1,2 delims=." %%f IN ( magick.lst ) DO (
FOR /L %%c IN (94,-1,75) DO magick "%%f.%%g" -quality %%c%% "%%f-%%c.%%g"
)
For each file with the .jpg extension, it will create a copy with a factor of compression going from 94 to 75. Each new file being named like the original but with the compression factor added to the name.
So, for a file named "my image.jpg", you'll have new files named "my image-94.jpg", "my image-93.jpg", and so on.
Then use an image browser like ACDSee, XNview or whatever you prefer, and choose the image with the lower compression factor that still have the better quality to your eyes.
Well your answer wasnt better lol.
Anyway, you guys are talking about h264 and h265 which are CODECS! and then go on and talk about webm which is NOT A CODEC!
You are not even comparing apples with oranges, but apples with orange seeds.
Go back and read the discussion, it was always about the container webm vs mp4. You confused the codec and container, implying that the container didn't even matter.
There is no hardware to unzip, unrar, or unwebm files. Opening a webm requires CPU. The webm = frozen fish, analogy vs mp4 canned tuna. Practically every device out there has a hardware can opener that opens and processes mp4, and h.264.
webm has to be defrosted in the microwave (CPU) before it can be consumed. Look at the history of mpeg hardware, we can expect that it will take time for webm hardware to be developed.
One thing you might consider is increasing the compression somewhat on your JPEG's. If you're using the JPEG's that come directly out of Daz Studio, they're rendered at a very low compression level. (Deliberate, to keep quality up.) But small decreases in JPEG quality can have very significant effects on file size, while making relatively little difference in visual quality.
You can't do this directly with Daz Studio (AFAIK) but you can with other tools. A command line tool that you can script to do things in batch is
You must be registered to see the links
. To just drop the quality level on a JPEG, it's as simple as
Code:
magick input.jpg -quality 85% output.jpg
You can play with the percentages, of course - I've found 85% works well for me, and it reduces the JPEG size by about 4:1 or 5:1.
Again, play with the bitrate you use on the video - you may find that you can reduce the size of the video by accepting some higher compression.
It's always better to have the choice, and to don't have works to do, so:
[whatever.bat]
Code:
@ECHO OFF
DEL magick.lst
FOR %%f IN ( *.jpg ) DO ECHO %%f >> magick.lst
FOR /F "tokens=1,2 delims=." %%f IN ( magick.lst ) DO (
FOR /L %%c IN (94,-1,75) DO magick "%%f.%%g" -quality %%c%% "%%f-%%c.%%g"
)
For each file with the .jpg extension, it will create a copy with a factor of compression going from 94 to 75. Each new file being named like the original but with the compression factor added to the name.
So, for a file named "my image.jpg", you'll have new files named "my image-94.jpg", "my image-93.jpg", and so on.
Then use an image browser like ACDSee, XNview or whatever you prefer, and choose the image with the lower compression factor that still have the better quality to your eyes.
Why so complicated? IrfanView has a built in batch converter with lots of options^^
@polywog Your last posts here where all about h.264 vs webm and not mp4 vs webm, also your comparisons have zero reason to the matter and some of your "technical explanations" are simply wrong. You ignore obvious technical facts even with given prove and source in this thread...
I'm usually not like this, but you seem to be set in your way, so I don't see the point of any further discussion on the matter.
Why so complicated? IrfanView has a built in batch converter with lots of options^^
@polywog Your last posts here where all about h.264 vs webm and not mp4 vs webm, also your comparisons have zero reason to the matter and some of your "technical explanations" are simply wrong. You ignore obvious technical facts even with given prove and source in this thread...
I'm usually not like this, but you seem to be set in your way, so I don't see the point of any further discussion on the matter.
In a couple years, devices will support webm (maybe not apple) but other relevant hardware. When that happens, all will be happy... thanks to Mozilla, and Goggle for bringing us webm. In the meantime, while we wait for hardware manufacturers to develop webm hardware... using webm severely limits the number of people that can play the game.
Did you ever burn a DVD video in the 90s? It took hours to encode mpeg using cpu only. After a few years hardware was made to support on the fly mpg encoding. The same will happen for webm. Stop being an impatient millennial.
If you want to use webms in your game, go for it. A modder will make an unofficial version to support other users if there is a demand for it.
Why ? Because it's the opposite of complicated. I mean, you put the script I gave in a batch file, let's say "jpgCompare.bat" that you save somewhere you'll be sure to remember. Then, starting this moment, the only thing you have to do is to copy the "jpgCompare.bat" file in the directory where are your images and double click on it. 30 seconds after this, you'll have the 20 variations of your 50 images.
Are your really sure that you'll need less than 30 seconds and a two steps process, to do the same with IrfanView ?
Why ? Because it's the opposite of complicated. I mean, you put the script I gave in a batch file, let's say "jpgCompare.bat" that you save somewhere you'll be sure to remember. Then, starting this moment, the only thing you have to do is to copy the "jpgCompare.bat" file in the directory where are your images and double click on it. 30 seconds after this, you'll have the 20 variations of your 50 images.
Are your really sure that you'll need less than 30 seconds and a two steps process, to do the same with IrfanView ?
What you do with irfan is almost the same. Install it, change the settings to you liking and once this is done you only need to open one image in the folder where your images are with irfan and start the batch process. Okay, you have to press "B" on the keyboard to start the batch process, but in return you don't need to copy any script into the folder
If you want to change the options you can do that in the program and don't need to change a script file which is complicated for some people.
I have done some batch "magic" myself in the past, so I'd say that the time cost is the same, but especially for people with lesser knowledge and people who need to change things often, irfan is the easier and faster option.
Er... they do exactly the same thing.
At first I wanted to do everything in this loop, but my DOS scripting being rusty, I can't remember how to split the name with this configuration. And as expected, too focused on the loop, I didn't thought that I could have replaced it.
One option you may not have thought of would be combining your animation and RenPy's ATL (
You must be registered to see the links
) to get your end result. I'm thinking of something like a static camera animation, then use ATL to do your pan operation.
I personally have been using ATL without actually realizing it for a while already (all those image statements where you link half a dozen images together and set them in a loop... is ATL). But now I'm starting to use parts I hadn't realized were possible before. In my case... panning around an image.
So imagine you're developing a 1080p game. Your standard image size would be 1920x1080. But you could create an image that was 1920x2160. Effectively double height. ATL would allow you to show that image starting at the bottom and pan all the way to the top (either smoothly {linear} or using a speed up/slow down {easein/easeout} movement).
Okay. That's a very simple example. But if you can pan around an image, and that image was say... a movie file... You could conceivably have a simple looking 20 frame looping animation/movie... and save the majority of those 300 "panning" frames by having ATL do it for you.
I'm not suggesting it would be a good idea to combine the two... I'm just offering alternatives.
I'm guessing this is where your real solution lies.
I've never used ffmpeg - but the idea of using it to combine a whole mass of consecutive still images together to create a movie file feels like what you were wanting in your original message.
Not least because of the image compression/optimization done by video encoding will massively reduce your overall animation filesize.
Imagine you have a 300 frame video, with a cuckoo clock in the corner that never moves... the wall around it and the clock would only need to be stored once... and the video encode/decode will ensure that part of the image appears on all 300 frames because it's always the same. Of course, it's mathematically way more complex than that... and it's actually doing it on a pixel level, rather than things a human can recognize... but I think it gets the point across why the filesize would be smaller.
Personally, I would use h.264 codec within an MP4 container. But only because I regularly recode 2160p VR video from h.265 to be h.264 using
You must be registered to see the links
... Mainly because the computer I use my oculus rift on isn't powerful enough to show 90FPS video using the h.265 codec without stuttering. (h.264 is older and ends up being bigger file sizes... but it has significantly lower computing power requirements). As long as I set Handbrake's options to switch on stuff like "web optimized", "fast decode" and use the "encoder preset: Slow" (To spend more time encoding the video, for a smaller overall filesizes)... I'm generally happy with the filesize compared with h.265, as a compromise.
I've no doubt that things like VP9 and WEBM are better than h.264 and MP4 in a lot of ways. I just favor "keep it simple" and "if you use the ancient tech... it'll run on practically everything", rather the favoring the cutting edge stuff.
Of course, you could also achieve that animation by creating the animation timeline within Daz and just have Daz save it as a movie rather than a series of images. Then use something like Handbrake to recode it into the codec/file format of your choice. I know it's possible... but like so much of this reply... my knowledge is purely theoretical.
One option you may not have thought of would be combining your animation and RenPy's ATL (
You must be registered to see the links
) to get your end result. I'm thinking of something like a static camera animation, then use ATL to do your pan operation.
I personally have been using ATL without actually realizing it for a while already (all those image statements where you link half a dozen images together and set them in a loop... is ATL). But now I'm starting to use parts I hadn't realized were possible before. In my case... panning around an image.
So imagine you're developing a 1080p game. Your standard image size would be 1920x1080. But you could create an image that was 1920x2160. Effectively double height. ATL would allow you to show that image starting at the bottom and pan all the way to the top (either smoothly {linear} or using a speed up/slow down {easein/easeout} movement).
Okay. That's a very simple example. But if you can pan around an image, and that image was say... a movie file... You could conceivably have a simple looking 20 frame looping animation/movie... and save the majority of those 300 "panning" frames by having ATL do it for you.
One thing you might consider is increasing the compression somewhat on your JPEG's. If you're using the JPEG's that come directly out of Daz Studio, they're rendered at a very low compression level. (Deliberate, to keep quality up.) But small decreases in JPEG quality can have very significant effects on file size, while making relatively little difference in visual quality.
You can't do this directly with Daz Studio (AFAIK) but you can with other tools. A command line tool that you can script to do things in batch is
You must be registered to see the links
. To just drop the quality level on a JPEG, it's as simple as
Code:
magick input.jpg -quality 85% output.jpg
You can play with the percentages, of course - I've found 85% works well for me, and it reduces the JPEG size by about 4:1 or 5:1.
Again, play with the bitrate you use on the video - you may find that you can reduce the size of the video by accepting some higher compression.
Er... they do exactly the same thing.
At first I wanted to do everything in this loop, but my DOS scripting being rusty, I can't remember how to split the name with this configuration. And as expected, too focused on the loop, I didn't thought that I could have replaced it.
What you do with irfan is almost the same. Install it, change the settings to you liking and once this is done you only need to open one image in the folder where your images are with irfan and start the batch process. Okay, you have to press "B" on the keyboard to start the batch process, but in return you don't need to copy any script into the folder
If you want to change the options you can do that in the program and don't need to change a script file which is complicated for some people.
I have done some batch "magic" myself in the past, so I'd say that the time cost is the same, but especially for people with lesser knowledge and people who need to change things often, irfan is the easier and faster option.
Guys, thank you all so much. I've learned tons from you all - not least that I should ask this stuff a bloody sight earlier
You've all been terribly kind in sparing your time educating an idiot and it's much appreciated. Truly.
I don't know how much I'll be able to apply to my current chapter as the clock is ticking on delivery but you've all guaranteed that my future work will be all so much better.
Ok, I have to correct you here.
You write a wonderful story, you make amazing rendering, and sometime you struggle with some specific part of the code or the "building". Personally, for my own project, I wrote not so bad code, I know more or less how I'll build everything I'll need, perhaps that I'll be able to render some not too bad looking CGs one day, and the story will be what it will be.
So, if there's an idiot here, it's more surely me than you. It's not something that can be judged according to only one criteria, else we are all idiots unless this criteria is our strong point. And your game prove by itself that you are far to be an idiot, and have way more strong points than me.
One option you may not have thought of would be combining your animation and RenPy's ATL (
You must be registered to see the links
) to get your end result. I'm thinking of something like a static camera animation, then use ATL to do your pan operation.
I personally have been using ATL without actually realizing it for a while already (all those image statements where you link half a dozen images together and set them in a loop... is ATL). But now I'm starting to use parts I hadn't realized were possible before. In my case... panning around an image.
So imagine you're developing a 1080p game. Your standard image size would be 1920x1080. But you could create an image that was 1920x2160. Effectively double height. ATL would allow you to show that image starting at the bottom and pan all the way to the top (either smoothly {linear} or using a speed up/slow down {easein/easeout} movement).
Okay. That's a very simple example. But if you can pan around an image, and that image was say... a movie file... You could conceivably have a simple looking 20 frame looping animation/movie... and save the majority of those 300 "panning" frames by having ATL do it for you.
I'm not suggesting it would be a good idea to combine the two... I'm just offering alternatives.
I'm guessing this is where your real solution lies.
I've never used ffmpeg - but the idea of using it to combine a whole mass of consecutive still images together to create a movie file feels like what you were wanting in your original message.
Not least because of the image compression/optimization done by video encoding will massively reduce your overall animation filesize.
Imagine you have a 300 frame video, with a cuckoo clock in the corner that never moves... the wall around it and the clock would only need to be stored once... and the video encode/decode will ensure that part of the image appears on all 300 frames because it's always the same. Of course, it's mathematically way more complex than that... and it's actually doing it on a pixel level, rather than things a human can recognize... but I think it gets the point across why the filesize would be smaller.
Personally, I would use h.264 codec within an MP4 container. But only because I regularly recode 2160p VR video from h.265 to be h.264 using
You must be registered to see the links
... Mainly because the computer I use my oculus rift on isn't powerful enough to show 90FPS video using the h.265 codec without stuttering. (h.264 is older and ends up being bigger file sizes... but it has significantly lower computing power requirements). As long as I set Handbrake's options to switch on stuff like "web optimized", "fast decode" and use the "encoder preset: Slow" (To spend more time encoding the video, for a smaller overall filesizes)... I'm generally happy with the filesize compared with h.265, as a compromise.
I've no doubt that things like VP9 and WEBM are better than h.264 and MP4 in a lot of ways. I just favor "keep it simple" and "if you use the ancient tech... it'll run on practically everything", rather the favoring the cutting edge stuff.
Of course, you could also achieve that animation by creating the animation timeline within Daz and just have Daz save it as a movie rather than a series of images. Then use something like Handbrake to recode it into the codec/file format of your choice. I know it's possible... but like so much of this reply... my knowledge is purely theoretical.
Hmm I'm making it this way more than one year. And because I must render all 200 frames for animation not depent if anything changin in background or not. So this way is for me still the best and 10 seconds 1600*900 in nice quality takes about 20MB of size.
Ok, I have to correct you here.
You write a wonderful story, you make amazing rendering, and sometime you struggle with some specific part of the code or the "building". Personally, for my own project, I wrote not so bad code, I know more or less how I'll build everything I'll need, perhaps that I'll be able to render some not too bad looking CGs one day, and the story will be what it will be.
So, if there's an idiot here, it's more surely me than you. It's not something that can be judged according to only one criteria, else we are all idiots unless this criteria is our strong point. And your game prove by itself that you are far to be an idiot, and have way more strong points than me.
You're welcome... well, as long as you stop saying that you are an idiot.
I know this is an old thread but I have been searching around and you seem very knowledgeable about this matter so I wanted to ask you.
The problem is, I've been having some of my android users complain about choppy video animations. I am using WebM VP9 for the videos. I checked my game on my Oneplus 7 pro and all the animations seem to play smoothly except for a couple, the ones that have big camera movements, like full-body scans or panning(it's only a tiny stutter for me, not that noticeable). But I am afraid that users with older devices may have it a lot worse. Should I reduce the fps maybe? The videos are currently 60 fps.
Do you have any tips?
Choppy/stuttering video is purely a matter of too much data not being delivered quickly enough to the screen.
The only real solution is to reduce the overall data rate and/or CPU requirements.
You might want to consider using H.264 (x264) for video and AAC for audio within a MP4 container.
Yes, the file will be bigger - but it's a much older standard and as such, it's CPU requirement for decoding the video is lower.
That said, Android is kinda optimized for VP8/VP9... so maybe it's not the boost I hope it would be.
It's an AVN video, not a first person shooter. 30FPS will be fine. A lot of AVN animations can be as low as 5 or 6 FPS.
30FPS will half your data rate. So maybe that will be enough.
Personally, I would recode your video a couple of times at 30/24/16 and see what level you are willing to live with. Obviously the lower the FPS, the more hardware it will run smoothly on.
The only other setting I can think that might matter would be whether the video is encoded with CBR (constant bit rate) or VBR (variable bit rate). You want VBR (sometimes called Constant Quality in some software). CBR uses the same data rate all the time, whether it needs it or not. VBR lets the data rate drop down when that's okay and go high when needed - as long as the average over time is below your hardware needs, things will be fine.
Choppy/stuttering video is purely a matter of too much data not being delivered quickly enough to the screen.
The only real solution is to reduce the overall data rate and/or CPU requirements.
You might want to consider using H.264 (x264) for video and AAC for audio within a MP4 container.
Yes, the file will be bigger - but it's a much older standard and as such, it's CPU requirement for decoding the video is lower.
That said, Android is kinda optimized for VP8/VP9... so maybe it's not the boost I hope it would be.
It's an AVN video, not a first person shooter. 30FPS will be fine. A lot of AVN animations can be as low as 5 or 6 FPS.
30FPS will half your data rate. So maybe that will be enough.
Personally, I would recode your video a couple of times at 30/24/16 and see what level you are willing to live with. Obviously the lower the FPS, the more hardware it will run smoothly on.
The only other setting I can think that might matter would be whether the video is encoded with CBR (constant bit rate) or VBR (variable bit rate). You want VBR (sometimes called Constant Quality in some software). CBR uses the same data rate all the time, whether it needs it or not. VBR lets the data rate drop down when that's okay and go high when needed - as long as the average over time is below your hardware needs, things will be fine.
Thanks for the information. I hate to bring the fps down, but I may have to. I tried MP4 and seems to be the same as webm.
It was already at VBR, I know not to use constant bit rate. I will try to experiment around a little bit and see what I can come up with. I really appreciate the reply.
