We Keep Coding

I get a non playable MP4 file when created with Mp4Parser Java API

I'm studying Mp4Parser API (Mp4Parser GitHub) and try to learn how it's working. I first tried to create an MP4 by "copying" the highest level tags into a new file.
If I get a similar file, it's unfortunately not "the same file" and result can't be played.
My dirty (it's just a quick try) code is:
public void copy(String videoFilePath) throws IOException {
File videoFile = new File(videoFilePath);
File videoPro2 = new File("/tmp/output.mp4");
if (videoPro2.exists())
videoPro2.delete();
videoPro2.createNewFile();
FileOutputStream fos = new FileOutputStream(videoPro2);
IsoFile isoFile = new IsoFile(new FileInputStream(videoFilePath).getChannel());
IsoFile pro2 = new IsoFile(new FileInputStream(videoPro2).getChannel());
ByteArrayOutputStream baos = new ByteArrayOutputStream();
pro2.addBox(Path.getPath(isoFile, "ftyp[0]"));
pro2.addBox(Path.getPath(isoFile, "free[0]"));
pro2.addBox(Path.getPath(isoFile, "moov[0]"));
pro2.addBox(Path.getPath(isoFile, "mdat[0]"));
pro2.getBox(Channels.newChannel(baos));
baos.writeTo(fos);
isoFile.close();
pro2.close();
baos.close();
return;
}
I tested my original MP4 with AtomicParsley, saw there were in that order, a ftyp, a free, a moov and an mdat tags.
My method basically aims to get these four tags and puts them into the destination file to "make an exact copy". Or that's what I was expecting, but it's not the case.
Firstly, output.mp4 is not playable, but comparing the hex dumps of input and output... almost everything is different, except ftyp and free. Why?
I can see that tag size are not similar neither..
Obviously, my goal is not to "copy" files, but understand Mp4Parser API as I'd like to use it in a real project. But this copy method is a starter for me to understand how this works, as I'm not familiar with MP4 specification.
Thanks

Ok, my fault.
There was an UUID tag I missed in the original footage between moov and mdat tags. Copying the UUID tag using
pro2.addBox(Path.getPath(isoFile, "uuid[0]"));
just before adding the mdat atom does the trick.
Sorry for this :)

Java: FileOutputStream and FileInputStream together on the same file

Do I can open a file (linux character device) for read+write, and use the two classes to implement a dialog like client-server?
Something like this:
File file = new File("/dev/ttyS0");
FileOutpuStream fo = new FileOutputStream(file)
FileInputStream fi = new FileInputStream(file)
After the above declarations, can I continuously send pollings (questions) to the file, and read its replies? (Of course, attached to ttyS0 there is a kind of server)

I was not able to test it, but you might want to give RandomAccessFile a try.
It does not give you the opertunity to create streams, but it implements DataInput and DataOutput. Thats maybe good enough for your purpose?
RandomAccessFile docs
String file = "/dev/ttyS0";
try {
RandomAccessFile f = new RandomAccessFile(file, "rwd");
} catch (IOException e){
e.printStackTrace();
}

The /dev/ttyS0 file is a device file for a serial terminal.
If the device has been configured appropriately to connect to a serial terminal line, then you should be able to read and write like that. However, on a typical desktop or laptop, it probably won't work because there won't be connected serial line.
(For example, when I do this on my PC:
$ sudo bash -c "cat < /dev/ttyS0"
I get this:
cat: -: Input/output error
which is saying that the device cannot be read from.)
Note that a /dev/tty* device does not behave like a regular file. The characters that are written in no way relate to the characters that you read back. Also note that it is not possible to make ioctl requests using the standard Java APIs. So configuring the terminal driver from Java would be problematic.
If you were talking abour reading and writing a regular file, it should work too. However, the behavior could be a rather confusing, especially if you have buffering in your streams. One issue you need to deal with is that the two file descriptors are independent of each other.
If you need to do this kind of thing with a regular file, you should probably use RandomAccessFile.

I didn't try RandomAccessFile, it could also work... it worked smoothly with FileInputStream and FileOutputStream, see this answer in SO: https://stackoverflow.com/a/56935267/7332147

Storing a file as part of android manifest for deployment and then opening it?

Okay I know this should be dead simple but I guess I'm not phrasing my question correctly in my Google & stackoverflow searches.
I have a substantial amount of static data (6 megs) I need to load into my database upon install. Right now I'm fetching a json data file from my web server on first run and populating my database but that can be slow and something could go wrong. I'd prefer to just include the data file in the manifest and then load it on install or first run.
So, where do I put the file, make it so that it ends up on the target device, and then open it?
I've tried putting it in /res/files/ and then doing:
InputStream inputStream = new FileInputStream("/res/files/foo.json");
but of course I'd have been shocked if that had worked.
While I'm at it I should probably use CSV format instead as that would cut down the size but that's another story, I don't seem to have a way to parse it but I do know how to parse JSON data. Sorry I'm a bit new at this. Thanks!

You could store it either in assets or in res\raw.
How to open it from the assets folder:
InputStream is = getAssets().open("foo.json");
How to open it from the res\raw folder:
getResources().openRawResource(R.raw.foo);

I would advise you to use SQLite and/or XML. What #Gabriel suggested will most likely work fine, but loading and processing 6MBs may take some time -a time window of 1 to 5 secs to my experience. Since you downloaded from your webserver I believe your data has some form of structure and in your app you won't need all of the data at once.
Here are some guides/tutorials about SQLite in android, keep in mind that XML is also viable and some will probably advocate XML over SQLite in this case.
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html
http://www.vogella.com/tutorials/AndroidSQLite/article.html

You can put your JSON file in the raw folder (res/raw) and load it with this code :
InputStream inputStream = getResources().openRawResource(R.raw.foo);
BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
StringBuilder sb = new StringBuilder();
String line = null;
while ((line = reader.readLine()) != null) {
sb.append(line + "\n");
}
inputStream.close();
JSONArray jArray = new JSONArray(sb.toString());
Then you can use your knowledge to parse the JSONArray.

Java- using an InputStream as a File

I'm trying to generate a PDF document from an uploaded ".docx" file using JODConverter.
The call to the method that generates the PDF is something like this :
File inputFile = new File("document.doc");
File outputFile = new File("document.pdf");
// connect to an OpenOffice.org instance running on port 8100
OpenOfficeConnection connection = new SocketOpenOfficeConnection(8100);
connection.connect();
// convert
DocumentConverter converter = new OpenOfficeDocumentConverter(connection);
converter.convert(inputFile, outputFile);
// close the connection
connection.disconnect();
I'm using apache commons FileUpload to handle uploading the docx file, from which I can get an InputStream object. I'm aware that Java.io.File is just an abstract reference to a file in the system.
I want to avoid the disk write (saving the InputStream to disk) and the disk read (reading the saved file in JODConverter).
Is there any way I can get a File object refering to an input stream? just any other way to avoid disk IO will also do!
EDIT: I don't care if this will end up using a lot of system memory. The application is going to be hosted on a LAN with very little to zero number of parallel users.

File-based conversions are faster than stream-based ones (provided by StreamOpenOfficeDocumentConverter) but they require the OpenOffice.org service to be running locally and have the correct permissions to the files.
Try the doc to avoid disk writting:
convert(java.io.InputStream inputStream, DocumentFormat inputFormat, java.io.OutputStream outputStream, DocumentFormat outputFormat)

There is no way to do it and make the code solid. For one, the .convert() method only takes two Files as arguments.
So, this would mean you'd have to extend File, which is possible in theory, but very fragile, as you are required to delve into the library code, which can change at any time and make your extended class non functional.
(well, there is a way to avoid disk writes if you use a RAM-backed filesystem and read/write from that filesystem, of course)

Chances are that commons fileupload has written the upload to the filesystem anyhow.
Check if your FileItem is an instance of DiskFileItem. If this is the case the write implementation of DiskFileItem willl try to move the file to the file object you pass. You are not causing any extra disk io then since the write already happened.

SWT Browser widget: html source inside jar?

I want to implement a help system for my tiny SWT desktop application.
I've thought about a SWT browser widget containing a single html markup page and a set of anchors to navigate (there are only very few things to explain).
Everything works fine, but how do I load the html file from a jar?
I know aboutgetClass().getClassLoader().getResourceAsStream("foo");, but what is the best practice when reading from the input stream? The answer to Load a resource contained in a jar dissuades using a FileInputStream.
Thanks in advance

Well, I found a rather simple solution that obviously just works:
InputStream in = getClass().getClassLoader().getResourceAsStream("html/index.html");
Scanner scanner = new Scanner(in);
StringBuffer buffer = new StringBuffer();
while(scanner.hasNextLine()) {
buffer.append(scanner.nextLine());
}
browser.setText(buffer.toString());

i tend to use commons-io for such a task giving me simple abstraction methods like IOUtils.toString(InputStream in); and leaving the choice of best implementations to the able people at apache ;)
commons-io: http://commons.apache.org/io/
apidocs: http://commons.apache.org/io/api-release/index.html