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

[Mickaël R. <Mic...@in...>]

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