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

Michael Niedermayer michaelni
Wed Dec 10 12:16:43 CET 2008

On Wed, Dec 10, 2008 at 11:37:54AM +0100, Anton Khirnov wrote:
> ok, so you basically want me to reverse what Aurelien told me to do
> On Sun, Aug 24, 2008 at 6:15 PM, Aurelien Jacobs <aurel at gnuage.org> wrote:
> >There are many more things I don't like in this patch. One of them being that
> >the demuxer try to parse a directory and open files itself. I think the
> >demuxer should only deal with ByteIOContext that the generic framework (utils.c)
> >passes to it. That's up to the generic framework to find and open files
> >(or network streams of whatever...). That could also be useful for other
> >demuxer.
> joy, i love nothing more than moving random pieces of code betwenn
> utils and matroskadec :P

Well, i guess noone wants that random trash in code they maintain, i can
understand aurel about this ...

> >ehm, if nut did link to files, it would link by relative pathnames not
> >some file content specific thing.
> which means users can't rename their files. i'm not sure this is
> better than matroska system.

The first thing is that having videos refer to other files being idiotic
The second thing is that files are referred to by name on computers, pick
a random file of your OS and rename it to see where the problem is, or
try to rename a file on a server without updating the links to it
(if you say this is a lame example, rename a video and update the other
 videos that refer to it by name, its the same thing)
The third is that the ID inside the file just moves the name, its just
a matter of time until someone wants to change that ID too (especially
if its displayed by more tools ...)
forth the file could use its own basename as well, not just the path,
that would allow files to be renamed together.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- 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/20081210/d2751b84/attachment.pgp>

More information about the ffmpeg-devel mailing list