search

artclarke / humble-video

Humble Video: Demuxing, Decoding, Filtering, Encoding and Muxing of 100's of video and audio formats and Codecs from the JVM
GNU Affero General Public License v3.0
563 stars 115 forks source link

Javadoc is misleading for MediaPicture#toPicture #84

Open rkosegi opened 9 years ago

rkosegi commented 9 years ago

Timestamp parameter of method MediaPicture#toPicture is described in javadoc as:

timestamp the time stamp which should be attached to the the video picture (in microseconds).

However, in following sample, no conversion to microseconds is done: https://github.com/artclarke/humble-video/blob/master/humble-video-demos/src/main/java/io/humble/video/demos/RecordAndEncodeVideo.java#L162

In my program, if I set its value to microseconds, video if completely invalid.

McPringle commented 3 years ago

Yes, you are right. Since a few hours I try to figure out what I have to pass here. It is not microseconds, it is not milliseconds, it is not a duration for the frame. Were you able to figure out what to pass here?

rkosegi commented 3 years ago

Yes, you are right. Since a few hours I try to figure out what I have to pass here. It is not microseconds, it is not milliseconds, it is not a duration for the frame. Were you able to figure out what to pass here?

It was long time ago, but I've found that it worked when I passed following:

long timestamp = fps * (System.currentTimeMillis() - start) / 1000;

Value of fps is 25 in my case and start value was initialized to System.currentTimeMillis() when I opened stream.

McPringle commented 3 years ago

@rkosegi, thank you very much for your fast response. I guess you are recording in realtime, e.g. from a screen (like in the example) or a camera. In that case, System.currentTimeMillis() - start is equal to the position in the resulting video in milliseconds:

long timestamp = fps * videoPositionInMillis / 1000;

As a result of this calculation with fps and 1000, the variable timestamp will held the number of the frame. In my case, where the frames come in order, this can be a counter and increase by every call:

converter.toPicture(picture, image, frame++);

Now I got a video with 0.0333333... fps. Looks like I had another error in calculating a rational number from my (integer) fps. After some research about rational numbers, nominators, and denominators, I got it to work! Why the heck do they require to specify the fps using nominators and denominators?

The result of my tests: The third parameter of converter.toPicture is just a counter! A working example is GPX Animator. The implementation is on the branch issue-321-humble because Humble is much slower than Xuggler (test video 208 s Humble vs. 116 s Xuggler). So we don't want to go into production with Humble and stay with Xuggler. Both solutions use FFmpeg under the hood. Thus, the cause of the slowness probably lies in the Humble code.