Re: [Opensvcdecoder-support] Usage of OSVC -- getting every last frame

[Brett S. <bre...@gm...>]

I apologize for the long email. I'm not very good at explaining
details like this clearly in a quick way. Thank you for taking the
time to read it and to reply. You saved me a lot of time by preventing
me from continuing to try to figure out what I was doing wrong, and I
was able to work around it fairly easily by saving the first access
unit and first decoded frame, and continuing to pass the first Au to
the library until it produced the first frame, in order to flush out
whatever is internally buffered.

On Sat, Apr 21, 2012 at 12:48 PM, Mickaël Raulet
<Mic...@in...> wrote:
> Your email is long but at least clear. The way the decoder is working is like a FIFO there is no way to get this picture back except by sending more pictures to the decoder to get this picture back.
>
> You need to get one to get one more picture. Sorry this is the current behaviour of the decoder.
> Mickaël
>
> Le 21 avr. 2012 à 16:53, Brett Slote a écrit :
>
>> Hello,
>>
>> OpenSVC is working well for me, but I have a question about one detail
>> of the usage:
>>
>> Say my video is encoded with only one layer with the GOP structure
>> IbBbPbBbPbBb I... and 32 frames.
>>
>> The access units will arrive from the encoder / be in the file in the
>> encoding order of IPBbb...
>>
>> So I pass the first I frame (access unit) to the decoder, and the
>> library returns that it has produced a picture, and I can write the
>> first frame to a .YUV file, great.
>>
>> But then, 2nd frame in display order is a b frame. Of course that
>> can't be decoded and written to file, first the P and B frames on
>> which it may depend must be decoded. So the P frame (access unit), as
>> the next frame in the file/bitstream, is passed to the Decoder. Of
>> course the library indicates that it does not have a picture ready,
>> since frame 2 has not yet been received.
>>
>> Several more frames are passed to the decoder, without a picture being
>> returned, as expected. After a few frames, say once the P and B frames
>> have been passed, and the next b frame is passed, the library
>> indicates that a picture is ready, and we can now write the 2nd frame.
>> Each frame after that returns a picture, as enough is buffered
>> internally (perhaps my understanding of how this works is completely
>> wrong...).
>>
>> So everything is great, the first 26 or so frames in the decoded yuv
>> match the reference yuv from the encoder perfectly.
>>
>> But then we reach the end of the file/bitstream. There are still 6 or
>> so frames at the end of the reference .yuv file. But there are no more
>> frames left in the .264 to pass to the library. It seems that the
>> internal buffering for dependant pictures leaves the last few frames
>> internally buffered with no way to get them out.
>>
>> It seems that the return of the library is a list of .yuv pictures,
>> however, the size of that list is always 1. It would make sense if
>> that list were bigger, returning all the buffered frames at the end of
>> the video. However, the only way to tell the library that it is the
>> end seems to be to call SVCDEcoder_close, but that doesn't produce the
>> last frames.
>>
>> Even if my GOP structure is IPPPP.... it seems to produce the same
>> results, which is strange since I would expect the library to be able
>> to return a picture for every frame in that case.
>>
>> Is there a way to use the library to produce every last frame from the
>> .264 file, and I am just using it wrong? Or are a few frames always
>> lost to internal buffering? I don't see what I am doing differently
>> than MPlayer, but there is probably something I am doing wrong. It is
>> quite important to me that I be able to decode every frame, so any
>> help with this last detail would be greatly appreciated.
>>
>> Thank you,
>>
>> Brett Slote
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Opensvcdecoder-support mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensvcdecoder-support
>