[FFmpeg-devel] maintainer duties (was: Re: [PATCH] fix speex sample)
Michael Niedermayer
michaelni
Sun Apr 19 18:36:11 CEST 2009
On Sat, Apr 11, 2009 at 07:48:57PM +0200, Kostya Shishkov wrote:
> On Sat, Apr 11, 2009 at 6:44 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Apr 11, 2009 at 06:37:10PM +0200, Kostya Shishkov wrote:
> >> On Sat, Apr 11, 2009 at 6:23 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Sat, Apr 11, 2009 at 06:04:07PM +0200, Kostya Shishkov wrote:
> >> >> On Sat, Apr 11, 2009 at 3:51 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> > On Sat, Apr 11, 2009 at 03:36:39PM +0200, Reimar D?ffinger wrote:
> >> >> [...]
> >> >> >> Also I think it would already be quite simple to fix if we just allowed
> >> >> >> packets to contain only palette (without any PKT_FLAG_PALETTE), since
> >> >> >> allocating a buffer and merging the palette stuff together with a video
> >> >> >> buffer is just a pain to implement. The problem though is that no
> >> >> >> keyframes at all would exist then.
> >> >> >
> >> >> > i think palette belongs in the packet with a frame not in a seperate packet
> >> >> > a palette is like a quantization tables in mpeg, we should treat it like
> >> >> > one
> >> >>
> >> >> Think about palettes in AVI - they are rather codec-agnostic. I think
> >> >> it's better to pass palettes as separate packets that can be handled
> >> >
> >> > that requires support for zero duration packets and requires code to
> >> > merge these packets with frames in muxers that are not called avi
> >> > so unless someone implements these, its not an option because it wouldnt
> >> > work with remuxing
> >>
> >> zero-duration packets - yes and it would be an unpleasant hack
> >
> >> as for remuxing - why should we bother? it's container-specific
> >
> > if we bother fixing AVPalette it should be done correctly, not in a
> > way that wont work with remuxing
>
> I also have some decoders using avctx->palctrl, so do we have stable
> way to pass palette change in AVI (i.e. those 1024 bytes at the end of
> frame) or I can wait before switching to some new way of passing
> palette?
i will fix avidec as soon as reimars packet grow/append patch is in
i need these ugly append() because it might be that there are multiple
pc chunks for a frame (i have no sample, but i also see no reason why this
couldnt be)
the 1024 byte at the end is a hack.
what i will do is put before each frame
"00pc" + 32bit len + the pc chunk, that is what is stored in AVI except 00
instead of a now meaningless stream #
and
"F" <the normal frame>
for the actual frame
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- 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/20090419/e311a2d3/attachment.pgp>
More information about the ffmpeg-devel
mailing list