[FFmpeg-devel] LATM BitStreamFilter

[Paul Kendall]

On Friday 01 May 2009 01:35:25 pm Michael Niedermayer wrote:
> On Fri, May 01, 2009 at 01:31:31AM +0100, Robert Swain wrote:
> > Michael Niedermayer wrote:
> >> On Wed, Apr 29, 2009 at 08:21:06PM +1200, Paul Kendall wrote:
> >>> Can I ask why LATM is preferred as a bit stream filter rather than
> >>> as a decoder, or built into the AAC decoder, as ADTS is?
> >>
> >> A simple use case
> >> you have a demuxer that outputs AAC in LATM, and a muxer that doesnt
> >> allow LATM.
> >> Only a bitstream filter can fix this up in the current architecture
> >> unless you want to change it to allow multiple demuxers to be chained,
> >> in which case you could implement it as a demuxer too.
> >
> > This may be an idea.
> >
> > I think Paul was asking if the bitstream filters could only be inserted
> > after encoding/before multiplexing and not after demultiplexing/before
> > decoding which is where it is needed.
>
> ffmpeg.c can be changed to insert them after demux too

Ok, I think I'll create a patch for this first then. I assume that leaving 
-absf as they are for backward compatibility is a requirement, so I should 
add -aibsf and perhaps -aobsf and the v & s versions as well.

>
>
> [...]
>
> >> you seem fixed on only the goal of decoding, this is not good, we need
> >> to be able to remove as well as add LATM surrounding AAC.
> >
I want to get it right! LATM for decoding is import as it gets a whole lot of
people working with ffmpeg in DVB-T situations.

I (or someone else) could then continue on to use LATM for encoding streams.
As a bit stream filter, or whatever is deemed to be the correct way.

> > The vast vast majority of people outside of DVB stream broadcasting do
> > not need to add LATM. At least, I'm not aware of any other applications
> > using LATM at the moment.
>
> so you have no plans to build a pirate dvb transmitter ;)
>
Not me, thats for sure! :-)

> >> If the remuxng case with LATM removial as well as keeping LATM doesnt
> >> work that would be reason to reject a patch.
> >
> > I think different parts should be considered separately. That is, I think
> > patches adding removal of LATM, addition of LATM or copying LATM should
> > be considered separately and the lack of any should not hold up inclusion
> > of any other as they're completely separate situations.
>
> of course, but if someone submitted a patch that contained a bitstream
> filter to remove it but it then worked only for decoding and not remuxing
> that would be a reason to reject (thats really what ive meant)
>
So you want the bit stream filter to work either direction? If this is the case
then I think the API needs 2 methods, input_filter and output_filter or some
such!

>
> [...]

Thanks for the discussion on this topic as I do really want this to get done.

Cheers,
Paul