[FFmpeg-devel] [PATCH] Add RTP hinting to the mov muxer

[Martin Storsjö]

On Mon, 3 May 2010, Martin Storsj? wrote:

> On Mon, 26 Apr 2010, Martin Storsj? wrote:
> 
> > On Thu, 22 Apr 2010, Martin Storsj? wrote:
> > 
> > > On Thu, 22 Apr 2010, Baptiste Coudurier wrote:
> > > 
> > > > Well, can you please merge the patches related to the muxer ?
> > > > It's hard for me to review all the separated changes.
> > > 
> > > Ok, merged most of patches that add new functionality.
> > > 
> > > > Also I find MKTAG('a','b','c','d') without the spaces between the ','
> > > > easier to read.
> > > 
> > > Done. Or do you want me to use AV_RL32("abcd") in the places where 
> > > feasible, even though it's a little less consistent with the rest of the 
> > > file?
> > > 
> > > > The tref atom function should be mov_write_tref_tag, MOVTrack should contain
> > > > tref_id and tref_tag to make it generic because it is used for chapters as
> > > > well.
> > > 
> > > Done - these patches now are written on top of David's patches for writing 
> > > qt chapters (that still are pending re-review iirc)?
> > > 
> > > > Also the code writing stss atom should be generic, ie not dependent of the
> > > > source track being a video track. Either the track has keyframes or only
> > > > keyframes, the current code should behave correctly and the condition should
> > > > be basically: tag == "rtp " || codec == VIDEO
> > > 
> > > Fixed.
> > > 
> > > > Also the hint_track and src_track fields confuses me, either it is an index or
> > > > a track, but I'm tired atm ;)
> > > 
> > > Fixed, both are indices now.
> > > 
> > > > Finally, do use av_new_stream for the hint tracks, add them internally, this
> > > > will have side effects on the interleaving when muxing.
> > > 
> > > I guess you meant "do not use" here. Fixed, by creating only a new 
> > > internal MOVTrack, just like the qt chapters patch does, without any 
> > > corresponding AVStream.
> > 
> > Here's an updated series, compared to previous version, there's only some 
> > minor changes to part 5, for unwrapping 32-bit RTP timestamps into linear 
> > 64-bit pts/dts fields.
> 
> Ping - any objections to applying this (once the mov/qt chapters stuff is 
> committed), given that Luca and Michael have ok'd it and I've addressed 
> Baptiste's comments?

Ping2

Any update on when you can have another look at this? This is soon a month 
old...

// Martin