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

[John Koleszar]

On Tue, Jun 15, 2010 at 3:15 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jun 15, 2010 at 12:18:29PM -0400, John Koleszar wrote:
> [...]
>> Framing aside, I don't think it makes sense to combine the two packets
>> because they can be semantically different. One of the two could be
>> droppable, for example.
>
> a redundant slice is also dropable in h264, so are SEIs
> yet they are part of the same access unit and required to be so per spec
> if iam not mistaken
>

ARFs are a separate access unit. The frame preceding an ARF doesn't
refer to the data in the ARF, and the frame following doesn't
necessarily refer to it either, though it may. ARFs aren't droppable,
or at least it'd be pointless to code a droppable one. It is a useful
entity for applications that are aware of it, though these
applications would be more exotic than basic playback.

>
>> Many applications want to treat these packets
>> independently (consider streaming, video conferencing). One example
>> might be to apply different error correction to the two packets. On
>
> I also might want to apply different error correction to parts of a h264
> or mpeg4 asp bitstream that uses data partitioning. Same for progressive jpeg
> or jpeg2000
>
> in a world where nothing but vp8 exists your arguments would make sense
> of course but thats not the way things are.
>
>

I was trying to underline the separable nature of the two frames. I've
never assumed a vp8-only world.


>> the decode side, it's useful for the application to be able to do work
>> between decoding the two packets.
>
> What actually is the advantage of these frames compared to B frames with
> normal reordering?
>

http://webmproject.blogspot.com/2010/05/inside-webm-technology-vp8-alternate.html

>
>> Stream copy shouldn't be any problem
>> as long as both transports don't make an assumption about the frame
>> being shown. You could support it with other containers with a
>> bitstream filter arrangement that knows how to split/combine packets.
>
> We also could finally get AAC in LATM working properly
> if its so easy, please send a patch, alot of people would be very happy
> if someone did.
>

I don't know what bitstream filters in ffmpeg can do, or what it is
that you're implying they're missing. I was just outlining one way
people could put vp8 into a container that doesn't support these
frames.

>
>> I'm not sure this how much value there is in trying to support these
>> more restrictive containers/transports. It's interesting in the
>> academic sense, but how practical is it?
>
> in which container besides mkv does it work?
>

Should be possible in nut, and there's a mapping defined for ogg.
Might need the additional constraint of never following a KF with an
ARF for some cases, which we could add. Should basically work in any
variable frame rate container that supports either monotonically (not
strictly) increasing timestamps or uses a timebase of higher
resolution than the frame rate.