[FFmpeg-devel] [PATCH] libvpx: alt reference frame / lag
Tue Jun 15 21:15:35 CEST 2010
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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel