Art Clarke | 1 May 02:19 2009

Re: Add Xuggler to FFmpeg-based projects?

On Thu, Apr 30, 2009 at 10:18 AM, Robert Swain <robert.swain <at> gmail.com>wrote:

> Done. :)
>
>
Thanks Rob.
Robert Swain | 1 May 02:31 2009
Picon

Re: LATM BitStreamFilter

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.

> Now if LATM supports multiple AAC streams and this would be actually used in
> practice then implementing it as a demuxer would be needed as a bitstream
> filter cannot have more than 1 stream as output.

It seems all instances in the wild at the moment use only one AAC stream 
per LATM stream. Is that right Paul?

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

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 
(Continue reading)

Michael Niedermayer | 1 May 03:35 2009
Picon
Picon

Re: LATM BitStreamFilter

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

[...]
>> 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.
>
> 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 ;)

(Continue reading)

Paul Kendall | 1 May 07:09 2009
Picon

Re: LATM BitStreamFilter

On Friday 01 May 2009 12:31:31 pm 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.

Yes this is what is need ed for this case.

>
> > Now if LATM supports multiple AAC streams and this would be actually used
> > in practice then implementing it as a demuxer would be needed as a
> > bitstream filter cannot have more than 1 stream as output.
>
> It seems all instances in the wild at the moment use only one AAC stream
> per LATM stream. Is that right Paul?

Correct.
(Continue reading)

Paul Kendall | 1 May 07:22 2009
Picon

Re: LATM BitStreamFilter

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.

>
>
> [...]
>
(Continue reading)

Cédric Schieli | 1 May 10:07 2009
Picon

Re: [PATCH] yuv2rgb: Trailing pixels are not converted if destination width is not multiple of 4

2009/4/30 Michael Niedermayer <michaelni <at> gmx.at>:
> On Thu, Apr 30, 2009 at 09:45:31PM +0200, Cédric Schieli wrote:
>> 2009/4/30 Michael Niedermayer <michaelni <at> gmx.at>:
>> > On Mon, Apr 27, 2009 at 04:08:13PM +0200, Cédric Schieli wrote:
> [...]
>> > besides i dont see how it could even work, it still has to be a multiple
>> > of 2.
>>
>> yes, but ffmpeg do not accept an odd destination width anyway.
>
> thats a very lame excuse, not all files are generated by ffmpeg and the
> check might be removed

I know, that's why
>> I'm ok it would be better to find a full fix

>>
>> >
>> > also was this bug always existing or is it new since the yuv2rgb rewrite?
>>
>> I did not test, but a quick look at the old yuv2rgb.c makes me think
>> it was already there
>
> until its confirmed that the old code was buggy too i think we should
> refrain from adding bloat, maybe it used a simpler fix

I can now confirm the bug was already there with the old code (tested
with a -r{2009-02-21} checkout of both ffmpeg and libswscale).

The only way I can think of (for the moment) to remove the bloat would
(Continue reading)

Stefano Sabatini | 1 May 13:33 2009
X-Face
Picon

Re: [PATCH] Implement av_get_token()

On date Thursday 2009-04-30 03:45:13 +0200, Michael Niedermayer encoded:
> On Sat, Apr 25, 2009 at 01:21:49PM +0200, Stefano Sabatini wrote:
[...]
> > > add \ at the end escaing the traiing null
> > > and unterminated '
> > > and escaped leading and trailing whitespace
> > 
> > OK.
> > 
> > [..]
> > > > +    /* strip trailing whitespaces */
> > > > +    out--;
> > > > +    while(--out >= ret && strspn(out, WHITESPACES))
> > > > +        *out = 0;
> > > 
> > > this will remove escaped trailing whitespaces
> > 
> > Reimplemeneted as a finite state machine, as the previous apporach was
> > resulting messy and unreadable.
> 
> i do not plan to approve this patch
> i think work should continue based on the previous version
> which was cleaner, simpler and smaller
> it only had one trivial bug

The previous patch had more problems that it looked, especially for
which regarded the terminating condition which I'm explicitely setting
now (for this I'm using the is_end var).

Other than this, the attached patch is absolutely equivalent to the
(Continue reading)

Laurent Aimar | 1 May 13:49 2009

[PATCH] Added integer 32 bits support to wavpack

 The attached patch completes the support for files with INT32INFO chunk
with non zero sent_bits.

--

-- 
fenrir

Attachment (wv-int32.patch): text/x-diff, 4339 bytes
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Cédric Schieli | 1 May 14:08 2009
Picon

[PATCH] libswscale: Chroma get shifted when converting from ARGB

Hi,

This patch fixes $subject which was noticed by Stefano here :
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-April/068208.html
Can someone test it on a big endian machine ?

Regards,
Cédric Schieli
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Cédric Schieli | 1 May 14:39 2009
Picon

[PATCH] yuv2rgb: luma get swapped on even lines

Hi,

I may be missing something, but why does luma is swapped on even lines
? This was not the case in the GPL scaler.
This patch fixes it, improving quality according to swscale-example,
and my eyes.

Regards,
Cédric Schieli
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Gmane