Closed ufdada closed 9 years ago
ufdada
commented
9 years ago Got it synced :)
@echo off
set movies=.\Movies\
set output=.\ConvertedMovies\
mkdir %output%
for /f "delims=|" %%f in ('dir /b %movies%') do (
ffmpeg -i %movies%%%f -vsync 1 -r 25 -itsoffset 4.2 -i %movies%%%f -map 1:0 -map 0:1 -vf scale=iw*2:ih -y %output%%%~nf.mp4
)
tonihele
commented
9 years ago Great! I have also thought about getting those even though my brain says the game is more important. But with the videos it looks like a ready game then.. It is all about the image...
I don't think they should be literally converted. Since converting a lossy format (20 year old) to another lossy format = pixels the size of an entire galaxy. And to a lossless, just a waste of space since and, well, the pixels :)
JME is currently lacking video playback. The most prominent workaround was to use animated texture but then we are the ones responsible with the audio sync also, maybe too hard... Or extending JAVA FX..? Not sure is it easy or not. With JAVA 8 in the future it could be done, maybe.
With libav/ffmpeg I think they can be embedded to the application, the compiled versions for every OS (though, now cross-platform support is not a super priority, it is nice and we should not intentionally use something that breaks it in the code). I think this is a widely used method. I think CorsixTH also uses this..? Should we do it like this? I don't know how to pack them or what the license says... But most feasible approach?
What do you think? Or did you have something on your mind with the MP4s? And how big they are compared to the originals, and the quality?
ufdada
commented
9 years ago Well i was just curious if it works or makes any big problems (and then not be worth enough to be converted into java). I also think the animated texture would probably be the best choice, even if we have to sync the audio by ourself.
The quality is surprisingly well (didn´t saw any great drawbacks) and the file sizes are a lot smaller (didn´t expect that!) on the converted movies.
Just for comparision:
tonihele
commented
9 years ago Heh that size is probably 20 years of progress in audio/video encoding. If we choose not to include libav/ffmpeg, which I think is a good choice also (many projects do it). Then we are bound to convert TGQ decoder to JAVA anyway. Wherever we may use the video JAVA FX, animated texture or some other means (https://github.com/jcodec/jcodec.. https://github.com/caprica/vlcj...). Shouldn't be too difficult. I think the playing is more difficult than the decoding.
tonihele
commented
9 years ago Yeah, I'd try to write the decoders by ourselves. It doesn't look that complicated. The resolution is quite low and everything, so even if we don't manage to write the most efficient decoder. We'll be okay.
BullfrogIntro is easiest to start with. 189 frames 320x480. Equal amount of the audio frames.
tonihele
commented
9 years ago tonihele
commented
9 years ago http://hub.jmonkeyengine.org/t/ive-made-a-movieappstate-so-you-dont-have-to/31673
The problem with JAVA FX is that it is not expandable in terms of video codecs. But nevertheless this code could be used once our decoder is done :)
tonihele
commented
9 years ago I'm gonna go ahead and try to write a decoder. I really think it is the easiest and the lightest solution. But also maybe way beyond my skills :)
tonihele
commented
9 years ago I don't know how retarded this stunt actually is :) But we now have a working audio stream. No picture yet. A personal victory still :)
tonihele
commented
9 years ago 
tonihele
commented
9 years ago The RGB conversion (the image) is just for debugging and is not very sophisticated. The idea is to use the GPU to convert them (the movieappstate dudes have already done this). There might still be something wrong with the YUV values as well. Not 100% checked.
tonihele
commented
9 years ago https://youtu.be/LjDZ7aY8-O4. A bit artifacts still.
ufdada
commented
9 years ago Wow, great :). Looks like these artifacts look better than before, isn't it?
tonihele
commented
9 years ago They are the same if you are referring to the image versions. Kinda. The shader just does better job converting the colors. Little touch ups here and there. Not easy though... On 21 Apr 2015 20:27, "ufdada" notifications@github.com wrote:
Wow, great :). Looks like these artifacts look better than before, isn't it?
— Reply to this email directly or view it on GitHub https://github.com/tonihele/OpenKeeper/issues/31#issuecomment-94879782.
tonihele
commented
9 years ago Nailed it!!! Got rid of the artifacts! Still some optimizations to do, should be easy as I now know the types of data I need out and I can see immediately if I f* things up. The only real problem is playing the video with audio.
The audio is correct, that I know for a fact, I have played it many times. But I think I need to play it through OpenAL, bypass JME, and sync the video to the audio. Still, I managed to come this far, which is amazing, to me :) I hate bits & math, I can't understand them.
tonihele
commented
9 years ago Ok, the audio is working and synced. The video is synced on the audio that is. Audio is played through JAVA audio, which is much simpler than the OpenAL. JME is used only on the logical states and hardware accelerate the videos (RGB conversion).
There are still some white/grayish pixels visible, they are especially visible on the Bullfrog Intro. The intro sequence is hooked to the Main now. And -nomovies flag can be used to skip the movies.
What amazes me the most is that the specs say that the videos are 15 FPS. But with 25 FPS everything seems to be in sync. So 25 FPS it is...
Still TODO:
Getting close for merging...
Even though it´s on low priority, it shouldn´t be too hard to convert them since libav/ffmpeg already have an implementation in C (in libav it´s called eatgq).
I already tried it to convert them with ffmpeg which works, but video/audio are not synced...