[Libav-user] Switching codecs from encode to playback on the fly
Alex Cohn
alexcohn at netvision.net.il
Mon May 7 12:05:45 CEST 2012
On Mon, May 7, 2012 at 7:09 AM, Bruce Wheaton <bruce at spearmorgan.com> wrote:
> On May 6, 2012, at 12:36 PM, Alex Cohn wrote:
>
>> Good question. The intent is to seamlessly move from ingesting a movie and
>> viewing it to playing back. I can't find a way to access the same movie for
>> playback as it's being ingested (that would work fine too), can't tell which
>> media container might support that even. So my workaround was to get frames,
>> cache them for playback and record at the same time.
>>
>> I was hoping to use all the same structures to minimize the interruption
>> as I switch between modes. It was more the time to set up the new structures
>> - opening the movie file etc. that was a pain, and having to have a double
>> set of structures that will bloat my playback code.
>>
>> Bruce
>
> Can you describe your intended usage in some kind of very high level
> pseudocode?
>
> Umm, I think so:
>
> Open movie for encode and playback (or stream)
>
> for each source movie frame {
> pass to display function
> encode and pass to movie for saving
>
> if (lastFrame) {
> finalizeMovie
> switch to playback mode
> }
> } while !lastFrame
>
> for each frame on disk (allowing seek and shuttle now) {
> pass to display function
> }
>
> Sorta.
>
> It's that changeover, and making it quick and clean I'm wondering about.
> Whether I should just treat it, from an ffmpeg point of view, as a
> completely separate step. Since all the movie details are already know in
> the encoding, I was wondering if I could use that.
>
> Bruce
Unfortunately, AVFormatContext Struct Reference
[http://ffmpeg.org/doxygen/trunk/structAVFormatContext.html] says
explicitly that this object can only be iformat or oformat, not both
at the same time.
As for AVStream, there is no explicit prohibition, but this structure
is not populated by user during demuxing/decoding, thus you will gain
nothing if you attempt to reuse it (the decoder will rebuild it
anyway).
BR,
Alex
More information about the Libav-user
mailing list