Dizty dev seeks animation assist...

[recreation]

You must be registered to see the links

 

[polywog]

webm is just a container format. It has little to do with whether the video can be hardware accelerated or not - that depends on the codec that you use to encode the video stream itself.

The two most common codecs used with the webm container are VP8 and VP9.

You must be registered to see the links

You must be registered to see the links

Essentially, there are hardware implementations of both, both in the desktop and mobile environment, but VP9 is supported more than VP8 when it comes to hardware acceleration. Of course, even if your chipset supports hardware acceleration, whether or not it actually gets used depends on how your video playback software is set up. Ren'py uses libav for playback. One presumes that the version of this library that PyTom uses was compiled for hardware acceleration support, but I don't know that for sure.

Realistically, "hardware acceleration or not" is unlikely to be a decision point for the vast majority of people using video in games - the software implementations are perfectly adequate. Oh, if you were trying to play a lot of videos simultaneously, or do "video textures" in Unity inside a 3D game, you might run into problems, but for "just show a single video on a screen in a 2D game such as Ren'py" I seriously doubt you'd ever see an issue.

In addition, VP8 and VP9 are royalty-free, whereas most of the other

You must be registered to see the links

that can be hardware-accelerated have patent entanglements.

MPEG-1 patents have expired, but this is a VERY old format, and doesn't perform near as well as the others.

You must be registered to see the links

You must be registered to see the links

Theora is not patent-entangled, but is considered an obsolete format by many. (Android refused to add native support for it, for example.)

Finally, H.264, which is one of the (patent-entangled) codecs that has pretty much ubiquitous hardware acceleration support, is substantially worse than VP9 in terms of its ability to compress video, so file sizes tend to be significantly larger for equivalent quality, or have more artifacts at equivalent file sizes. Not surprising, since the the format is something like 15 years old at this point. Its primary replacement, H.265, is only slowly being adopted, again because of patent licensing issues. The VP9 compression performance was one of the reasons that

You must be registered to see the links

back in 2015. (Youtube internally encodes videos in a number of different codecs for playback, since it wants to be able to play back on essentially any device, but VP9 seems to be their "preferred" codec.) That last link includes an embedded example showing the improved result of using VP9 over H.264 at equivalent bandwidths.

OK, probably far more than anybody wanted to know, and straying a bit from the question in the OP, but there you are...

You must be registered to see the links

An interesting read, but

1. It's eight years old (August 2010), only a couple of months after WEBM+VP8 was launched.
2. It focuses on playback in browsers, which had only just barely begun to add support.
3. "The initial developer preview releases of browsers supporting WebM are not yet fully optimized and therefore have a higher computational footprint for screen rendering than we expect for the general releases" As such, you have to take the relative numbers with a significant grain of salt for 2019.

Note, I'm in no way trying to argue that software decoding isn't going to take more CPU than hardware-accelerated decoding. Of course it is. The real issue is whether that's the primary decision point for someone building a video, or whether issues of patent entanglement or compression ratio or something else are more significant.

But I did LOVE the line:

And he's correct - 8+ years later, iOS still hasn't added it.

(For others reading the thread, that doesn't mean that Ren'py-iOS won't play WebM videos - it will. What he's talking about is either native support, or support within Apple Safari. Since Ren'py brings along its own video playback software, this isn't an issue.)

I love webm. It's great for distribution, faster downloads etc. but compression comes at a cost. 80-90% CPU load to open a webm will crash a renpy game on 50% of android devices out there. someday webm will rule, and I look forward to it, but it is not this day. A few more years.

 

[recreation]

You must be registered to see the links

I love webm. It's great for distribution, faster downloads etc. but compression comes at a cost. 80-90% CPU load to open a webm will crash a renpy game on 50% of android devices out there. someday webm will rule, and I look forward to it, but it is not this day. A few more years.

The problem is not the container (webm) but the codec. If you use VP9 instead of VP8 you won't have any trouble.

 

[Rich]

I love webm. It's great for distribution, faster downloads etc. but compression comes at a cost. 80-90% CPU load to open a webm will crash a renpy game on 50% of android devices out there. someday webm will rule, and I look forward to it, but it is not this day. A few more years.

A completely valid point. Support for hardware acceleration on mobile platforms could, indeed, be a case where "that's the primary decision point for someone building a video." In that case, one probably should be using the H.264 codec in an mp4 container. On the flip side, if you're only targeting desktop platforms, other factors might be more important to you.

It's all about knowing what you need to optimize for, based on your own particular circumstances.

Also, if one is heavily targeting mobile platforms, it may very well make sense not to take a "one size fits all" approach to video. Given that mobile screens are smaller and app size is more a factor, one could choose to use separate videos, encoded differently, on mobile vs desktop distributions. The mobile versions could use different codecs, as you suggest, but could also be more heavily compressed to save space (the resulting additional artifacts might not be visible on the smaller screen) or even use lower frame rates to reduce the load on the device. If they're full-screen, and it can be done appropriately, one also might play the videos using renpy.movie_cutscene() rather than using the Movie() approach, since PyTom indicates that this is more efficient.

Cross-platform support can be a bitch... LOL

 

[recreation]

A completely valid point. Support for hardware acceleration on mobile platforms could, indeed, be a case where "that's the primary decision point for someone building a video." In that case, one probably should be using the H.264 codec in an mp4 container. On the flip side, if you're only targeting desktop platforms, other factors might be more important to you.

It's all about knowing what you need to optimize for, based on your own particular circumstances.

Also, if one is heavily targeting mobile platforms, it may very well make sense not to take a "one size fits all" approach to video. Given that mobile screens are smaller and app size is more a factor, one could choose to use separate videos, encoded differently, on mobile vs desktop distributions. The mobile versions could use different codecs, as you suggest, but could also be more heavily compressed to save space (the resulting additional artifacts might not be visible on the smaller screen) or even use lower frame rates to reduce the load on the device. If they're full-screen, and it can be done appropriately, one also might play the videos using renpy.movie_cutscene() rather than using the Movie() approach, since PyTom indicates that this is more efficient.

Cross-platform support can be a bitch... LOL

VP9!
Damn did anybody read my post?
VP9 is supported by every major platform, Android since 4.4 (we have 8!), it decodes faster than h264 AND H265 and uses about 20% lesser cpu/computing than H265.
A quote from the link I posted earlier:

it plays so smooth on PCs that we were able to play a 4096×4096@60fps VP9 without any hiccups in our Chrome browser… on a laptop (!!), while a 3840×2160@30fps HEVC video wouldn’t play on that same device at all.

HEVC is H265 btw.

 

[polywog]

A completely valid point. Support for hardware acceleration on mobile platforms could, indeed, be a case where "that's the primary decision point for someone building a video." In that case, one probably should be using the H.264 codec in an mp4 container. On the flip side, if you're only targeting desktop platforms, other factors might be more important to you.

It's all about knowing what you need to optimize for, based on your own particular circumstances.

Also, if one is heavily targeting mobile platforms, it may very well make sense not to take a "one size fits all" approach to video. Given that mobile screens are smaller and app size is more a factor, one could choose to use separate videos, encoded differently, on mobile vs desktop distributions. The mobile versions could use different codecs, as you suggest, but could also be more heavily compressed to save space (the resulting additional artifacts might not be visible on the smaller screen) or even use lower frame rates to reduce the load on the device. If they're full-screen, and it can be done appropriately, one also might play the videos using renpy.movie_cutscene() rather than using the Movie() approach, since PyTom indicates that this is more efficient.

Cross-platform support can be a bitch... LOL

I make VR simulations that run only on $200,000 hardware. So I understand wanting to be cutting-edge, more than most.
But for most game developers, compatibility is important for sales. If you target only players with high-end PCs, you're looking at only <15% of the market. The average PC is 4 years old. Mac users upgrade even less frequently.
Mobile devices are outselling PCs, more and more people choosing mobility, budgeting less towards the desktop.
In the future devices will have hardware decoders for webm vp8, vp9 (see mpeg history)

H.264 has been successful partially because chip makers have built in the ability to decode that codec. The SoC in your phone just understands H.264 video. WebM support is software not hardware.

MPEG-LA has said that they don't intend to charge users a licensing fee, but there is some legal grey area remaining. If you film H.264 video for use in a professional project, could you incur licensing fees? We’re not sure what could happen in the future, but Google wasn't willing to take the chance, so they developed WebM.
However... video compression is hard. So hard, that many of the same ideas end up being re-used. Many suspect that WebM may be using some patented technologies because of this. MPEG-LA (the folks that watch over H.264) have decided to assemble a patent pool for WebM. It remains to be seen if companies buy in to avoid possible legal action down the road.
Not a big concern for somebody making small videos for a small market.

 

[recreation]

WebM support is software not hardware.

Sorry, but this is simply wrong. And again, webm is just the container, not the codec. The codec is VP8/9.

You must be registered to see the links

You must be registered to see the links

 

[polywog]

Sorry, but this is simply wrong. And again, webm is just the container, not the codec. The codec is VP8/9.

You must be registered to see the links

You must be registered to see the links

saying webm is just a container not the codec, is like saying frozen fish is yummy

You must be registered to see the links

 

[recreation]

saying webm is just a container not the codec, is like saying frozen fish is yummy

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.

 

[recreation]

And sorry if this came of offensive, it wasn't meant to, but I wanted to clarify this.

 

[anne O'nymous]

In the future devices will have hardware decoders for webm vp8, vp9 (see mpeg history)
View attachment 269930
H.264 has been successful partially because chip makers have built in the ability to decode that codec.

Why are you using a

You must be registered to see the links

NTSC/PAL/SECAM decoder to illustrate this ? It's far from the subject since it's an analogical to numerical converter. It really looks like you searched "video decoder chip" on google image, then picked the first image on the second page, without caring if it will be something accurate or not.

And why exactly chip makers should "decode" H.264, when the

You must be registered to see the links

are public and available for free ? It's their use that is subject to legal few due to the patent, not their reading. It would be simply stupid for a codec developer to hide the specifications ; especially if he expect it to become an income source. Anyway it's an

You must be registered to see the links

, so I'm almost sure that there's an obligation to keep the specifications public.

saying webm is just a container not the codec, is like saying frozen fish is yummy

Is Google aware of this ?

You must be registered to see the links

VP8/VP9 video and Vorbis/Opus audio are the only codecs allowed in a valid .webm file. Why did you define WebM so narrowly?

We decided to define WebM files in this way because we wanted to do what's best for users. Users just want video to work, they don't want to worry about supported codecs, file formats, and so on. After much discussion with browser makers, tool developers and others, we reached a consensus that a narrowly defined format would cause the least confusion for users. If a user has a .webm file, he or she can be confident that it will play in any browser or media player that supports WebM.

[Personal note: Apparently it still cause confusion with some users...]

Note that the question itself clearly separate the codecs from the WebM format. It also talk about "valid .webm file", implying that obviously the container can still works with other codecs, like almost all multi-media containers.


And also, what On2 Technologies think about your assertion ? After all, they are the one that created the VP8 codec

You must be registered to see the links

, so 2 years before Google

You must be registered to see the links

. And also 2 years before Google

You must be registered to see the links

, developed to ensure that there will always be an Open Source container for their, now Open Source, codec (as said in the FAQ linked above).
The same question apply for Xiph.org, developer of the Vorbis codec,

You must be registered to see the links

under it's first final specifications, and for the working group of the IETF behind the Opus codec,

You must be registered to see the links

.

 

[Nottravis]

*is looking...puzzled?*

 

[recreation]

*is looking...puzzled?*

To make it simple: Use what you like
And if you're going to make videos, use mp4 or webm format

 

[Goblin Baily: DILF]

I've had a look (honest!) but can't seem to find a pre-existing answer to this one...

So, I've had small animations in the second chapter of my game but they were quite simple and I was able to get them in the old Renpy machine by simply adding them the frames as scenes and sticking a 0.1 delay in between them all. So far, so simple and it worked nicely enough.

For Chapter Three I've pushed the boat out a bit and have three animations of several hundred frames each. (my patrons bought me a new graphics card so...seemed only right to use it!). OK, all very nice, but why am I telling you all this?

Because it's dawned on me (yes, only just now...) that given I usually have around 500-600 images per monthly release, I'm going to be doubling my file size this month if I do it the way I usually do. Now, this doesn't seem like that should be the case and I suspect that there's a more efficient way of getting these animations in that doesn't involve whomping up the download size by an extra 400-500mb.

So...my question is, how do I drop animations into renpy in the smallest Mb size possible without losing graphical quality? Any answers gratefully accepted. Thanks

keep in mind that MEGA has a limit of 5 GB/ six hours... if you manage to keep the chapters within that size, everyone will be fine considereing quality vs size

 

[recreation]

keep in mind that MEGA has a limit of 5 GB/ six hours... if you manage to keep the chapters within that size, everyone will be fine considereing quality vs size

Keep in mind that there are still people on the world who don't have highspeed internet, and some people won't download games this size in general. There was a thread about the filesize in adult games not long ago where many people actually said they prefer smaller filesize.

 

[Goblin Baily: DILF]

Keep in mind that there are still people on the world who don't have highspeed internet, and some people won't download games this size in general. There was a thread about the filesize in adult games not long ago where many people actually said they prefer smaller filesize.

I'm well aware of that, but I'm also aware that some games are worth the slow download

 

[Nottravis]

Keep in mind that there are still people on the world who don't have highspeed internet, and some people won't download games this size in general. There was a thread about the filesize in adult games not long ago where many people actually said they prefer smaller filesize.

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.

I can't deliver a final game in excess of 7gb. I'm looking at individual chapter downloads as a solution but that's another nightmare for another post...

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

 

[Akamari]

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

I don't think that would be necessary!

 

[Nottravis]

I don't think that would be necessary!

One ani is over 300 frames with panning etc. So just cutting the frame numbers won't work as the composition would be...meh.

I'll still work on it but if I can't wrestle it down I'll release the original as a bonus jobbie as it would be bloody shame for it not to see the light of day.

*really should think this stuff through more...*

 

[Akamari]

One ani is over 300 frames with panning etc. So just cutting the frame numbers won't work as the composition would be...meh.

I'll still work on it but if I can't wrestle it down I'll release the original as a bonus jobbie as it would be bloody shame for it not to see the light of day.

*really should think this stuff through more...*

I really don't think you should cut down on content just because of the size. Besides I am of belief it can be brought down to respectable levels size-wise while keeping the quality.