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

[Michael Niedermayer]

On Tue, Jun 15, 2010 at 05:09:49PM -0400, John Koleszar wrote:
> 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:
[...]
> >> 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.

whats missing for AAC in LATM is someone with time and will to implement
it cleanly


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

no, nut does not allow it.
It would not be a big issue to make nut support it (we just need to add
a flag to mark such frames and code to adapt the timestamp handling)


> and there's a mapping defined for ogg.

given the amount of trouble everyone had just getting anything simple in
ogg working and given the amount of ambiguity and difference between
spec and implementation in ogg, i doubt that this will work out smoothly


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

it requires a container supporting frames that have a dts but not a pts
iam not aware of such containers but i did not check any thats just from
memory ...
As said for nut its a matter of a new flag. for other containers outside
our control this would not be that easy.
What you write above is a description of a hack not of clean support.
because these frames do not have a pts, they are not presented, without
marking them it will mess up our timestamp handling. and i think it would
also mess up mplayers timestamp handling, at least mplayer had its share
of issues with h264 PAFF due to decoder input and output not matching.
Also just think of a player that passes a frame with dts=5 to a decoder
prior to vp8 arf the player could have expected that the decoder would
return a decoded frame with pts=5 for this but with arf it could output
nothing. This has its potential to break players, iam not saying it will
iam saying it could

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20100616/289d52d9/attachment.pgp>