[FFmpeg-devel] [PATCH] libvpx: alt reference frame / lag

Michael Niedermayer michaelni
Sat Jul 3 04:47:14 CEST 2010


On Fri, Jul 02, 2010 at 03:26:36PM -0400, John Koleszar wrote:
> On Wed, Jun 9, 2010 at 8:27 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Jun 09, 2010 at 12:08:59PM -0400, James Zern wrote:
> >> On Tue, Jun 8, 2010 at 22:19, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > this looks and sounds wrong
> >> > the way divx/xvid packed b frames are handled is much saner
> >> >
> >> I'll have to have a closer look at that. From what I remember, these
> >> were flagged within the container with each frame having a new header
> >> to allow the frames to be broken up by the decoder correct?
> >
> > the primarely relevant part is that it does not have more frames at container
> > level than there are output by the decoder.
> > having the number of frames input in the decoder differ from the output could
> > cause some problems. Similarly for the encoder. Its likely not unsolveable
> > if its neccessary but as this is not common it likely would break a few
> > applications.
> > besides strictly speaking, frames that are not presented to the user have no
> > presentation time
> >
> 
> In hopes of starting to write some code to move this discussion
> forward, I think there are two basic issues we've been talking about:
> packed ARFs and what to do about the timestamps.
> 

> Regarding packed vs non-packed ARFs, I don't think there's any way to
> introduce a packed format at the codec level without breaking
> backwards compatibility. If someone does have an idea on how to do so
> we can go that route, 

someone could just fork libvpx and change it to pack frames.
if someone did that, chances are most of the community would prefer that lib
as it would work with existing players


> but the rest of this mail is trying to find out
> what an acceptable implementation of invisible frames in ffmpeg looks
> like.
> 
> For the question about what to do with the pts, the closest thing to
> the current implementation would be to create a pts between frames if

thats not possible. A not displayed frame has no presentation timestamp
i dont think any maintainer would approve a patch encoding such things
if there was any other option
on the decoder/demuxer/player side such pts likely would be implemented in the
form of some

lots of ugly code to parse headers
if(this frame is arf){
    pkt->pts= PTS_UNAVAILABLE
    pkt->flags= ARF
}

mixed with variing amounts of polite words in comments


[...]
> Another option would be to reuse the timestamp, or set it to something
> like AV_NOPTS_VALUE, and relax the check that forces timestamps to be
> strictly increasing.

that is closer to possible

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100703/aaec0e85/attachment.pgp>



More information about the ffmpeg-devel mailing list