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

[Michael Niedermayer]

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


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


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


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/20100615/e78ba0b6/attachment.pgp>