Playing video with alpha channel in AS3 (VP6 On2) - actionscript-3

I want to display a video with alpha channel. I've found an old article that describes exactly what I want to do, and says that it is possible with VP6 On2 codec, which tends to be correct according to adobe site:
The On2
VP6 codec provides:
Higher quality video when compared to the Sorenson Spark codec encoded at the same data rate
Support for the use of an 8-bit alpha channel to composite video
The designer I am working with was able to create such a video in AfterEffects, but when I play it flash player does nothing: no errors, no log entries - it just silently works without drawing a thing. However when I asked the designer to encode the video without alpha channel flash played it perfectly.
The code I am using is pretty straightforward:
var flvPlayback:FLVPlayback = new FLVPlayback();
flvPlayback.addEventListener(MetadataEvent.METADATA_RECEIVED, onMetadataReceived);
flvPlayback.width = 300;
flvPlayback.height = 300;
flvPlayback.play("http://192.168.0.102:9998/assets/video/test.flv");
I am developing in IntelliJ IDEA, using Flex SDK 4.6 and FLVPlaybackAS3 component from Flash Professional 2015.
Do I understand correctly that Flash dropped support for FLV videos with alpha channel? If yes, then is there any other alternative that is production-ready?
P.S. I am aware of producing such an effect by combining two videos' output to bitmap (where one video contains RGB data and other contains mask as RGB), but it doesn't produce steady FPS on an average hardware.

Try this code:
flvPlayback.alpha = 0.2;
I have checked this with FLVPlayback 2.5 in Flash Player app

Related

How to access audio stream of BackgroundMediaPlayer Windows Phone?

Is it possible to add custom sound effects to the music being played by BackgroundMediaPlayer? I need raw samples, like in PCM, to apply some simple math.

Flash to HTML5 Loss of interactivity

I have Some sample fla Content which I am not able to convert into HTML5 with interactions
What I tried is
Google Swiffy --> Gives interactions [not full] but no sound. Issue is it works for content less than 1 MB
Toolkit for CreateJs --> Initially I got jsx errors but I cleared them by removing Special Characters in element names. But non of the case I got interactivity [Means I was not able to use my Mouse events or clicks
HTML5 Canvas in Flash Pro CC --> even here I got same above result.
Did I am missing something ??
You didn't really miss anything. Flash's HTML conversions do not convert AS3 to JS (that would be nice if it did). In this case you have to write the interaction using JS.
Sounds like you're using Google's online SWF-to-Swiffy converter, which has a 1MB limit. There's a better way, if you have Flash Pro CS5 or CS6 and the original FLA files. Try this:
download Google's swiffy generator and instal it in your Flash Pro (read instructions carefully)
open your FLAs and find the sounds that don't play in the swiffy file - most likely they are set as streaming sound (streaming audio is not supported by Swiffy), so change them to event sound
BUT, looped event sounds exported to Swiffy only play once (they don't loop), so if you need them, export the sound from the FLA (as .wav), and copy and paste it as many times as necessary in a new .wav file and re-import
All done? Now export from Flash Pro using Command -> Export as HTML5 (swiffy)
NB: Google's Swiffy extension for Flash Pro won't work with Creative Cloud, and on mobiles there'll be NO AUDIO whatever you do - sound only seems to work on desktop PCs, owing to mobile restrictions on unsolicited big-file preloads.

Accurate Seek in Pseudo-streaming Flash

I would like to know if the flash fallback (medialement or any other) can support accurate seek to the frame for an H.264 video in a MP4 container, transferred by HTTP using an IIS or apache web server (HTTP Pseudostreaming or Progressive Download). In HTML5, we can order to seek to any frame number and it will manage to decode whatever is needed to display the requested frame index.
Currently, what I can experiment with all flash player is something like a seek to the closest GOP or keyframe. However, this is unfortunately not enough for my project as I really need to be able to reach any arbitrary frame.
Do you know if there is a way to have an frame accurate seek in Flash, using HTTP pseudo streaming (I know this is possible with FMS and RTMP streaming).

Web Audio API: seek, play-/buffer-progress

When you play audio using the audio element in Chrome you get annoying clicks and cracks. At least under my 64bit Linux installation, even after I formatted and installed a new Fedora version. (Firefox and Opera are fine, even IE9 in a VirtualBox Windows 7.)
But demos using the Web Audio API instead of the audio element have perfect sound. So I was wondering if I could use the Web Audio API like the audio element? But there are some things you seem not to be able to do with this API. Or am I missing something? The things I couldn't find where:
starting to play a file before it is completely loaded
getting buffer progress updates (depends on the previous point)
getting play progress updates
seeking
Is there a way to do this with the Web Audio API?
This is where I would use it: http://tinyurl.com/magnatune-player
I think you should still use <audio> for streaming at the very least. You can treat it as a MediaElementAudioSourceNode in web audio if you'd like:
var mediaSourceNode = context.createMediaElementSource(audioElement);
AFAIK, there is no way to stream web audio directly. In fact, the web audio api suggests that you don't:
4.9. The AudioBuffer Interface
This interface represents a memory-resident audio asset (for one-shot sounds and other short audio clips). Its format is non-interleaved IEEE 32-bit linear PCM with a nominal range of -1 -> +1. It can contain one or more channels. Typically, it would be expected that the length of the PCM data would be fairly short (usually somewhat less than a minute). For longer sounds, such as music soundtracks, streaming should be used with the audio element and MediaElementAudioSourceNode.
Unless you used a MediaElementAudioSourceNode (which I would assume suffer from the same issues you're having since it's just using an <audio> tag) AFAIK the answers to your questions are:
starting to play a file before it is completely loaded: No.
getting buffer progress updates (depends on the previous point): Possibly (You could check for progress events on the XHR)
getting play progress updates: No.
seeking: No.
In the meantime Chrome fixed the audio playback issues. So I don't need any workarounds anymore.

How did Scirra get HTML5 audio so perfect in Construct 2?

Check out this space shooter demo.
The HTML5 audio is perfect on Chrome 18 and Firefox 10. There is no lag in playing sounds and each sample plays perfectly. The last time I tried to play sounds using HTML5 audio and JavaScript I couldn't get a sound to play more than once.
What sorcery is Scirra doing to make this so perfect?
I'm the developer of Construct 2, so I hope I'm sufficiently qualified to answer your question :)
HTML5 audio is indeed a mess, so I've gone to considerable lengths to try and make it bulletproof in Construct 2. Here's an outline of what I've done:
Use the Web Audio API
HTML5 audio appears designed for streaming music, so a HTML5 Audio object is kind of a heavyweight object. Playing 10 sounds a second with it like Space Blaster does can easily seize up the browser. On the other hand, the Web Audio API is a high-performance audio engine with routing, effects, and lightweight sound playback. It's perfect for games. Audio buffers and audio playback are separated, so you can have one data buffer and efficiently play it many times simultaneously, whereas some browsers are so buggy if you play a HTML5 sound a few times it re-downloads it each time! Since it was actually designed for games and such, you can happily play back tonnes of sound for ages and it will still hum along nicely. It can also use HTML5 audio as a sound source, although I only use HTML5 audio for things the user has designated as music tracks (since that's where you'd prefer to have streaming - typically everything else in the Web Audio API is fully downloaded before playing).
The Web Audio API is supported in Chrome, has also made it in to iOS 6+ (although it's muted until you try to play some audio in a touch event), Firefox are working on support, and it should be coming soon to Chrome for Android. So on these platforms audio will be significantly more reliable.
More info on HTML5Rocks and the proposed spec - you'll have to use the spec as the documentation for now, there's not much else out there.
Other browsers: implement an audio recycling system
The Web Audio API isn't yet supported everywhere, notably IE, which means you still need to crowbar HTML5 audio in to something that might work for games for backwards compatibility. The way to do this is to recycle audio objects.
The player's laser in Space Blaster fires 10 times a second - and that's not including any other sound effects! As I mentioned earlier, Audio is kind of a heavyweight object, so if you're doing new Audio() 10+ times a second, lo and behold, the browser eventually dies and audio starts glitching up. However, you can drastically reduce the number of Audio objects created by recycling them.
Basically, for each sound effect, keep a cache of every Audio object you've created with that sound as a source. Then, when playing a new sound, search the cache for any sound effects which have finished playing (the ended property will be true). If you find one, rewind it back to the beginning (currentTime = 0) and play() again. Otherwise, create a new Audio() object in the cache.
Since the player's laser sound effect is short, instead of creating 600 Audio objects a minute, there will just be 3 or 4 that it keeps cycling round. Some browsers unfortunately will still download it 4 times (Safari did this last I checked!) or have high latency the first time each sound buffer is played, but eventually the browser catches up since the same buffers are always being reused. So basically sound might be a bit weird for a few moments, then it clears up. We also use the HTML5 app cache so next time you play everything loads from disk, so subsequent plays should perform well immediately.
That's basically it. It's still a little dodgy on the first play with HTML5 audio, but every time after that should be fairly solid providing the browser has a sane audio implementation. There are a number of ways to try to clone Audio objects, but I've found that rewinding existing Audios works best.
There's no SoundManager or any Flash/plugin-based fallbacks at all since we make a point of being pure HTML5.
We also support audio APIs provided by PhoneGap and appMobi for mobile, since HTML5 audio on mobile isn't even worth trying. That makes a total of four audio APIs our audio engine wraps, and yes, it does look like a frankenstein mess, but it works.
That's it. I suppose our competitors will read this, but who cares when there's SO rep to be had???!!!1111