[FFmpeg-devel] Issues with ljpeg
Stefano Sabatini
stefano.sabatini-lala
Fri Aug 29 00:27:44 CEST 2008
On date Thursday 2008-08-28 09:01:38 +0200, Stefano Sabatini encoded:
> On date Thursday 2008-08-28 02:58:10 +0200, Michael Niedermayer encoded:
> > On Wed, Aug 27, 2008 at 08:00:43PM -0400, compn wrote:
> [...]
> > > it must be something when one ffmpeg developer has to convince
> > > other ffmpeg developers that a decoder/encoder actually exists...
> >
> > yes, everyone except me is stupid ;)
> >
> > our mjpeg decoder decodes ljpeg, similarly we DO have a h263p decoder
> > and a MPEG audio layer 1 decoder,
> > we also have vob, vcd and svcd demuxers, none of them is listed, i dont
> > know why this is suddenly confusing people, its not new at all ...
> [...]
>
> It would be nice anyway to export that information to the user, I mean
> in the case an X decoder provide support for many formats (this is
> another problem of the a-codec-is-not-a-stream-format issue).
I mean something like this:
AVStreamFormat:
this would represent the logical format used for a stream, would
contain constraints, a long name (which wouldn't need to be duplicated
in both codec and decoder), why not for example an url to a mediawiki
page with its description, and eventually the list of the encoders and
decoders which
support it.
AVCodec:
this would contain a reference to the AVStreamFormat(s) supported, for
example the mjpeg decoder would contain many reference to different
stream formats.
This way we could have many different implementations of the same
codec for the same stream format, each one referencing the
corresponding AVStreamFormat.
Similiar redesign may happen to libavformat too.
This would require a good deal of work, and would also require a major
bump, but would improve the overall codec/mudem management framework
(furthermore it is exactly what I'd for ffprobe!!;-)).
Regards.
--
FFmpeg = Foolish and Frightening Monstrous Programmable Epic Glue
More information about the ffmpeg-devel
mailing list