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

[John Koleszar]

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.

Outside of browsers, it works today with mplayer and mencoder. It
works with gstreamer, DirectShow, and QuickTime. The majority of WebM
content is making use of this feature, and I don't know of any reports
of broken players. This is just by relying on VFR and muxing ARFs as
ordinary P-frames. This can be done better, without breaking
compatibility, by using a better timebase and setting the invisible
bit. But unless someone has a solution to the webm compatibility
problem, that issue is orthogonal to defining a packed format for
non-webm containers and should be addressed one at a time, imho.

>> but the rest of this mail is trying to find out
>> what an acceptable implementation of invisible frames in ffmpeg looks
>> like.
>>
[...]

>> 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
>

ok.