[pecenipicek]

i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power

[Nuke]

I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.

to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.

[mjn.mixael]

Just go with what we have already in the code. No reason to bulk it up if what we have works.

[The E]

i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power

One problem: There is no h264 implementation that is licence-compatible to FSO.

I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.

to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.

No.

[mjn.mixael]

I don't think we have any problems using .ANI for 99% of the interface art we currently use ANI for.

to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.

No.

That is not helpful at all... 

[The E]

The reason is that I think the last thing FSO needs at this point is a new proprietary format.

[mjn.mixael]

Agreed.

So.. how bout that .ogg support for cb_anims? 

[pecenipicek]

i'm just saying. if size is any concern at all, i find it doesnt get any better with the quality/size ratio than x264. (well, its not so apparent on short anims and such, but on anything beyond 30-60 seconds or so, it starts to show it power

One problem: There is no h264 implementation that is licence-compatible to FSO.

Good point there.

[Goober5000]

to go off on another tangent here, can we get a container format for eff for that 99%, so we can upgrade the indexed color icons to 32bit color icons, and do it without littering the interface directory with effs. perhaps a container with the eff contents as the header. this of course has nothing to do with ogg support.

This is actually the best long-term solution (provided that it is actually a container format, not an EFF which is nothing of the sort).  And again, this is an enhancement that has been on the SCP to-do list for a long time.

So.. how bout that .ogg support for cb_anims?  

I'm not a graphics coder so take this with a grain of salt, but I suspect it would be rather difficult.  The current OGG movie player is designed to play full-screen or on a window, and not to be composited on top of some other interface art.  By the time you spent the effort required to hack together a modified OGG player, you could have already finished the new container format.

And keep in mind, as karajorma said, that you can already play an OGG movie as a full-screen substitute for a command briefing.

[The E]

Yes, you can play an ogg as a replacement for a CB. What you can't do, however, is to go back and forth between CB stages that way.

And really, a new container format? In the end, that would mean that we'd need a new content creation tool as well. While that might not be difficult to produce, I have to ask if it is really a good idea when we could just as well use a standardized format that can be produced using standard tools and converters that are already freely available.

One problem that a container similar to ani has (which, for those who do not know, is basically a container for a series of pcx files with the individual headers stripped off) is that there is no real video compression going on. As the use of png-based effs proves, these files can become prohibitively large (even anis have that problem; mjn can provide the data here). ogg theora, or other video codecs, would allow us to be way more efficient in that regard.

[chief1983]

*sigh* even if there's no h264 implementation, there is VP8...specifically, ffvp8, part of ffmpeg, which is LGPL.  Sorry if I'm starting to sound like a broken record, but if we _were_ going to add another video format, that seems the way to go to me.

[Nighteyes]

well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO

[The E]

well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO

No, it really doesn't.

[pecenipicek]

well there is a downside in using ogg as cbanims, this way there is no option to use cbanims with alpha channel(as far as i know)...
EFF animation with PNG images produces pretty small animation sizes in terms of mgb IMO

since when do cbani's actually need alpha maps for... anything?(no, i do not consider interface elements to be normal CBani's in that way, CBani's are the Command Briefing Animations... with a strictly defined space, aka in the command briefs! video's would work nicely there. no keyframing needed, just looping, end of story.)



and to echo what The_E said, no PNG really doesnt produce "small animations", being a lossless format, that produces better compression when there are lots of flat colors, but doesnt do so well with the "typical" data a game might use (varios animations, etc)


PNG might do well for interface elements and such. but using it ingame for explosion effects and the like? waste of RAM and HDD space.

[The E]

Having an Alpha channel in a cb ani is a very good thing, IMHO. The cb anis used in War In Heaven work very well that way.

[pecenipicek]

*has forgotten how WiH cbani's looked*



but the point is, they arent 100% neccesary.

[The E]

True.

[Nighteyes]

*has forgotten how WiH cbani's looked*



but the point is, they arent 100% neccesary.

yep. those are the cbanims I did btw, now its easy to say its not 100% neccesary, and its true, but its something that works currently and I don't see a reason to implement something take will limit us in any way.
I don't recall saying anything about using PNG animations as effects in game, thats plain stupid and as far as I know only TGA and DDS are supported... for cbanims, using the EFF method of animations, PNG is the best way(please enlighten me if im mistaking), and please don't mention the word ANI...
now, back on topic, I don't know if it might be possible at all, but I know some games can read 7zip files, so if we could zip all the frames and eff file into one compressed file, and have the game be able to read it upon request, that can be a nice solution.

[Goober5000]

EFFs do not work well as cbanis.  They don't stream, and the game has to open and close one file per frame, which is not good for performance or memory management.

Keep in mind that a new ANI container format would not only be used for cbanis, but also for anything else an ANI is typically used for.  You could have animated main halls with more than 8-bit color depth, for example.

[Galemp]

Goob, please try to stay on topic. Filesize, or indeed color depth, on mainhall animations is not an issue. Having hundreds of megabytes or thousands of EFFs in the cbanis folder IS the issue. We need a format that has video-level compression and low data loss that can loop, that's it. And I think a new proprietary ANI format would be acceptable, honestly.