- Review and perhaps improve the way frames are given to the user. For now, ByteBuffers are used but they involve a memory copy operation, at least to transfer the contents of the ByteBuffer to a byte array which can be then passed on to other SWING objects for display. It might not be necessary when doing video streaming over the network for instance (I believe it is possible to send the contents of the ByteBuffer to a socket without extra copy, but I have not tested this). Also worth investigating is whether implementing a push model would be useful.
- Add support for MPEG image format: in order to achieve this, libvideo must first be modified to return not just a pointer to the frame buffer, but most of the fields present in the struct v4l2_buffer so as to report timecode, frame type, ... The reason I havent implemented things this way originally, is because MPEG is only available in v4l2, and I wanted to investigate more how to emulate (or fake) these fields that are present in v4l2 but missing in v4l1. However, with a bit more experience now and after making libvideo fake (a lot) of missing things to make it behave like v4l2 in a lot of ways, I believe it shouldnt be too hard to implment.
- Integration with FMJ: FMJ is an open source implementation of the (now dead) JMF (Java Media Framework). FMJ is API-compatible with JMF, so applications written to use JMF can (in theory, not tested) work with FMj without modification. Alexandra has submitted some sample code to quickly create a JMF DataSource out of a v4l4j VideoDevice, but it needs some refactoring.
- Since I am currently deeply involved with DirectShow at work, I cant help but thinking about making v4l4j use DirectShow to capture video streams. Of course, the v4l part in v4l4j wont be too relevant there, but I think a project rename is acceptable if it means supporting addtional platforms.
This is all I can think for now. As always, comments (on the mailing list please) are welcome.
No comments:
Post a Comment