[Libav-user] Custom IO callbacks

[Reuben Scratton]

Hi,


I am writing an FFMpeg-based Android app which can play H264/AAC content
over plain old HTTP.

As well as playing the content, the app also needs to cache it
intelligently (and securely), which means the Java application layer needs
control over the stream of bytes that goes in to the FFMpeg decoder. Simply
passing a URL through to FFMpeg for it to open the stream natively isn't
enough.

So I've been using ByteIOContext with custom IO callbacks, as documented in
a blog post at
http://cdry.wordpress.com/2009/09/09/using-custom-io-callbacks-with-ffmpeg/.

It seems that it should be straightforward, but I am getting mixed results.
If I open a stream from the start, it works fine. If I try to seek, it goes
a bit nuts... the decoder calls the 'seek' callback with SEEK_SET and an
offset pretty near the end of the file/stream. Even if I've only scrubbed
forwards a few seconds, say, in the stream, the decoder wants to leap all
the way to the end. Is that to be expected? Or does it maybe indicate
something's gone wrong with the streaming?

Second question: what does ByteIOContext.is_streamed actually denote? If I
*don't* set this to 1, the decoder seeks all over the shop before settling
in to play the video. If I set it to 1 it more or less behaves itself. But
I wonder if I sufficiently understand the implications of this flag? In
what circumstances would this ever need to be 0? Isn't the streamed nature
of the data implicit with the whole API?

Thirdly, when I probe the first 4K of the stream, the long name is returned
as "QuickTime/MPEG-4/Motion JPEG 2000 format". But a tiny bit later in the
diagnostic trace, right after the first read(), I see the following message
(which seems to originate in mov.c):

I/ffmpeg(31276): ISO: File Type Major Brand: ┤iªE
I/ffmpeg(31276): st:1168533572 removing common factor -2139027635 from
timebase
I/ffmpeg(31276): st:1168533572 removing common factor -2139027635 from
timebase

This worries me... as far as I can tell the File Type Major Brand should be
a human-readable string, but I'm getting garbage. The video plays okay, so
I've ignored it thus far, but I wonder if it isn't symptomatic of some
hideous underlying problem. And those timebase lines look a little
worrying. Should those be expected?

Fourthly, if anyone's done this sort of thing before it'd be good to hear
from them! If I get this project completed to a robust & satisfactory
state, it'll be open-sourced as a hopefully useful reference for others
wanting to use FFMpeg in the Java world.

Many thanks,


Reuben Scratton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20111029/76985c1b/attachment.html>