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

John Koleszar jkoleszar
Mon Jul 5 16:50:13 CEST 2010


On Mon, Jul 5, 2010 at 10:27 AM, John Koleszar <jkoleszar at google.com> wrote:
> On Fri, Jul 2, 2010 at 10:47 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> 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
>>
>
> As I've said n-times, I'm not opposed to defining a packed frame
> format, or supporting it in libvpx. I'm saying that I see no way to
> use such a format in a WebM file in a backwards compatible way. If we
> define a packed frame format, and YouTube remuxes all of its WebM
> content overnight, or even just enables it for new content, the end
> result would be that everyone playing WebM today would be unable to do
> so tomorrow. This is unreasonable. Unpacked frames *is* what works
> with existing players.
>

Just to be clear, I mean putting packed ARFs into webm files without
any other changes, ie the packed arfs reaching the current players'
decoders as-is, causing corruption. Any solution that avoids that
would be worth considering, its corrupting the video for otherwise
working players that's unreasonable.



More information about the ffmpeg-devel mailing list