Hi,<div><br></div><div><br></div><div>I am writing an FFMpeg-based Android app which can play H264/AAC content over plain old HTTP.</div><div><br></div><div>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.</div>
<div><br></div><div>So I've been using ByteIOContext with custom IO callbacks, as documented in a blog post at <a href="http://cdry.wordpress.com/2009/09/09/using-custom-io-callbacks-with-ffmpeg/">http://cdry.wordpress.com/2009/09/09/using-custom-io-callbacks-with-ffmpeg/</a>.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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?</div>
<div><br></div><div>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):</div>
<div><br></div><div><div>I/ffmpeg(31276): ISO: File Type Major Brand: ┤iªE</div><div>I/ffmpeg(31276): st:1168533572 removing common factor -2139027635 from timebase</div><div>I/ffmpeg(31276): st:1168533572 removing common factor -2139027635 from timebase</div>
</div><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Many thanks,</div><div><br></div><div><br></div><div>Reuben Scratton</div>