exception when encoding h263 FLV files in JFLVTOOL

[icodeflex]

hello-
I have written a swing app using the jflvtool libraries found at http://code.google.com/p/jflvtool/wiki/GettingStarted

It wasn't until today that I tried encoding a h263 encoded flv file- and found the application throws a string out of bounds exception. VP6 FLV files encode without trouble.

It turns out Riva also has this same problem.

Has anyone run into this, and hopefully even fixed the problem? I havent been able to get my head around what the binary data should look like so I can fix. I do know that the line of code in the VideTag.java class looks suspicious, and is what is throwing the error:

int hwCheck = bh.bit2uint(bits.substring(30, 3).toCharArray());

width = findWidth(hwCheck);
height = findHeight(hwCheck);

the substring looks backwards and the index out of range error is because the program is trying to find -27. But then I am still not sure, because is -27 supposed to be translated to something?

Any help is appreciated.- for a link to a fix or even another place to ask questions about this code.

I am running Java 1.5.0_16 and the commons-cli classes the help doc said to use.

thanks!
Dustin

[icodeflex]

Good News!

The author of the JFLVTool code, Jon Keys, was able to post a fix to the problem I was having with encoding H263 FLV files. He has updated the code on Google source: http://code.google.com/p/jflvtool/wiki/GettingStarted.

Thanks Jon!!

This is a great Java based encoder for VP6 and H263 FLV files, and is open source. I used it to build a Swing app.

Jon made some of the following comments, which might be useful for anyone using this code:

The limitation for jFlvTool is the file size - ~2GB is all we can handle. The reason for this is I chose to cast my unsigned integers to an int rather than a long.
You might have noticed that jFlvTool uses quite a bit of memory when dealing with large files - this is because many objects are created to keep track of all the tags.
If you need to deal with files larger than 2GB then you could cast the unsigned integers to longs which have the capacity to hold the entire file size - it will increase the RAM utilization quite a bit though.
I've thought of using an embedded db like H2 to keep track of all this info without using too much RAM, but I'm unsure how it might affect performance.

jFlvTool is faster on some systems because I use NIO to map the byte offsets directly into memory.
If your systems has good NIO support then it should be quite fast.

cheers-
Dustin