I've searched and found no answer, and the GIF specification is over my head. What is the longest possible delay between frames in a GIF animation?
Your reference says the delays are 2 byte unsigned integers and the unit is 100ths of a second. So the max duration in seconds would be (2^16-1)/100 = 65535/100 = 655.35s or about 11 minutes.
Related
I am building a video rendering engine and am stuck on a problem. I would like to determine the rate at which to take the screenshots.
Currently, I am setting the rate to be 25 fps. From that, I can determine the total screenshots, as an example, a 10-second video would be 250 screenshots.
for (let i = 0; i < 250; i++ {
//... i / 25 fps is what I set the HTML 5 video to be
//... this means every 0.04s or 40ms a screenshot is taken
}
The problem is that in my editor a user may combine a 25 fps video with a 30 fps video. I have found the 30 fps video will at times be choppy because the natual rate would be i / 30 which means it needs a screenshot every 0.033s or 33ms.
I am trying to come up with ways to combat this from being an issue. I would like to inform myself more around solving this problem.
As for solutions with my existing knowledge I can only think of two.
make sure every video that gets added to the editor gets re-encoded with 25fps, this could still cause issues and be problematic, since removing frames could cause jank, and adding frames is impossible.
have a variable frame rate while taking the screenshots so that when the video in view is 30fps I can change the rate of the screenshot mechanism. This poses problems when layers on top use an animation frame rate of 25 fps, or if it's next to a video side by side with a frame rate of 25.
Both solutions I can think of arent the best. So I would like to ask the folks who understand this problem the most and would like to share some of that knowledge.
Lastly, it seems the browser does a good job of handling this which tells me it's possible. Here is a screen recording of the app https://share.getcloudapp.com/KouwpkwE the first run was a bit sluggish but the second one showcases the video in the background using a frame rate of 30, then the lottie animation on top using a frame rate of 25.
When trying to capture this frame by frame at a fixed 25 I run into issues. Any techniques to solve this?
Thanks
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 7 years ago.
In my program, I have a score multiplier variable of type 'Number'
When I try to add 0.1 to it, I have a problem.
Here is the code:
scoreMultiplier += 0.1;
trace(scoreMultiplier);
scoreMultiplier is originally set to 1, and after the first run through, I correctly get a value of 1.1. However, the second time, the trace shows 1.2000000000000002, and the next time 1.3000000000000003.
There is no other code which modifies scoreMultiplier. This is a problem, first because it is shown on my game screen and goes off the screen, and second because if conditionals where scoreMultiplier==2 for example do not work due to the bizarre fault in the addition.
If anyone knows what's causing this, or at the very least how to truncate the value to 1 decimal place, that would be great.
Flash does not like floating points. At all. Avoid them as much as you can.
I use cocos2d-x 3.0 on Windows, but the game should be on Android and iOS.
I want to create coin collection sound. My player can collect for example 10 coins with 0.1 seconds delay. Now I want to play the same effect 10 times with the same delay, whereas my effect length is 1 second. SimpleAudioEngine does not play that. How I can achieve that?
In other words I want to play the same sound with multiple streams. Please help me.
Size matters. If the size of .wav file is "enough" small, then it can play multiple times.
Apologies in advance, but this isn't really a photoshop question. Rather, I'm trying to come up with something that is convincing but exploits the compression and features of the gif format as best as possible to produce the smallest possible file for the animation.
Some constraints:
It needs to be at least 20 or 30 frames. I've tried with fewer (and since they're largely uncompressable 15 frames is half the size of 30, generally speaking)
Size needs to be no less than about 256x192
It doesn't need to be color though, nor even full grayscale. I've seen convincing stills with as few as about 16 grays
It can have a pattern, but not one that is instantly obvious to the human eye. If someone takes a single frame and after a minute or two can spot the pattern (which makes it compressable?) that's ok
Frames 2 through n can use quite a bit of alpha, but when I started using big horizontal stripes of alpha, it was instantly noticeable to my eyes. So you don't get to rack up a bunch of RLE with the easy cheat.
All of the above and still needs to look good at 30-33ms frame speed. No variable speed or relying on anything significantly faster than that.
Also acceptable: an apng that complies with the above constraints. Possibly even mpeg, if you can come up with that (I'm ignorant of how the DCT does its magic).
Ideally I could get something down in the 250kbyte range, but I'd settle for anything significantly smaller than the 9 meg monstrosity I cooked up last week.
Oh, and one last thing: obviously I don't expect anyone to supply the graphic for me. I'm just looking for some trick(s) that will let me get there myself eventually.
This is a very interesting question.
Static (random noise) by its nature is actually highly incompressible. Information theory says that true noise is basically incompressible, and the more patterns something contains the more compressible it becomes (to the point of a solid line of 1's or 0's being perfectly compressible.
The ideal would be to create a true noise generator (just random numbers), but that doesn't help within the constraints of your problem.
The best thing I can think of is storing a number of small tiles of static and displaying them in staggered fashion to prevent the eye catching on to any patterns. Aside from that, you won't have much luck compressing this beyond 256 x 192 x 20 / 2 or about 500 kilobytes ( assuming 20 frames with resolution of 256 x 192, using 4 bit color depth ).
Simply encoding your animated gif in 16 color mode should get you to that point.
Well old but still unanswered answer (not checked anyway)
so create the NoSignal image data
If it is not obvious how read this:
NoSignal in asm and C++
encode into gif
Had played with it a bit so I used resolution 320x240, the lowest bit resolution usable is 3 bit per pixel. Lower does not look good. Single global palette only (obvious) here 300KB example
[Notes]
if this is just for some app then generate the image on the run it is really just few lines of code see that linked answer in bullet #1
Yes, you can achieve that with a lossy GIF compression, or rather a specifically rigged compressor that outputs noisy LZW stream.
A best-case scenario for LZW compression is to output X pixels, then X+1 pixels, then X+2 pixels, etc. It's easy to make that noisy.
Try screwing up the gfc_lookup function to (almost) always return longest dictionary item and compress series of noisy frames with it:
https://github.com/pornel/giflossy/blob/master/src/gifwrite.c#L270
Not easily normally. Good randomness (high entropy) by definition does not compress well. Having it greyscale may help, but not much.
If you want to do this on a web page and you have (some) control, you can always write a very small bit of JS to help... if you can do this, then you can do the following:
Create a gif about 1.5x the size you need with high-entropy static.
Set the clipping to the size you want.
Then you randomly move it around by changing the starting offset.
As long as your offsets are a decent distance away from one another (and don't repeat patterns) it is usually difficult to discern it as movement, and it looks truly like static.
I did this trick about 20 years ago on an Amiga to emulate static on a limited-memory demo, and it worked remarkably well... it also does not require fast low-level code as all was done by changing offsets and the co-processor bitblit-ed the rest.
I am working on a Flash Video player and am implementing the ability to start a video at x time within the span of an FLV (served from FMS). I am able to start it x seconds into a stream without any issue using
netStream.play(source, startTime);
but as far as I can tell, it only supports seconds. I am looking to be able to give a start time (or even a seek time if that is supported) in milliseconds, or really anything more precise than whole seconds.
Anyone know of any way to achieve this even by monkey patching the fl classes?
Thanks,
Doug
Well the seek will allow you to seek by a number of frames, but the spec says that it only seeks to the closes I-Frame in the FLV. That will become a problem with any method you use, because the I-Frames are the only ones that actually contain the whole picture frame (here's the gist of that).