>>20464You can use .flv-files created with FLV Maker in SwfH264 but there isn't much point in doing so.

FLV files created in FLV Maker are encoded using VP6 + Mp3. These can be embedded into the main timeline of a swf, having the benefit of being seekable to every frame and being streamed (you can start watching the video before downloading the entire flash).

FLV files created for SwfH264 are encoded using H.264 + AAC (newer codecs). Those will produce much better quality than the old VP6/Mp3 combo but cannot be embedded into the main timeline of a swf. Flashes created from SwfH264 simulates that the FLV is being downloaded from somewhere else and due to how byte arrays are embedded into swf files the flash must be fully downloaded before the video can start to play.

If you use a VP6/Mp3 kind of FLV with SwfH264 there will be no increase in quality per byte, the streaming feature will just be sacrificed for nothing. Also, FLVs that are created with FLV Maker must still have their metadata fixed or else they won't be seekable in the flash created with SwfH264 (the reason that they are seekable in flashes created with the toolkit in FLV Maker is because they are able to be embedded on the main timeline - and then they are more accurately seekable because they don't rely on keyframes in the video).

Why I can't save the SRT file I created from the app? If I want to correct any mistakes or make a better version, must I start from zero?Or better, make an option to save all the options plus the subtitles to a file that you can load after.Also, if the subtitles have more than two lines of text, from the third line, the text is cut.

>>20601Glad to see it being used! All the things you mentioned are already noted on the "Possible Improvements"-list towards the bottom of the project page, except that part about subtitle text being cut from the third line. I'll make a note of that and will look into it the next time I make an update.

For now I recommend that you always create the subtitles using a proper .srt program. It's mentioned on the project page as well in the example (next to the third screenshot).

I didn't want to go overboard with the initial features in SwfH264, as with most of what I do I try not to waste too much time on something until I see it actually being used by people. Further development of SwfH264 depends on if I start seeing many flashes created by it, or if people demonstrate interest in the program by posting here.

>>20624To be more constructive about that:Gulim, Meiryo and Arial Black are bundled with Windows. You could reduce your distribution size by 11MB by dropping them and fetching them from "%windir%/fonts". You could check "/usr/share/fonts/", "~/.local/share/fonts", "/Library/Fonts" and "/System/Library/Fonts" as well to make Mac/Linux people happy.

Or just:java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts()to get every font installed on the system, regardless of platform.

>>20626I included those just to be sure they would always be available, though I was thinking about dropping Gulim and Meiryo since they are so large. They probably won't be used much and should be available anyway when needed. Might replace them in future versions with something more fun, especially Meiryo since it's a bit luxurious to have two Japanese fonts when I think about it. Arial Black is so small (just 117 KiB) so might as well keep that one since it's the initial font for the source bar.

The default behavior of loading a font in Java should be cross-platform, as far as I know it always searches all available locations for the entered font name and should find it as long as it's installed.

Could you share sources for template.swf for people who want to change preloader animation?

I tried to decompile it and managed to build a working version. Unfortunately video/subtitles embedded data was loaded in frame 1 (instead of frame3) meaning that preloader didn't work at all. My Flash/AS3 knowledge is too weak to fix that.

>>21198You could try manually moving the embedded data using Flashbulb. Click a DefineBinaryData tag, click the right-facing green arrow, click the red X to delete the original tag, click a tag with a "3" next to it, press the curvy left-facing arrow to insert the tag into frame 3 of the file. 'course you'd have to do this for every file you made. If you upload the swf somewhere I'll do it for you, out of curiosity to see if it'll work.

>>21201Correction: you actually wouldn't have to do it every time. Flashbulb should be able to import FLVs directly into the DefineBinaryData tag, so you could swap out videos that way. Captions may be another story.

>>21206Thinking about it, Flash only stores the characters it actually uses in its font tags. If you used SwfH264 to make a video with subtitles with every alphanumeric character, then replaced the fonts of your template file with the ones from that video, you would be able to freely swap out captions too.

>>21198Not ready to open source anything for this project, at least not yet. But I'll make a TODO of trying to add the possibility of a custom preloader, or the option of removing the preloader completely.

>Unfortunately video/subtitles embedded data was loaded in frame 1 (instead of frame3) meaning that preloader didn't work at all.With the .fla project open go to "File" > "ActionScript Settings..." to open the Advanced ActionScript 3.0 Settings window. There you change "Export classes in frame" from 1 to 3. Perhaps that will get your hack to work?

>>21211C'mon, do the right thing and release sourcecode. No point in keeping progression of this app in the gutter. Once the source is released, we can get on about fixing the loose ends and wrapping it in a proper WYSIWYG interface for those who don't into Adobe+Sony. (parametric controls are for linuxfhags, not humanz)

>>23709I intend to improve the program myself but I'm busy with another project at the moment. Sorry man.

>>23794I'll probably include less fonts in the next version to be honest. It's because you can use any font that is installed on your computer, go to Control Panel > Fonts to browse everything you can use in SwfH264.

However if you have a suggestion for a super good font that people usually don't have installed by default in Windows please let me know!

>>27211The swf file is stretching the video inside of it, the actual video is still 360p so there's no actual change in the video's resolution. If you're worrying about any change in the video file you don't need to, SwfH264 doesn't change the video at all. There is no upscaling. You can resize the swf player to a smaller size if you'd like to. Er, I guess it was a strange decision of me to make the player always have a certain size. I think my reasoning at the time was that I wanted people to be able to open the flash and watch it immediately without having to put it in fullscreen (since low resolution videos otherwise would be so small on a modern screen). I'll add another TODO to the pile though. If you really, really want a smaller swf file I think it would be safe to hack the output swf and just change the resolution in its header. If you intend to embed it on a webpage you can just change its width/height with HTML. The key thing to remember is that the size of the swf doesn't affect the quality or resolution of the embedded video.

Just a heads up for the ffmpeg thing, it's better to put the -ss before the -i as doing it with -i first causes ffmpeg to load the entire file before skipping to the piece of time you want, while -ss being first makes it skip to that time and then load the remaining.

Note that this might change when the time comes. Especially "-tune grain", which wants the input video to be of excellent quality. "-acodec libvo_aacenc" was replaced with "-acodec aac -strict experimental" because the native experimental AAC encoder is supposed to give better quality than libvo_aacenc from what I've read. I'd like to make the new acodec "libfdk_aac" instead (for Fraunhofer AAC encoder) if I can get a compiled version of ffmpeg.exe with the codec installed. Don't know if Apple AAC is possible? That sounds very licence-esque.

The bundled general-solution will be 2-pass since that improves quality further, even if that means changing stuff on two lines. Question is if it always improves it or if it could make it worse sometimes? I actually did try 2-pass out for the first version of SwfH264 but I must have fucked it up because I didn't notice any quality improvement and decided to skip it for simplicity's sake. But since then I've noticed that yes of course it improves the final result. If someone sees this that happens to be an expert on making 2-pass encodings with ffmpeg please post any advice that you can! Maybe there's more to it than I've written in this post?

Two-pass encoding is used when you want a consistent average video quality throughout a video at a specific resulting file size. What is really going on behind the scenes is on the first pass, ffmpeg analyzes the file and builds a data structure that indicates where more bits are needed than others to maintain an average q level throughout. Then on the second pass, that analysis is used to vary the bitrate as necessary to reach closer to a specific file size.

This is nice because if you want a file that is 10MiB in size, it is much easier to get a result close to that with two pass encoding. You divide the file size (as kbit) by duration (in seconds) then subtract the audio bitrate and then subtract maybe 2% of the resulting value to account for overhead and you get an appropriate value for where you would want your bitrate to be.

What you are seeing by using 2 pass encoding is that certain scenes that would look much better take a quality hit so that more complex scenes can maintain consistent quality with the less complex scenes. For /f/ and the like, this is acceptable.

>if I can get a compiled version of ffmpeg.exe with the codec installed. Don't know if Apple AAC is possible? That sounds very licence-esque.

You can't legally distribute ffmpeg with libfdk_aac built in. That changes its license to non-free. However, it would be very beneficial to indicate an easy solution to this because libfdk_aac supports high efficiency AAC (aac-he). AAC-HE can be used at low bitrates (think 32k and lower) and still sound passable. I usually use it around 32K because the native aac encoder doesn't even sound comparable at 64k with normal aac.

You could nudge people to use this to autobuild a static copy of ffmpeg. Just *don't* build mediainfo or it bombs out, and its not necessary to build all the extra binaries so long as you just want ffmpeg.

>>28622Thanks for the input! Hm, sounds like there won't be anything more fancy than "-acodec aac -strict experimental" then since I want things to be ready out-of-the-box for people that use SwfH264. I doubt I have the capability of nudging people into going through all the hassle of compiling their own version of ffmpeg for those extra few percentages in sound quality. Usually regular AAC is "good enough", I figure only when you hear two demo samples played after each other you'd be able to pinpoint the difference. It'd be worth it for longer videos but will the regular Joe really bother? But I should probably at least mention somewhere that a better audio codec exists, for those that need it and are willing to go though the effort to obtain it.

>>28642Right, self-compilation is a pain in the ass. In my mind, it'd be kinda nice if the general tool could take into consideration at least some of the optimizations. I had something like that for myself but I lost it with my last OS reload :(

There's been some pushback on /f/ because the average joe doesn't look further than the general tool, and so the results have been poor. I think the options you've got now will help a fair bit but IMO anything that can be done to take tweaking steps out of the hands of average joe would help the appeal of this tool.

>>28643Arch Linux has the AUR package "ffmpeg-full" which is relatively painless for installation.

Anyway, while we are talking about features, I would request the ability to loop back to a previous time. Like>Video Starts from 0:00>Video hits 1:24 that repeats at 0:54>Video loops 0:54 to 1:24 indefinitely

>>28742Would be a good feature, especially since it differentiates the video played through flash from the video on YouTube. I was also thinking about being able to detach audio and video so one could use SwfH264 to make flash loops... Phew, the TODO is getting heavy.

>>29383No, the issue is that the bytes of the whole movie is embedded into ActionScript 3 and flash loads all of its classes on a single frame so you have to load it all at the same time. Even if the bytes are split up into several classes all classes have to be loaded on the same frame.

I have thought up a workaround that involves loading chunks of movie bytes as jpg images, which don't have to all be loaded on the same frame. You basically have to trick flash into thinking it's loading a jpg when it's really just an array of bytes. When the fake image is loaded you extract the bytes from it and append it to the main byte array of the movie. Storing the bytes as audio data would probably be better or even easier than doing it as fake images... Flash is great at streaming audio chunks from the main timeline and those are expected to contain all kinds of random bytes. Anyway, haven't put it into practice yet but in theory it should be possible.

While I'm rambling, wonder if Adobe will add H.265 support to flash? That would basically mean twice the quality for the same file size, judging from what I've seen of the codec so far. If nothing else it would mean that Flash keep up with the times.

I can't see them adding H.265. Partly because they themselves are progressively changing their toolset to work with HTML5, and partly because it is heavily patent encumbered.

Another problem with that codec is it is the available encoders are rather difficult to tune correctly such that they were compete well on quality with H.264. This will need further attention to rectify.

>>33480Yeah but I'll be releasing something new soon. Hopefully this week. It won't feature what SwfH264 has to offer initially but I plan to have it eventually replace SwfH264. I'm always open to suggestions or general feedback if you had something in mind.

>>59976Sorry I'm still not ready to open-source... I want to wrap things up with Swiff Army Knife and maybe release the source then if I think it's presentable, although I don't know when I'll be able to do it. I'm willing to answer questions on how I've done stuff in SwfH264 if you have anything specific that you are interested in knowing.