[FFmpeg-devel] [PATCH] support for ordered chapters/segment linking in Matroska

[Michael Niedermayer]

On Sun, Aug 10, 2008 at 08:18:17AM +0200, Anton Khirnov wrote:
> On Sat, Aug 9, 2008 at 7:00 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > the changes to avformat.h and utils.c are rejected. also all alternative
> > implementations that would allow switching the codec within a AVStream are
> > rejected.
> >
> > If you want a different codec just put the packets in a different AVStream!
> > Or even different AVFormatContext (with seperate and independant demuxer)
> >
> 
> um...why? 

because it would break EVERYTHING
try to transcode a mkv to anything else (hell not even another mkv would work
without considerable hacks to undo the hacks in the demuxer)
This is not a issue that is a little bad this is one of the most broken
patches ever submitted.


> the player explicitly asks for this so it must be prepared

one cannot explicitly ask for different output, that is one of the key issues
and it should raise a gigantic red flag for anyone who reads this even
without knowing further details.
Because _why_ is it not done by default? That question alone should make it
obvious that something is very very wrong. And that ABI & API obviously are
being ignored and broken. Instead of cleanly extended.


> to deal with it (as a side note, different codecs aren't allowed, just
> some reinitialization might be needed on segment switch). and

There is no codec, and no player and no way to reinitalize the muxer that
may be using the output.
when writing or working on a demuxer, there is a demuxer and the demuxer
MUST NOT EVER make any assumtations on what may come after it. As soon as
it checks "is there a player supporting X" you already did something wrong.
the demuxer can have 2 players or a muxer and a player connected. Its not
unimaginable that one wants to watch a file over the net and at the same
time want to download that to disk maybe in a different container ...


> rewriting the patch as you say would mean too much needless work and
> code duplication in players.

i did not suggest anything that was concrete enough to allow such
conclusions.

This issue has come up in the past, either implement it cleanly or
go away. You will not be successfull in pushing any hacks into ffmpeg!
ffmpeg is not a appendix of your favorite player, if your goal is to make
it work with a player while it wont work when the destination is a muxer
then you wont get the patch approved.

demuxers should export information about chapters, progams, their relation
and metadata, their recommanded order of playment, their filenames which very
well may be different container formats.

And the player could then use this information together with the users
preferrace and configuartion to play things.
There is nothing wrong with putting code in lavc to make it easier for apps
to do do this, like a
av_get_recommanded_streams(AVFormatContext, char* language)
or to extend the seeking API so that it can recommand AVStream/AVFormatContext
switches.

It is imaginable that there would be 1 AVFormatContext for each file and
a AVFormatContext for their combination that for example would likely be
the correct thing for things like SMIL.
It also is imaginable that there would be just 1 AVFormatContext accessing
several files ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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/20080810/729e90cc/attachment.pgp>