[PATCH] attachments support in matroska demuxer
Hi, this patch adds attachments support to mkv demuxer. They are collected in AVFormatContext::attachments. This is needed to correctly display SSA/ASS subtitles that often depend on fonts emdedded in matroska container.
On Sat, Dec 29, 2007 at 10:38:24PM +0300, Evgeniy Stepanov wrote:
Hi,
this patch adds attachments support to mkv demuxer. They are collected in AVFormatContext::attachments. This is needed to correctly display SSA/ASS subtitles that often depend on fonts emdedded in matroska container.
such data belongs in AVCodecContext.extradata/extradata_size also your patch contains tabs and trailing whitespace which isnt allowed in ffmpeg svn [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
On 12/31/07, Michael Niedermayer <michaelni at gmx.at> wrote:
such data belongs in AVCodecContext.extradata/extradata_size
They are not related to any stream. Should I add a fake stream with attachments as extradata ? Or even as data packets, since there could be a lot of them.
On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
On 12/31/07, Michael Niedermayer <michaelni at gmx.at> wrote:
such data belongs in AVCodecContext.extradata/extradata_size
They are not related to any stream.
Then no stream needs them per definition, and they can be droped.
Should I add a fake stream with attachments as extradata ?
this does not sound reasonable ...
Or even as data packets, since there could be a lot of them.
The awnser depends on random access issues. Lets assume we have a stream (could be audio,video or subtitles). The API (as well as most containers) gives you 2 things 1. extradata 2. packets data packets can be keyframes or non keyframes one requirement is that you can start decoding from a keyframe + extradata that is without having ever seen, or having any means to see previous packets. so if the attachments are not globally needed then maybe packets are approproiate. If they are global you would have to duplicate them in front of every keyframe. as far as i understand matroska attachments, they are a mere duplication of extradata. It seems everyone thinks the codec or container they designed has special needs outside what already exists. Completely missing that the problem if one exists at all really applies to all codecs. And then goes on designing a new fancy solution not really solving anything ... other codecs store their huffman tables, vector quantizer tables, quantization tables, ... in extradata or before every keyframe. Fonts for subtitles are not different from other tables needed for decoding streams. If theres a problem with size of the fonts, maybe the designers of the codec (ASS/SAA here) should have spend more time thinking about the format in which fonts are stored, or have a minimum required set of fonts which every decoder must contain and which thus become unneeded to be stored in videos. Or even store fonts in files seperate of the videos. The only way to see fonts as special relative to global data (=extradata) would be if one argues that a subtitle decoder outputs UTF-8 + position + font name + color + size + ... in that case fonts would be an rendering hint but unneeded for decoding the subtitle stream (as the decoder doesnt output bitmaps ...). the problem here is that this is not how subtitles are currently implemented in libavcodec so if you want to pursue this direction you would first need to extend the existing subtitle handling to output such textual rendering info instead of bitmaps. anyway comments welcome! but most important is that we need generic solutions, not something which can only be used with mkv-ass (= no hacks) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On Tue, Jan 01, 2008 at 01:27:11PM +0100, Michael Niedermayer wrote: [...]
The only way to see fonts as special relative to global data (=extradata) would be if one argues that a subtitle decoder outputs UTF-8 + position + font name + color + size + ... in that case fonts would be an rendering hint but unneeded for decoding the subtitle stream (as the decoder doesnt output bitmaps ...). the problem here is that this is not how subtitles are currently implemented in libavcodec so if you want to pursue this direction you would first need to extend the existing subtitle handling to output such textual rendering info instead of bitmaps.
note, having subtitle decoders output UTF-8 + position + ... also allows easy transcoding between subtitle formats, so this might be the best solution if that is done, then putting fonts in a seperate stream as extradata with a CODEC_ID_TTF or so might make some sense ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On Tue, 2008-01-01 at 13:27 +0100, Michael Niedermayer wrote:
On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
On 12/31/07, Michael Niedermayer <michaelni at gmx.at> wrote:
such data belongs in AVCodecContext.extradata/extradata_size
They are not related to any stream.
Then no stream needs them per definition, and they can be droped.
A decoder may need them to show the subtitles accurately if it does not already have the required fonts. However the resources are not associated with any particular stream on the container level. Libavformat can guess (but NOT know for sure) that attached files which have a font type are used by decoders of subtitle streams of type SSA or ASS and not by other decoders. The same font may be used by multiple subtitle streams.
Should I add a fake stream with attachments as extradata ?
this does not sound reasonable ...
I think this would be the least bad fit if you want to force the extra resources into existing libavformat data structures.
as far as i understand matroska attachments, they are a mere duplication of extradata. It seems everyone thinks the codec or container they designed has special needs outside what already exists. Completely missing that the problem if one exists at all really applies to all codecs. And then goes on designing a new fancy solution not really solving anything ... other codecs store their huffman tables, vector quantizer tables, quantization tables, ... in extradata or before every keyframe. Fonts for subtitles are not different from other tables needed for decoding streams.
There are differences from extradata used by video/audio codecs. The fonts are often shared by multiple subtitle streams. The decision whether to attach the fonts or assume the decoder already has them is mostly independent of the subtitle stream (in contrast to video/audio extradata which is almost always an essential part of the stream itself).
The only way to see fonts as special relative to global data (=extradata) would be if one argues that a subtitle decoder outputs UTF-8 + position + font name + color + size + ...
You can't make an exhaustive list of properties easily. Position cannot be expressed with simple coordinates for some fixed part of rendered text unless the decoder knows the exact rendered size in advance. There can be rotated text, different kinds of border, and various special effects (more of which can appear in the future).
anyway comments welcome! but most important is that we need generic solutions, not something which can only be used with mkv-ass (= no hacks)
No other container can properly handle SSA/ASS with fonts AFAIK, so this requirement is rather vague. In practice no way of handling fonts (or other extra resource files) can be used with other containers before there's a spec on how to store such data in those containers. I think trying to make an overly general solution is not a good idea as long as the only real use will be with mkv+SSA/ASS. Better make something which works for that particular use and worry about a more general solution later when there's a need for it. Trying to guess now what kind of extra generality will be needed later is unlikely to produce a good result.
On Wed, Jan 02, 2008 at 03:47:40AM +0200, Uoti Urpala wrote:
On Tue, 2008-01-01 at 13:27 +0100, Michael Niedermayer wrote:
On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
On 12/31/07, Michael Niedermayer <michaelni at gmx.at> wrote:
such data belongs in AVCodecContext.extradata/extradata_size
They are not related to any stream.
Then no stream needs them per definition, and they can be droped.
A decoder may need them to show the subtitles accurately if it does not already have the required fonts. However the resources are not associated with any particular stream on the container level. Libavformat can guess (but NOT know for sure) that attached files which have a font type are used by decoders of subtitle streams of type SSA or ASS and not by other decoders. The same font may be used by multiple subtitle streams.
Well, if the demuxer cannot know which streams need an attachment then so the matroska file cannot be remuxed with a subset of the streams unless you also include all (likely) unneeded attachments. That would be a serious design flaw and hardly one upon which we should base our API. Also speaking of redundancy between streams, fonts are not special here extradata will often be identical or similar between streams of the same codec.
Should I add a fake stream with attachments as extradata ?
this does not sound reasonable ...
I think this would be the least bad fit if you want to force the extra resources into existing libavformat data structures.
Its not so much existing libavformat data structures, than existing container formats. I can add a new data structure in libavformat, but how is the avi, asf, mov, ... file generated from it going to work? [...]
The only way to see fonts as special relative to global data (=extradata) would be if one argues that a subtitle decoder outputs UTF-8 + position + font name + color + size + ...
You can't make an exhaustive list of properties easily. Position cannot be expressed with simple coordinates for some fixed part of rendered text unless the decoder knows the exact rendered size in advance. There can be rotated text, different kinds of border, and various special effects (more of which can appear in the future).
The data structure isnt cast in stone and can be extended as new things appear in the future. Any difficulty in making an exhaustive list exists for writing a (needed) subtitle decoder/renderer already. If you cant do that you cant decode the subtitle either way.
anyway comments welcome! but most important is that we need generic solutions, not something which can only be used with mkv-ass (= no hacks)
No other container can properly handle SSA/ASS with fonts AFAIK, so this requirement is rather vague. In practice no way of handling fonts (or other extra resource files) can be used with other containers before there's a spec on how to store such data in those containers. I think trying to make an overly general solution is not a good idea as long as the only real use will be with mkv+SSA/ASS. Better make something which works for that particular use and worry about a more general solution later when there's a need for it. Trying to guess now what kind of extra generality will be needed later is unlikely to produce a good result.
Simply duplicating the fonts in extradata would work (with respect to fonts) with most containers and a libavcodec based ASS/SSA decoder (->it also would work in all libavcodec based players even ones not using libavformat) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
On Wed, 2008-01-02 at 04:31 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 03:47:40AM +0200, Uoti Urpala wrote:
On Tue, 2008-01-01 at 13:27 +0100, Michael Niedermayer wrote:
On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
Well, if the demuxer cannot know which streams need an attachment then so the matroska file cannot be remuxed with a subset of the streams unless you also include all (likely) unneeded attachments.
AFAIK this is the case - you cannot know which attachments decoders might be able to use based on container-level information only.
That would be a serious design flaw and hardly one upon which we should base our API.
API for doing what? Libavformat should provide access to the contents of Matroska attachments. What other things should the same API be generalized to do? Hypothetical attachments in other containers? Restrict it to less than general attachment handling for subtitle fonts only, but generalize that to hypothetical fonts in other containers?
Also speaking of redundancy between streams, fonts are not special here extradata will often be identical or similar between streams of the same codec.
Extradata may happen to be identical, but subtitles can refer to "the same font" in a stricter sense. If you demux a .mkv file into separate files, a natural format is to have an audio file (or files), a video file, a .ssa/.ass file (or files) and a bunch of font files. Nobody splits video/audio tracks into separate "standard extradata" and "main content" parts.
Should I add a fake stream with attachments as extradata ?
this does not sound reasonable ...
I think this would be the least bad fit if you want to force the extra resources into existing libavformat data structures.
Its not so much existing libavformat data structures, than existing container formats. I can add a new data structure in libavformat, but how is the avi, asf, mov, ... file generated from it going to work?
You may not be able to automatically remux one from mkv, but AFAIK there is currently no spec which would give corresponding functionality in those containers with any method (independently of whether you want to create the file by remuxing from mkv or from scratch). Attaching the fonts during muxing or not is also a separate decision which is not necessarily related to the contents of the subtitle track. And you should also consider muxing mkv.
The only way to see fonts as special relative to global data (=extradata) would be if one argues that a subtitle decoder outputs UTF-8 + position + font name + color + size + ...
You can't make an exhaustive list of properties easily. Position cannot be expressed with simple coordinates for some fixed part of rendered text unless the decoder knows the exact rendered size in advance. There can be rotated text, different kinds of border, and various special effects (more of which can appear in the future).
The data structure isnt cast in stone and can be extended as new things appear in the future. Any difficulty in making an exhaustive list exists for writing a (needed) subtitle decoder/renderer already. If you cant do that you cant decode the subtitle either way.
The output format of such a "decoder" would need to be so high level that it wouldn't so much be decoding as translating to another very general subtitle format.
but most important is that we need generic solutions, not something which can only be used with mkv-ass (= no hacks)
No other container can properly handle SSA/ASS with fonts AFAIK, so this requirement is rather vague. In practice no way of handling fonts (or other extra resource files) can be used with other containers before there's a spec on how to store such data in those containers. I think
Simply duplicating the fonts in extradata would work (with respect to fonts) with most containers and a libavcodec based ASS/SSA decoder (->it also would work in all libavcodec based players even ones not using libavformat)
Duplicating the fonts can be expensive if there are lots of subtitle tracks (which there can be as they're otherwise small). In addition to the memory directly used by the font files there are also whatever data structures parsing and rendering them requires - duplicating the fonts in the extradata of each track would force a decoder to do extra work comparing them to go back to the shared representation if it wants to avoid that overhead. And what about other Matroska attachments? Shouldn't there be a general way to access them? I think it would be better to create an API for accessing Matroska attachments (generalized to attachments in other containers if some get such functionality), and leave issues specific to fonts and their relation to subtitle tracks outside libavformat for now.
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
That would be a serious design flaw and hardly one upon which we should base our API.
API for doing what? Libavformat should provide access to the contents of Matroska attachments. What other things should the same API be generalized to do? Hypothetical attachments in other containers? Restrict it to less than general attachment handling for subtitle fonts only, but generalize that to hypothetical fonts in other containers?
I think Michael's concern is how you expect a decoder for ASS/SSA subtitles to obtain the fonts. Having demuxer-specific code (or even code which depends on a demuxer api at all) in the decoder is not acceptable.
Also speaking of redundancy between streams, fonts are not special here extradata will often be identical or similar between streams of the same codec.
Extradata may happen to be identical, but subtitles can refer to "the same font" in a stricter sense. If you demux a .mkv file into separate files, a natural format is to have an audio file (or files), a video file, a .ssa/.ass file (or files) and a bunch of font files. Nobody splits video/audio tracks into separate "standard extradata" and "main content" parts.
I agree here too. Most subtitle 'codecs' already have an extradata format of their own, text-based, separate from the binary ttf data. Most likely it's the "header text" which would appear at the beginning of the subtitle file if it were flat text. So it would be rather problematic to try to munge the fonts together with this...
Duplicating the fonts can be expensive if there are lots of subtitle tracks (which there can be as they're otherwise small). In addition to the memory directly used by the font files there are also whatever data structures parsing and rendering them requires - duplicating the fonts in the extradata of each track would force a decoder to do extra work comparing them to go back to the shared representation if it wants to
This makes sense.
avoid that overhead. And what about other Matroska attachments? Shouldn't there be a general way to access them? I think it would be better to create an API for accessing Matroska attachments (generalized to attachments in other containers if some get such functionality), and leave issues specific to fonts and their relation to subtitle tracks outside libavformat for now.
The whole idea of attachments is rather disgusting and something of a hack... But I don't know any right way to deal with them, just that existing ways are not the right way.. Rich
On Wed, Jan 02, 2008 at 12:51:46AM -0500, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
That would be a serious design flaw and hardly one upon which we should base our API.
API for doing what?
That what libavformat is for, muxing and demuxing, the system used in matroska is as such insufficient to remux a subset of streams. That is even mkv->mkv
Libavformat should provide access to the contents of Matroska attachments.
Libavformat first needs a generic API for this, though if there is no interrest in a clean solution iam prepared to reject attachment support completely. Ive no interrest in a "lets quickly just export attachments" to make ASS/SSA in mplayer work with lavf. lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments are not needed currently. Especially not in a half thought through way.
What other things should the same API be generalized to do? Hypothetical attachments in other containers?
Lets say if the system doesnt work with avi/mov/nut its rejected. And about there being a spec for AVI/MOV id rather preempt someone comming up with storing mkv with attachments as is in a stream in avi. We had this with ogg in the style of vorbis in ogg in avi ...
Restrict it to less than general attachment handling for subtitle fonts only, but generalize that to hypothetical fonts in other containers?
I think Michael's concern is how you expect a decoder for ASS/SSA subtitles to obtain the fonts. Having demuxer-specific code (or even code which depends on a demuxer api at all) in the decoder is not acceptable.
Its not hard to add a pointer to AVCodecContext which points to lets say a linked list of attachments. If that is easy within other demuxer / decoder APIs though is less certain. [...]
Duplicating the fonts can be expensive if there are lots of subtitle tracks (which there can be as they're otherwise small). In addition to the memory directly used by the font files there are also whatever data structures parsing and rendering them requires - duplicating the fonts in the extradata of each track would force a decoder to do extra work comparing them to go back to the shared representation if it wants to
This makes sense.
As already said this doesnt make attachments/fonts special, extradata or parts of extradata are also commonly identical. The solution here (attachments) is quite specific ignoring the general problem of redundancy in extradata. That as well can be redundancy relative to some default large vector quantizer tables. Also sharing any non constant data generated from fonts or extradata between several decoder instances will require thread synchronization so half of the "sensible" comment above really only applies for decoders peppered with mutexes fromyour favorite thread API. (and its unlikely that a decoder would be written like that ...)
avoid that overhead. And what about other Matroska attachments? Shouldn't there be a general way to access them? I think it would be better to create an API for accessing Matroska attachments (generalized to attachments in other containers if some get such functionality), and leave issues specific to fonts and their relation to subtitle tracks outside libavformat for now.
The whole idea of attachments is rather disgusting and something of a hack... But I don't know any right way to deal with them, just that existing ways are not the right way..
Well, iam waiting to see some actually working solution from you and uoti which is better Minimum requirements are * efficiently remuxing a subset of streams * mov and avi support (the fonts can even be in seperate files but id like to see a working patch here not some general sketch of how it might work) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 12:51:46AM -0500, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
Libavformat should provide access to the contents of Matroska attachments.
Libavformat first needs a generic API for this, though if there is no interrest in a clean solution iam prepared to reject attachment support completely. Ive no interrest in a "lets quickly just export attachments" to make ASS/SSA in mplayer work with lavf.
Do you not want to provide access to the exact contents stored in the container through lavf? For Matroska attachments that most likely requires some container-specific functionality. Or do you intend lavf to only allow access to some common-denominator subset of container functionality that is easy to remux in any of them? MPlayer's native Matroska demuxer is still preferable to the lavf one so there's no real hurry to make the lavf one fully functional. Even so I think that insisting on a fully generic and clean implementation as the first step is a bad choice. Especially when there are no would-be users of the more generic functionality, it's not even clear what that functionality should be, and a simple "let's just quickly export the attachments" interface would not be particularly messy or hard to change later.
lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments are not needed currently. Especially not in a half thought through way.
Why would lavf functionality be "not needed" unless lavc has corresponding functionality too? Do you consider ffmpeg.c to be the only worthwhile program using the libraries? Or think that all video-related functionality must be added to FFmpeg and other programs shouldn't use SSA/ASS decoding without adding it to lavc?
What other things should the same API be generalized to do? Hypothetical attachments in other containers?
Lets say if the system doesnt work with avi/mov/nut its rejected.
Work to give what result? What are you supposed to get when you try to remux an mkv with attachments to avi?
Duplicating the fonts can be expensive if there are lots of subtitle tracks (which there can be as they're otherwise small). In addition to the memory directly used by the font files there are also whatever data structures parsing and rendering them requires - duplicating the fonts in the extradata of each track would force a decoder to do extra work comparing them to go back to the shared representation if it wants to
This makes sense.
As already said this doesnt make attachments/fonts special, extradata or parts of extradata are also commonly identical.
There are (as already said...) reasons why memory usage by fonts is different from video tracks. Video extradata may commonly happen to be identical, but subtitles refer to "the same font" in a stricter sense. The memory usage associated with fonts can be significant while the subtitle track itself is small. It's very rare to have a huge number of video tracks as that would make the file size much larger than versions with separate tracks, but adding a large number of subtitle tracks causes no such problems.
The solution here (attachments) is quite specific ignoring the general problem of redundancy in extradata. That as well can be redundancy relative to some default large vector quantizer tables.
It's much more of a problem for fonts than for video or audio extradata. And memory use is not the only reason to use attachments. I already explained that whether to attach the fonts or assume the decoder has them is a decision which can be separate from the contents of the subtitle track (unlike video), and that a natural format for demuxing a .mkv into separate files is to have .ass files and separate font files (unlike video).
Also sharing any non constant data generated from fonts or extradata between several decoder instances will require thread synchronization so half of the "sensible" comment above really only applies for decoders peppered with mutexes fromyour favorite thread API. (and its unlikely that a decoder would be written like that ...)
It requires either a decoder using mutexes for shared caches (which is not particularly unlikely even if you claim otherwise), or a decoder that has a per-played-file context shared by all subtitle streams from that file (and of course only one thread may be decoding a stream using that context at once).
Well, iam waiting to see some actually working solution from you and uoti which is better Minimum requirements are * efficiently remuxing a subset of streams
Again, what exactly is the behavior you want? You cannot choose the minimum used set of font files referred to from a subset of streams in current mkv automatically without parsing those streams (and you might not always want to attach the fonts to the output file even if the streams did refer to them). So what should the system do? Actually parse the streams to find out which fonts might be used (not very practical)? Have functionality which would allow picking only required fonts in case it was used with some hypothetical container which did have dependency information (adding code which at the moment would be totally useless)?
* mov and avi support (the fonts can even be in seperate files but id like to see a working patch here not some general sketch of how it might work)
Again, mov and avi "support" in what sense? AFAIK there is no spec on how to store SSA in mov or avi. So what kind of mov/avi files would you want to create?
On Wed, Jan 02, 2008 at 09:10:22PM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 12:51:46AM -0500, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
Libavformat should provide access to the contents of Matroska attachments.
Libavformat first needs a generic API for this, though if there is no interrest in a clean solution iam prepared to reject attachment support completely. Ive no interrest in a "lets quickly just export attachments" to make ASS/SSA in mplayer work with lavf.
Do you not want to provide access to the exact contents stored in the container through lavf? For Matroska attachments that most likely
Id like to provide access to what is needed and do so in a clean and flexible way.
requires some container-specific functionality. Or do you intend lavf to only allow access to some common-denominator subset of container functionality that is easy to remux in any of them?
Using extradata supports remuxing in avi/mov/nut. Using AVAttachments as in the patch does not on its own, it could be extended somehow to make storage in avi/mov possible, until then this soluton though is inferrior. And i wont accept an inferrior solution. [...]
lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments are not needed currently. Especially not in a half thought through way.
Why would lavf functionality be "not needed" unless lavc has corresponding functionality too?
Do you consider ffmpeg.c to be the only worthwhile program using the libraries? Or think that all video-related functionality must be added to FFmpeg and other programs shouldn't use SSA/ASS decoding without adding it to lavc?
Could you please refrain from trolling. I repeat it again, we need a clean system. If we alread now know that it will cause problems with a hypothetical ass/ssa decoder in lavc then the system certainly is not well designed. Anyway the discussion with you is pointless, you seem to be on a trolling crussade, ive better things to do then to reply to you any further.
What other things should the same API be generalized to do? Hypothetical attachments in other containers?
Lets say if the system doesnt work with avi/mov/nut its rejected.
Work to give what result? What are you supposed to get when you try to remux an mkv with attachments to avi?
a avi which when decoded results in bit identical video+subs
Duplicating the fonts can be expensive if there are lots of subtitle tracks (which there can be as they're otherwise small). In addition to the memory directly used by the font files there are also whatever data structures parsing and rendering them requires - duplicating the fonts in the extradata of each track would force a decoder to do extra work comparing them to go back to the shared representation if it wants to
This makes sense.
As already said this doesnt make attachments/fonts special, extradata or parts of extradata are also commonly identical.
There are (as already said...) reasons why memory usage by fonts is different from video tracks. Video extradata may commonly happen to be identical, but subtitles refer to "the same font" in a stricter sense. The memory usage associated with fonts can be significant while the subtitle track itself is small. It's very rare to have a huge number of video tracks as that would make the file size much larger than versions with separate tracks, but adding a large number of subtitle tracks causes no such problems.
My .avi files also are bigger than my .txt files still they coexist on the same file system. Based on your aruments one should design a new filesystem for each mime type.
The solution here (attachments) is quite specific ignoring the general problem of redundancy in extradata. That as well can be redundancy relative to some default large vector quantizer tables.
It's much more of a problem for fonts than for video or audio extradata. And memory use is not the only reason to use attachments. I already explained that whether to attach the fonts or assume the decoder has them is a decision which can be separate from the contents of the subtitle track (unlike video), and that a natural format for demuxing a .mkv into separate files is to have .ass files and separate font files (unlike video).
You are just describing common practice. Seperate .ass does not differ from separte audio and video files. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
On Thu, 2008-01-03 at 00:12 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 09:10:22PM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
Do you not want to provide access to the exact contents stored in the container through lavf? For Matroska attachments that most likely
Id like to provide access to what is needed and do so in a clean and flexible way.
And do you know what an application using lavf needs access to? Even if you create a separate "generalized" hack for subtitles there are still other attachment types. Do you think that lavf should not provide access to Matroska attachments in general (at a level which does not care what the application wants to use those attachments for)?
requires some container-specific functionality. Or do you intend lavf to only allow access to some common-denominator subset of container functionality that is easy to remux in any of them?
Using extradata supports remuxing in avi/mov/nut.
It does not when there is no spec how to format such extradata or how to store SSA/ASS in those containers at all. And there can be other kinds of attachments.
Using AVAttachments as in the patch does not on its own, it could be extended somehow to make storage in avi/mov possible, until then this soluton though is inferrior. And i wont accept an inferrior solution.
Such an "extended solution" would not only be about lavf code but would require extending the specs of the container formats in question. And that solution would not solve access to Matroska attachments in general. You won't accept what you consider an "inferior" solution and prefer the inferior alternative of things not working at all.
lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments are not needed currently. Especially not in a half thought through way.
Why would lavf functionality be "not needed" unless lavc has corresponding functionality too? Do you consider ffmpeg.c to be the only worthwhile program using the libraries? Or think that all video-related functionality must be added to FFmpeg and other programs shouldn't use SSA/ASS decoding without adding it to lavc?
Could you please refrain from trolling.
My reply is no more trolling than your "the decoding is not done in lavc so nobody needs to demux them either". Do you actually have a better reason for your comment than those I suggested?
I repeat it again, we need a clean system. If we alread now know that it will cause problems with a hypothetical ass/ssa decoder in lavc then the system certainly is not well designed.
Whether it will cause problems depends on how that hypothetical decoder that nobody is working on would be implemented. And even if you think you'll want a more general solution later that doesn't mean you should do it that way now when you don't need it yet.
Anyway the discussion with you is pointless, you seem to be on a trolling crussade, ive better things to do then to reply to you any further.
I've made a lot of points which have nothing to do with trolling, and I've shown that several of your ideas were wrong. I think that should make the discussion not completely pointless unless you refuse to learn from anything said by me. Your attitude in this discussion seems to be that the solution you consider the most general or clean must be implemented, even if it does not actually work all that well or isn't the most practical one to use with container formats as they now exist. Instead of creating a solution which works best in the current situation you want to create a solution designed for a future where everyone else does things the way you want and changes their code to fit your preferred design.
Lets say if the system doesnt work with avi/mov/nut its rejected.
Work to give what result? What are you supposed to get when you try to remux an mkv with attachments to avi?
a avi which when decoded results in bit identical video+subs
It's not possible to make an avi which would give identical results. To get that you'd first need to extend specs and then change decoders.
There are (as already said...) reasons why memory usage by fonts is different from video tracks. Video extradata may commonly happen to be identical, but subtitles refer to "the same font" in a stricter sense. The memory usage associated with fonts can be significant while the subtitle track itself is small. It's very rare to have a huge number of video tracks as that would make the file size much larger than versions with separate tracks, but adding a large number of subtitle tracks causes no such problems.
My .avi files also are bigger than my .txt files still they coexist on the same file system. Based on your aruments one should design a new filesystem for each mime type.
Your analogy is stupid enough that you're probably just trolling, but I'll write a short reply anyway. In a filesystem some files have identical parts but are still stored separately (like video tracks). Other resources are in separate files which are shared by multiple contexts (like fonts).
The solution here (attachments) is quite specific ignoring the general problem of redundancy in extradata. That as well can be redundancy relative to some default large vector quantizer tables.
It's much more of a problem for fonts than for video or audio extradata. And memory use is not the only reason to use attachments. I already explained that whether to attach the fonts or assume the decoder has them is a decision which can be separate from the contents of the subtitle track (unlike video), and that a natural format for demuxing a .mkv into separate files is to have .ass files and separate font files (unlike video).
You are just describing common practice. Seperate .ass does not differ from separte audio and video files.
Your reply makes no sense. Of course separating .ass does not differ from separating audio and video; the point is that it's natural to split to an .ass file + font files, whereas nobody splits to a video extradata file plus separate video main content file. And an .ass track without (all) fonts attached still makes some sense, whereas nobody muxes video tracks without the extradata.
On Thu, Jan 03, 2008 at 02:47:09AM +0200, Uoti Urpala wrote:
On Thu, 2008-01-03 at 00:12 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 09:10:22PM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
Do you not want to provide access to the exact contents stored in the container through lavf? For Matroska attachments that most likely
Id like to provide access to what is needed and do so in a clean and flexible way.
And do you know what an application using lavf needs access to? Even if
approximately yes, in all perfect fine detail no.
you create a separate "generalized" hack for subtitles there are still other attachment types. Do you think that lavf should not provide access to Matroska attachments in general (at a level which does not care what the application wants to use those attachments for)?
I do want attachments to be exported to the application in some _CLEAN_ way, hey this is even the topic of this thread. But i guess i can say whatever i want you will keep asking questions as if i said something i didnt say.
requires some container-specific functionality. Or do you intend lavf to only allow access to some common-denominator subset of container functionality that is easy to remux in any of them?
Using extradata supports remuxing in avi/mov/nut.
It does not when there is no spec how to format such extradata or how to store SSA/ASS in those containers at all. And there can be other kinds of attachments.
Using AVAttachments as in the patch does not on its own, it could be extended somehow to make storage in avi/mov possible, until then this soluton though is inferrior. And i wont accept an inferrior solution.
Such an "extended solution" would not only be about lavf code but would require extending the specs of the container formats in question. And that solution would not solve access to Matroska attachments in general.
You won't accept what you consider an "inferior" solution
yes
and prefer the inferior alternative
no, sorry even if you want that, i wont accept any inferrior variant no matter who proposed it, be it you or myself
of things not working at all.
they would work, so would AVAttachments with some changes
lavc doesnt even have a ASS/SSA decoder, so from my point of view attachments are not needed currently. Especially not in a half thought through way.
Why would lavf functionality be "not needed" unless lavc has corresponding functionality too? Do you consider ffmpeg.c to be the only worthwhile program using the libraries? Or think that all video-related functionality must be added to FFmpeg and other programs shouldn't use SSA/ASS decoding without adding it to lavc?
Could you please refrain from trolling.
My reply is no more trolling than your "the decoding is not done in lavc so nobody needs to demux them either". Do you actually have a better reason for your comment than those I suggested?
Iam just trying to make it clear that we need a clean solution. Iam not seriously planing to not support attachments. But threatening with that makes people think about the half baked mess they proposed, hey i even got you to write some comments. Even if they are 90% trollinga and flaming.
I repeat it again, we need a clean system. If we alread now know that it will cause problems with a hypothetical ass/ssa decoder in lavc then the system certainly is not well designed.
Whether it will cause problems depends on how that hypothetical decoder
that nobody is working on
Really, how do you know?
would be implemented.
Not really, no, it doesnt matter how its implemented. You need to pass the fonts to the decoder independant of its implementation. Its even quite bad design if you base the API used for passing attachments to the decoder on a specific decoder implementation.
And even if you think you'll want a more general solution later that doesn't mean you should do it that way now when you don't need it yet.
Many applications use lavc and lavf, changing the API continuously is quite annoying for most of their developers. Its also a lot of extra work for them to repeatly change the code used to access lavc/lavf.
Anyway the discussion with you is pointless, you seem to be on a trolling crussade, ive better things to do then to reply to you any further.
I've made a lot of points which have nothing to do with trolling, and
I've shown that several of your ideas were wrong. I think that should
You have mostly shown that your interpretations and guesses of what i meant were wrong.
make the discussion not completely pointless unless you refuse to learn
from anything said by me.
Your attitude in this discussion seems to be that the solution you consider the most general or clean must be implemented, even if it does not actually work all that well or isn't the most practical one to use with container formats as they now exist. Instead of creating a solution which works best in the current situation you want to create a solution designed for a future where everyone else does things the way you want and changes their code to fit your preferred design.
Your ability to read my thoughts fails. I dont want the things you claim i do.
Lets say if the system doesnt work with avi/mov/nut its rejected.
Work to give what result? What are you supposed to get when you try to remux an mkv with attachments to avi?
a avi which when decoded results in bit identical video+subs
It's not possible to make an avi which would give identical results. To get that you'd first need to extend specs and then change decoders.
let me simplify that "its not possible. To make it possible you would ..." Is it just me or is that what you say selfcontradicting? And iam not claiming that would be limited to the above 2 sentences.
There are (as already said...) reasons why memory usage by fonts is different from video tracks. Video extradata may commonly happen to be identical, but subtitles refer to "the same font" in a stricter sense. The memory usage associated with fonts can be significant while the subtitle track itself is small. It's very rare to have a huge number of video tracks as that would make the file size much larger than versions with separate tracks, but adding a large number of subtitle tracks causes no such problems.
My .avi files also are bigger than my .txt files still they coexist on the same file system. Based on your aruments one should design a new filesystem for each mime type.
Your analogy is stupid enough that you're probably just trolling, but
Its hard to find a smart analogy to a stupid claim. After all the point was to show that your claim is stupid.
I'll write a short reply anyway. In a filesystem some files have identical parts but are still stored separately (like video tracks). Other resources are in separate files which are shared by multiple contexts (like fonts).
That rather would have to be fonts stored duplicated in some .txt files.
The solution here (attachments) is quite specific ignoring the general problem of redundancy in extradata. That as well can be redundancy relative to some default large vector quantizer tables.
It's much more of a problem for fonts than for video or audio extradata. And memory use is not the only reason to use attachments. I already explained that whether to attach the fonts or assume the decoder has them is a decision which can be separate from the contents of the subtitle track (unlike video), and that a natural format for demuxing a .mkv into separate files is to have .ass files and separate font files (unlike video).
You are just describing common practice. Seperate .ass does not differ from separte audio and video files.
from separating audio and video; the point is that it's natural to split to an .ass file + font files, whereas nobody splits to a video extradata file plus separate video main content file. And an .ass track without (all) fonts attached still makes some sense, whereas nobody muxes video
Your reply makes no sense. Of course separating .ass does not differ tracks without the extradata.
Just compare fonts to some refinement streams (mpeg/jpeg/jpeg2k scalability) They both are optional and improve presentation if available. Your arguments are based on the idea that mkv attachments and fonts (2 distinct things implemented with the same syntax) are mkv specific and dont exist in other containers. This is false. Still you skip over the presented facts and continue to claim we should ignore the other containers. And design a API based on how mkv handles fonts and attachments [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras
On Thu, 2008-01-03 at 03:18 +0100, Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 02:47:09AM +0200, Uoti Urpala wrote:
On Thu, 2008-01-03 at 00:12 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 09:10:22PM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 11:21 +0100, Michael Niedermayer wrote:
you create a separate "generalized" hack for subtitles there are still other attachment types. Do you think that lavf should not provide access to Matroska attachments in general (at a level which does not care what the application wants to use those attachments for)?
I do want attachments to be exported to the application in some _CLEAN_ way, hey this is even the topic of this thread. But i guess i can say whatever i want you will keep asking questions as if i said something i didnt say.
You did oppose exporting the attachments as is and wanted things like copying font attachments to the extradata of every subtitle track instead. If that was the only way to access the attachments it wouldn't work for a program that wants to access the attachments for some other reason.
Could you please refrain from trolling.
My reply is no more trolling than your "the decoding is not done in lavc so nobody needs to demux them either". Do you actually have a better reason for your comment than those I suggested?
Iam just trying to make it clear that we need a clean solution. Iam not seriously planing to not support attachments. But threatening with that makes people think about the half baked mess they proposed, hey i even got you to write some comments.
Your own description of what you tried to do sounds pretty much like the definition of trolling.
Even if they are 90% trollinga and flaming.
I think most of my comments in this thread are in no way trolling or flaming.
And even if you think you'll want a more general solution later that doesn't mean you should do it that way now when you don't need it yet.
Many applications use lavc and lavf, changing the API continuously is quite annoying for most of their developers. Its also a lot of extra work for them to repeatly change the code used to access lavc/lavf.
Any changes will only be needed after there is some actual use for more general functionality. And generalizing the API in advance does not guarantee you'll avoid changes. That would only happen if you get it right before you know how other containers will actually implement the functionality (if at all).
Lets say if the system doesnt work with avi/mov/nut its rejected.
Work to give what result? What are you supposed to get when you try to remux an mkv with attachments to avi?
a avi which when decoded results in bit identical video+subs
It's not possible to make an avi which would give identical results. To get that you'd first need to extend specs and then change decoders.
let me simplify that "its not possible. To make it possible you would ..."
Is it just me or is that what you say selfcontradicting? And iam not claiming that would be limited to the above 2 sentences.
Here's a spelled out version: Given current specs and existing decoders it is not possible to create an avi file which would behave the way you want. So it is impossible to create any system of exporting Matroska attachments that would make remuxing to avi work (as such avi files simply cannot exist). So to get something that could be called "avi" and has the desired functionality you would first need to abandon the "given current specs and existing decoders" premise, extend the specs and change decoders to support the new specs. I think it is unreasonable to require extending specs related to other container formats as a precondition to supporting some Matroska feature.
from separating audio and video; the point is that it's natural to split to an .ass file + font files, whereas nobody splits to a video extradata file plus separate video main content file. And an .ass track without (all) fonts attached still makes some sense, whereas nobody muxes video
Your reply makes no sense. Of course separating .ass does not differ tracks without the extradata.
Just compare fonts to some refinement streams (mpeg/jpeg/jpeg2k scalability) They both are optional and improve presentation if available.
Those refinement streams make no sense as independent objects, and are very unlikely to be shared between tracks.
Your arguments are based on the idea that mkv attachments and fonts (2 distinct things implemented with the same syntax) are mkv specific and dont exist in other containers. This is false.
I'm not sure which arguments you're referring to. I've made several arguments in this thread to which your claim obviously can't apply at all.
Still you skip over the presented facts and continue to claim we should ignore the other containers. And design a API based on how mkv handles fonts and attachments
Here's an overall description of my view: - There should be a way to access Matroska attachments directly (the same API could likely to be used for generic attachments in other containers). This should still exist even if there was a separate way to handle fonts, or other higher-level way(s) to access resources Matroska can store in attachments. - Such an attachment API would be reasonably easy to implement. - Even if an attachment-specific API is not suitable for storing fonts in every container the practical benefit of creating a different API for fonts (and possibly other hypothetical functionality) is very limited as long as fonts are not in practice stored in other containers. - Getting fonts through an attachment-specific API does not require much code. Nor is there any other obvious reason why it would be more important to make sure no changes are needed in the future than to make the current implementation simple and practical. - Given the above it's best to add an attachment API to libavformat now and leave the semantics of the attachments to the calling application. So I'm not advocating creating a "font API" based on how mkv does it. Rather I'm saying that a simple "just give the attachments" API is the most practical way to do everything people want with currently existing files, and a more abstracted (and complicated to implement) API should only be added later if the situation changes so that such an API would give some real practical benefit.
Hi On Wed, Jan 02, 2008 at 12:51:46AM -0500, Rich Felker wrote: [...]
avoid that overhead. And what about other Matroska attachments? Shouldn't there be a general way to access them? I think it would be better to create an API for accessing Matroska attachments (generalized to attachments in other containers if some get such functionality), and leave issues specific to fonts and their relation to subtitle tracks outside libavformat for now.
The whole idea of attachments is rather disgusting and something of a hack... But I don't know any right way to deal with them, just that existing ways are not the right way..
Right way (for ASS/SSA mkv) would have been IMHO, like codecs. File uses font foobar, if available fine, if not warn the user that a font is missing and she should find and install it for optimal display. (that find&install could have been automatic on network connected point and click OSs) Also dont forget that embeding ttf fonts (which is i think what is done) opens you up to all exploits in the ttf rendering lib. Downloading them from a trusted source seperately reduces the risk significantly. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I wish the Xiph folks would stop pretending they've got something they do not. Somehow I fear this will remain a wish. -- M?ns Rullg?rd
On Wed, 2008-01-02 at 12:24 +0100, Michael Niedermayer wrote:
Right way (for ASS/SSA mkv) would have been IMHO, like codecs.
File uses font foobar, if available fine, if not warn the user that a font is missing and she should find and install it for optimal display. (that find&install could have been automatic on network connected point and click OSs)
Completely impractical.
Also dont forget that embeding ttf fonts (which is i think what is done) opens you up to all exploits in the ttf rendering lib. Downloading them from a trusted source seperately reduces the risk significantly.
There's no trusted source which would have all fonts (some of which are custom made). Pdf files can have embedded fonts so most people are already exposed to whatever exploits are possible against the font rendering library. The video libraries are likely to be an easier target for attack anyway.
On Wed, 2 Jan 2008, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
Extradata may happen to be identical, but subtitles can refer to "the same font" in a stricter sense. If you demux a .mkv file into separate files, a natural format is to have an audio file (or files), a video file, a .ssa/.ass file (or files) and a bunch of font files. Nobody splits video/audio tracks into separate "standard extradata" and "main content" parts.
I agree here too. Most subtitle 'codecs' already have an extradata format of their own, text-based, separate from the binary ttf data. Most likely it's the "header text" which would appear at the beginning of the subtitle file if it were flat text. So it would be rather problematic to try to munge the fonts together with this...
You can put fonts in SSA extradata, using a variant of uuencoding. I haven't seen this recently, but I have some movies using this from before matroska. --Loren Merritt
On Jan 2, 2008, at 8:45 PM, Loren Merritt wrote:
On Wed, 2 Jan 2008, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
Extradata may happen to be identical, but subtitles can refer to "the same font" in a stricter sense. If you demux a .mkv file into separate files, a natural format is to have an audio file (or files), a video file, a .ssa/.ass file (or files) and a bunch of font files. Nobody splits video/audio tracks into separate "standard extradata" and "main content" parts.
I agree here too. Most subtitle 'codecs' already have an extradata format of their own, text-based, separate from the binary ttf data. Most likely it's the "header text" which would appear at the beginning of the subtitle file if it were flat text. So it would be rather problematic to try to munge the fonts together with this...
You can put fonts in SSA extradata, using a variant of uuencoding. I haven't seen this recently, but I have some movies using this from before matroska.
--Loren Merritt
This usually isn't done in practice, although it might be useful for AVI. mkvmerge will actually delete Font sections and add them as new mkv attachments. Anyway, since Unicode fonts can be several MB, I really wouldn't want them ending up in text files I want to edit.
On Wed, Jan 02, 2008 at 09:06:58PM -0500, Alexander Strange wrote:
You can put fonts in SSA extradata, using a variant of uuencoding. I haven't seen this recently, but I have some movies using this from before matroska.
--Loren Merritt
This usually isn't done in practice, although it might be useful for AVI. mkvmerge will actually delete Font sections and add them as new mkv attachments. Anyway, since Unicode fonts can be several MB, I really wouldn't want them ending up in text files I want to edit.
I really don't think the kiddies embedding fonts are using fonts with wide unicode coverage, but rather stylized ones for a single (or maybe two) particular scripts. Also, glyph subsetting should be used for embedding fonts; this often avoids copyright issues on the complete font due to licenses that allow subset embedding (as if the people warezing movies cared about that anyway...). Furthermore, uuencode only increases size by about 33%. If a font is big enough that this matters it was probably waaaay to big to be embedded already... Rich
On Wed, 2008-01-02 at 22:32 -0500, Rich Felker wrote:
Furthermore, uuencode only increases size by about 33%. If a font is big enough that this matters it was probably waaaay to big to be embedded already...
What would be "too big to be embedded"? I've seen a 6 MB embedded font.
On Thu, Jan 03, 2008 at 06:11:08AM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 22:32 -0500, Rich Felker wrote:
Furthermore, uuencode only increases size by about 33%. If a font is big enough that this matters it was probably waaaay to big to be embedded already...
What would be "too big to be embedded"? I've seen a 6 MB embedded font.
I think we can all agree this is stupid, as there's no way the movie is making use of the whole 6mb of glyphs... Rich
On Jan 2, 2008, at 11:22 PM, Rich Felker wrote:
On Thu, Jan 03, 2008 at 06:11:08AM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 22:32 -0500, Rich Felker wrote:
Furthermore, uuencode only increases size by about 33%. If a font is big enough that this matters it was probably waaaay to big to be embedded already...
What would be "too big to be embedded"? I've seen a 6 MB embedded font.
I think we can all agree this is stupid, as there's no way the movie is making use of the whole 6mb of glyphs...
Rich
Yes, but unfortunately most people don't have an automatic subset tool when muxing, so it's common. CJK is really big, after all, so you can't make a subset font without knowing the exact text of the subtitles.
On Wed, Jan 02, 2008 at 06:45:44PM -0700, Loren Merritt wrote:
On Wed, 2 Jan 2008, Rich Felker wrote:
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
Extradata may happen to be identical, but subtitles can refer to "the same font" in a stricter sense. If you demux a .mkv file into separate files, a natural format is to have an audio file (or files), a video file, a .ssa/.ass file (or files) and a bunch of font files. Nobody splits video/audio tracks into separate "standard extradata" and "main content" parts.
I agree here too. Most subtitle 'codecs' already have an extradata format of their own, text-based, separate from the binary ttf data. Most likely it's the "header text" which would appear at the beginning of the subtitle file if it were flat text. So it would be rather problematic to try to munge the fonts together with this...
You can put fonts in SSA extradata, using a variant of uuencoding. I haven't seen this recently, but I have some movies using this from before matroska.
Ahh, perhaps the mkv demuxer should translate them and append them to the extradata like this. At least then it's some kind of sane, standard format. Rich
On Wed, Jan 02, 2008 at 06:49:28AM +0200, Uoti Urpala wrote:
On Wed, 2008-01-02 at 04:31 +0100, Michael Niedermayer wrote:
On Wed, Jan 02, 2008 at 03:47:40AM +0200, Uoti Urpala wrote:
On Tue, 2008-01-01 at 13:27 +0100, Michael Niedermayer wrote:
On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
Well, if the demuxer cannot know which streams need an attachment then so the matroska file cannot be remuxed with a subset of the streams unless you also include all (likely) unneeded attachments.
AFAIK this is the case - you cannot know which attachments decoders might be able to use based on container-level information only.
That would be a serious design flaw and hardly one upon which we should base our API.
API for doing what? Libavformat should provide access to the contents of Matroska attachments. What other things should the same API be generalized to do? Hypothetical attachments in other containers?
and about "Hypothetical attachments in other containers" info packets in nut cd covers in id3 looking in the mov spec i found the following: 'imag' Image font data. This atom contains two more atoms. An 'idat' atom contains compressed image data to be used to draw the text when the required fonts are not available. An 'idsc' atom contains a video sample description describing the format of the compressed image data. and the swf filespec even has a complet chapter about fonts and text So i hope it will be clear to everyone that a solution only considering mkv is problematic. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
Hi On Sat, Dec 29, 2007 at 10:38:24PM +0300, Evgeniy Stepanov wrote:
Hi,
this patch adds attachments support to mkv demuxer. They are collected in AVFormatContext::attachments. This is needed to correctly display SSA/ASS subtitles that often depend on fonts emdedded in matroska container.
just for the case that we end up deciding to add AVAttachments here are a few comments about things which would need to be fixed [...]
Index: libavformat/avformat.h =================================================================== --- libavformat/avformat.h (revision 11346) +++ libavformat/avformat.h (working copy) @@ -371,6 +371,15 @@
#define MAX_STREAMS 20
+typedef struct AVAttachment +{ + char* name; + char* mime; + uint64_t uid; + void* data; + unsigned int data_size; +} AVAttachment;
char *name char *type union value{ int64_t integer; AVRational rational; struct{ uint8_t *data; unsigned int data_size; } } what good does uid do? (IMO it should be removed) Also doxygen comments are needed for all fields explaining what they are.
+ /** * format I/O context. * New fields can be added to the end with minor version bumps. @@ -476,6 +485,9 @@ * demuxing: set by user */ enum CodecID subtitle_codec_id; + + unsigned int nb_attachments; + struct AVAttachment* attachments;
no this breaks ABI extensibility, that is we couldnt add a field to AVAttachment without breaking ABI also code passing AVAttachment to (the correct) decoders is missing [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
Hi,
this patch adds attachments support to mkv demuxer. They are collected in AVFormatContext::attachments. This is needed to correctly display SSA/ASS subtitles that often depend on fonts emdedded in matroska container.
Well, obviously, AVFormatContext.attachments is very controversial. I will try to summarize things which were pointed out, and my ideas: - Matroska has a feature called attachment. It consist in a kind of generalized archiver (think about a tar file concatenated to the Matroska file). (whether it's ugly or not is irrelevant. files exists in the wild so we need to support them) - Attachment can be any kind of file. It has a filename and a mime-type. It's commonly used to store required ttf fonts, but also jpeg/png of the poster of the movie. - Attachement may not be related to any other stream (poster of the movie), or related to one or more stream (ttf fonts for example) - Streams might be "linked" to one of the attachment (subtitle stream linked to one ttf font for example), but I have not verified if it's used in practice. We need a clean and generic solution to demux and remux this. Specificially we should try to remux this in other containers (avi, mov...) and we should be able to select which stream and which attachments we want to remux. Deductions: - We can't rely on any link between streams and attachments to deduce which attachment needs to be demuxed/remuxed. - We can't put attachments in extradata of a codec as they may not be related to any stream, and codec such as SSA alreay have some extradata. Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be: * contain one single packet * not pts * has a filename (important so that an ASS decoder can select the proper ttf based on it's name) * always demuxed before other (normal) streams (IIRC) It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC) - I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now). What do you think about this proposal ? Does it sounds like a reasonable base ? If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc... Aurel
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: [...] Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ... at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ... Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had. And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have [...] -- 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
On Thu, 3 Jan 2008 02:23:09 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: [...] Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet.
Hum... Indeed, using extradata has some advantages over normal packet...
Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
Still it has at least one drawback: applications can't decode attached pictures as a normal stream. They will need some special handling. But, well, extradata may indeed be the best solution.
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
I wonder if we really need this. It depends on what you consider a SSA decoder should do. Maybe a SSA decoder should just output some plain-text+formating (so that it can be re-encoded to another textual format), and thus it don't need the ttf file. The subtitle rendering (ttf bliting) could be done in libvo (for optimal speed) or in libavfilter (subtitle incrustation during transcoding for example). Still we need a way to get the attachments to vo/filters...
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
Indeed. But then we can either: - accept this limitation of avi/mov container - write those attachments in separate files Or even better, be able to choose for each attachement if you want it as a separate file or not. In fact it would be as simple as: let the user remux the stream he wants inside the avi, and then let him do some more invocation of ffmpeg to extract other streams in separate files using raw muxer. Aurel
On Thu, Jan 03, 2008 at 03:05:18AM +0100, Aurelien Jacobs wrote:
On Thu, 3 Jan 2008 02:23:09 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: [...] Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet.
Hum... Indeed, using extradata has some advantages over normal packet...
Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
Still it has at least one drawback: applications can't decode attached pictures as a normal stream. They will need some special handling.
one could in principle use 1 packet and set the timestamp to the first frame and the duration to the duration of the movie. In avi one could choose a framerate so that the 1 frame is as long as the whole movie i dont think this is a good idea though, iam pretty sure it would cause alot of problems
But, well, extradata may indeed be the best solution.
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
I wonder if we really need this. It depends on what you consider a SSA decoder should do.
Maybe a SSA decoder should just output some plain-text+formating (so that it can be re-encoded to another textual format), and thus it don't need the ttf file.
yes that would be ideal, it also seems that fabrice designed the subtitle system toward this (uint16_t format; /* 0 = graphics */) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
And what about stream count limit ? 20 is probably too low, I've definitely seen mkvs with more than 10 or even 15 attachments. Increasing it will break ABI and could still be not enough for some files.
On Sat, Jan 05, 2008 at 01:01:47AM +0300, Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
And what about stream count limit ? 20 is probably too low, I've definitely
MAX_STREAMS should be removed independant of the attachment stuff, a a patch replacin it by av_realloc() and local_array[s->nb_streams] is welcome [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
On Saturday 12 January 2008 17:54:09 Evgeniy Stepanov wrote:
This patch implements attachments as separate streams with extradata.
Any comment ?
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information. I fixed all those issues in the attached patch. Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ? Aurel
On Thursday 17 January 2008 03:00:26 Aurelien Jacobs wrote:
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it.
I was not 100% sure that it is safe to create av_streams at that point. The code somehow suggested that av_streams and MatroskaTracks are always kept in sync. If they are not, your variant is obviously better.
- I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
I just want to point out that it is a partial solution: ff_mkv_mime_tags surely does not contain everything that can possibly come as an attachment. For instance, "application/x-font" should also be mapped to CODEC_ID_TTF.
Evgeniy Stepanov wrote:
On Thursday 17 January 2008 03:00:26 Aurelien Jacobs wrote:
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it.
I was not 100% sure that it is safe to create av_streams at that point. The code somehow suggested that av_streams and MatroskaTracks are always kept in sync. If they are not, your variant is obviously better.
When we create MatroskaTracks, we don't have all the needed informations to create the av_streams. That's why there is a temporary storage. (and maybe because some track information which don't fit in av_stream are needed by the demuxer, but I'm not sure). I guess all of this MatroskaTracks could be simplified (removed ?), but I never gave it a deep look. Anyway, for attachments it's safe to not use MatroskaTracks.
- I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
I just want to point out that it is a partial solution: ff_mkv_mime_tags surely does not contain everything that can possibly come as an attachment.
Sure, it was not meant to be complete. It's just the types I found in 2 random mkv files. Other types can be added later (patch welcome). Aurel
On Thu, 17 Jan 2008 01:00:26 +0100 Aurelien Jacobs <aurel at gnuage.org> wrote:
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
If there is no comment about this, I will apply this patch soon (including the new CODEC_ID_TTF). Aurel
Aurelien Jacobs <aurel at gnuage.org> writes:
On Thu, 17 Jan 2008 01:00:26 +0100 Aurelien Jacobs <aurel at gnuage.org> wrote:
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
If there is no comment about this, I will apply this patch soon (including the new CODEC_ID_TTF).
I don't quite like the name "attachment", but that's probably just me. I don't have any better suggestion either, so don't let me stop you. -- M?ns Rullg?rd mans at mansr.com
On Thu, Jan 17, 2008 at 01:00:26AM +0100, Aurelien Jacobs wrote:
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
[...]
Index: libavformat/avformat.h =================================================================== --- libavformat/avformat.h (revision 11544) +++ libavformat/avformat.h (working copy) @@ -21,8 +21,8 @@ #ifndef FFMPEG_AVFORMAT_H #define FFMPEG_AVFORMAT_H
-#define LIBAVFORMAT_VERSION_INT ((52<<16)+(4<<8)+0) -#define LIBAVFORMAT_VERSION 52.4.0 +#define LIBAVFORMAT_VERSION_INT ((52<<16)+(5<<8)+0) +#define LIBAVFORMAT_VERSION 52.5.0 #define LIBAVFORMAT_BUILD LIBAVFORMAT_VERSION_INT
#define LIBAVFORMAT_IDENT "Lavf" AV_STRINGIFY(LIBAVFORMAT_VERSION) @@ -347,6 +347,9 @@
#define MAX_REORDER_DELAY 4 int64_t pts_buffer[MAX_REORDER_DELAY+1]; + + char *filename;
+ char *type;
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so
} AVStream;
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato
On Sun, 20 Jan 2008 02:56:20 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
On Thu, Jan 17, 2008 at 01:00:26AM +0100, Aurelien Jacobs wrote:
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
[...]
Index: libavformat/avformat.h =================================================================== --- libavformat/avformat.h (revision 11544) +++ libavformat/avformat.h (working copy) @@ -21,8 +21,8 @@ #ifndef FFMPEG_AVFORMAT_H #define FFMPEG_AVFORMAT_H
-#define LIBAVFORMAT_VERSION_INT ((52<<16)+(4<<8)+0) -#define LIBAVFORMAT_VERSION 52.4.0 +#define LIBAVFORMAT_VERSION_INT ((52<<16)+(5<<8)+0) +#define LIBAVFORMAT_VERSION 52.5.0 #define LIBAVFORMAT_BUILD LIBAVFORMAT_VERSION_INT
#define LIBAVFORMAT_IDENT "Lavf" AV_STRINGIFY(LIBAVFORMAT_VERSION) @@ -347,6 +347,9 @@
#define MAX_REORDER_DELAY 4 int64_t pts_buffer[MAX_REORDER_DELAY+1]; + + char *filename;
+ char *type;
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment. It is only useful to stream-copy from mkv to mkv, preserving attachments which have a mime-type not listed in ff_mkv_mime_tags[]. So I guess it's not really useful as long as ff_mkv_mime_tags[] is reasonably complete (which it is not, right now, but I will improve it). I will remove it for now.
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so
Sure. I will add doxy comments in next version of this patch (probably tomorrow). Aurel
On Sun, Jan 20, 2008 at 03:16:28AM +0100, Aurelien Jacobs wrote:
On Sun, 20 Jan 2008 02:56:20 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
On Thu, Jan 17, 2008 at 01:00:26AM +0100, Aurelien Jacobs wrote:
Evgeniy Stepanov wrote:
On Thursday 03 January 2008 04:23:09 Michael Niedermayer wrote:
On Thu, Jan 03, 2008 at 01:38:39AM +0100, Aurelien Jacobs wrote:
On Sat, 29 Dec 2007 22:38:24 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
[...]
Conclusions: - Attachment really looks like a stream itself. You can select the one you want to remux. For example the film poster would just be a jpeg stream with a single picture. The specificity of those streams would be:
* contain one single packet * not pts
Contain no packets, just one global extradata, this was proposed already. If you use normal packets there will be problems with them disapearing if a stream is split timewise or if you seek before demuxing the first packet. Iam not completely happy with this use of streams but we will need some solution and maybe its the least ugly, we will see ...
at least iam pretty sure extradata to be a better choice than 1 normal packet
* has a filename (important so that an ASS decoder can select the proper ttf based on it's name)
* always demuxed before other (normal) streams (IIRC)
extradata should be available before packets ...
It seems to me that attachment would fit pretty well, each one in its own AVStream. Does this sound reasonable ? - Here is how remuxing to other formats (avi, mov...) could work: * supported codec (jpeg poster) could be muxed as a normal JPEG stream with only one picture * ttf streams should be written in a separate file (that's the way various players expect to find ttf fonts when demuxing AVI, IIRC)
- I think the only required API modifications to support this would be: * adding AVStream.filename and maybe AVStream.id_of_link_stream. * adding CODEC_ID_TTF ? (ugly, but shouldn't cause much trouble) * adding a way to mux ttf font in a separate file (maybe use a separate muxer for this, ie. call 2 different muxers from ffmpeg. seems ugly, but I've no better idea right now).
Well, there are a few more things i think We need name / (mime) type to remux attachments (CD Cover / ? / tiff) (Fan art / image/x-photoshop / psd) There also could be other things like Author, ...
Also we need a way to get the attachments to the decoders, yes we dont have a ASS/SSA decoder but lets assume we had.
And while we can just store the streams in avi/mov, where does the filename/name/type go? if its dropped you could end up with a huge number of images and not know what each is.
What do you think about this proposal ? Does it sounds like a reasonable base ?
If it's not, the only viable alternative seems to be AVFormatContext.attachments just like in the original patch, but with some additionnal code to allow "remuxing", etc...
yes, these seem to be the 2 options we have
This patch implements attachments as separate streams with extradata.
OK. Here are things issues in this patch: - CODEC_TYPE_NB must stay at the end of the enum. - Adding attachments to AVFormatContext is probably a leftover from your previous patch. - I don't like the fake MATROSKA_TRACK_TYPE_ATTACHMENT and everything depending on it. - I don't think CODEC_ID_ATTACHMENT is of any use if it's used for every kind of attachement. CODEC_TYPE_ATTACHMENT already gives the same information.
I fixed all those issues in the attached patch.
Moreover, I tried to associate a specific CODEC_ID_* to different kind of attachements. To me, this seems like a good idea, but I would like to know what others think about it ?
[...]
Index: libavformat/avformat.h =================================================================== --- libavformat/avformat.h (revision 11544) +++ libavformat/avformat.h (working copy) @@ -21,8 +21,8 @@ #ifndef FFMPEG_AVFORMAT_H #define FFMPEG_AVFORMAT_H
-#define LIBAVFORMAT_VERSION_INT ((52<<16)+(4<<8)+0) -#define LIBAVFORMAT_VERSION 52.4.0 +#define LIBAVFORMAT_VERSION_INT ((52<<16)+(5<<8)+0) +#define LIBAVFORMAT_VERSION 52.5.0 #define LIBAVFORMAT_BUILD LIBAVFORMAT_VERSION_INT
#define LIBAVFORMAT_IDENT "Lavf" AV_STRINGIFY(LIBAVFORMAT_VERSION) @@ -347,6 +347,9 @@
#define MAX_REORDER_DELAY 4 int64_t pts_buffer[MAX_REORDER_DELAY+1]; + + char *filename;
+ char *type;
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
It is only useful to stream-copy from mkv to mkv, preserving attachments which have a mime-type not listed in ff_mkv_mime_tags[]. So I guess it's not really useful as long as ff_mkv_mime_tags[] is reasonably complete (which it is not, right now, but I will improve it). I will remove it for now.
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so
Sure. I will add doxy comments in next version of this patch (probably tomorrow).
Aurel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that. Greetings, Reimar D?ffinger
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
Still after years of working on FFmpeg, I have yet to figure out the purpose of codec_tag. In my own apps using lav*, I have never read nor set it, and everything has always worked just fine without it. I would certainly not consider using codec_tag a proper substitute for a MIME type field. There of course the issue of MIME types not having complete coverage, but that's beside the point. -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 20, 2008 at 01:40:00PM +0000, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
Still after years of working on FFmpeg, I have yet to figure out the purpose of codec_tag. In my own apps using lav*, I have never read nor set it, and everything has always worked just fine without it.
try to play a avi with XVIX or UMP4 fourcc or some really old divx or xvid anyway, codec_tag is not only there to workaround bugs during decodig but also to allow to preserve the container specific codec identifer during foobar->foobar stream copy. And to allow preserving the container specific codec identifer even between containers if both support the codec identifer. But if the target doesnt then select a correct identifer for it and the codec_id. you arent doing any transcoding IIRC ...
I would certainly not consider using codec_tag a proper substitute for a MIME type field. There of course the issue of MIME types not having complete coverage, but that's beside the point.
You misunderstand me i think, iam not objecting to a mime type field. Iam objecting to people not setting codec_tag and instead introduce new fields to do the very same. If matroska did set codec_tag then matroskas various codec identifers could often be preserved during stream copy and the same is true for attachments. With a seperate way to identify them it will need seperate (duplicated) code to handle. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 01:40:00PM +0000, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that. Still after years of working on FFmpeg, I have yet to figure out the
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...] purpose of codec_tag. In my own apps using lav*, I have never read nor set it, and everything has always worked just fine without it.
try to play a avi with XVIX or UMP4 fourcc or some really old divx or xvid anyway, codec_tag is not only there to workaround bugs during decodig but also to allow to preserve the container specific codec identifer during foobar->foobar stream copy. And to allow preserving the container specific codec identifer even between containers if both support the codec identifer. But if the target doesnt then select a correct identifer for it and the codec_id.
you arent doing any transcoding IIRC ...
I would certainly not consider using codec_tag a proper substitute for a MIME type field. There of course the issue of MIME types not having complete coverage, but that's beside the point.
You misunderstand me i think, iam not objecting to a mime type field. Iam objecting to people not setting codec_tag and instead introduce new fields to do the very same. If matroska did set codec_tag then matroskas various codec identifers could often be preserved during stream copy and the same is true for attachments. With a seperate way to identify them it will need seperate (duplicated) code to handle.
If I understand well, do we need CODEC_TYPE_ATTACHMENT at all ? Would not be CODEC_TYPE_DATA sufficient ? I think I would agree to set codec_tag to mime type if it is the way to detect types of attachment in matroska, this is IMHO in line with the API and the use of codec_tag. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
I think I would agree to set codec_tag to mime type if it is the way to detect types of attachment in matroska, this is IMHO in line with the API and the use of codec_tag.
codec_tag is an "unsigned int". How would you set that to a MIME type, which is a string? -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 20, 2008 at 04:06:31PM +0000, M?ns Rullg?rd wrote:
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
I think I would agree to set codec_tag to mime type if it is the way to detect types of attachment in matroska, this is IMHO in line with the API and the use of codec_tag.
codec_tag is an "unsigned int". How would you set that to a MIME type, which is a string?
well ... the original idea was that codec identifers would either fit in an int or a demuxer would have a table of identifiers, it needs one anyway to set codec_id, and in that case codec_tag could be a index into that table this should work with mime types too ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On Sun, 2008-01-20 at 17:22 +0100, Michael Niedermayer wrote:
the original idea was that codec identifers would either fit in an int or a demuxer would have a table of identifiers, it needs one anyway to set codec_id, and in that case codec_tag could be a index into that table this should work with mime types too ...
This would require limiting the allowed MIME types somehow. The file could have arbitrary "application/x-myprogram" MIME types. The Debian file /etc/mime.types which lists known types is 753 lines long (not every line is a separate type but most are). Would you support at least all those in the table? Or which subset?
On Sun, Jan 20, 2008 at 06:31:18PM +0200, Uoti Urpala wrote:
On Sun, 2008-01-20 at 17:22 +0100, Michael Niedermayer wrote:
the original idea was that codec identifers would either fit in an int or a demuxer would have a table of identifiers, it needs one anyway to set codec_id, and in that case codec_tag could be a index into that table this should work with mime types too ...
This would require limiting the allowed MIME types somehow. The file could have arbitrary "application/x-myprogram" MIME types. The Debian file /etc/mime.types which lists known types is 753 lines long (not every line is a separate type but most are). Would you support at least all those in the table? Or which subset?
As ive said the codec_tag system could be extended to handle abitrary strings if that is needed ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
On Sun, Jan 20, 2008 at 04:45:37PM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 01:40:00PM +0000, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
> iam against some undocumented char *type > please document precissely what it repressents and how it differs from > codec_tag, stream_codec_tag and codec_id > or even better get rid of it and use codec_tag or explain why the type > here should be special cased relative to these funny codec id strings in > matroska Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that. Still after years of working on FFmpeg, I have yet to figure out the
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...] purpose of codec_tag. In my own apps using lav*, I have never read nor set it, and everything has always worked just fine without it.
try to play a avi with XVIX or UMP4 fourcc or some really old divx or xvid anyway, codec_tag is not only there to workaround bugs during decodig but also to allow to preserve the container specific codec identifer during foobar->foobar stream copy. And to allow preserving the container specific codec identifer even between containers if both support the codec identifer. But if the target doesnt then select a correct identifer for it and the codec_id.
you arent doing any transcoding IIRC ...
I would certainly not consider using codec_tag a proper substitute for a MIME type field. There of course the issue of MIME types not having complete coverage, but that's beside the point.
You misunderstand me i think, iam not objecting to a mime type field. Iam objecting to people not setting codec_tag and instead introduce new fields to do the very same. If matroska did set codec_tag then matroskas various codec identifers could often be preserved during stream copy and the same is true for attachments. With a seperate way to identify them it will need seperate (duplicated) code to handle.
If I understand well, do we need CODEC_TYPE_ATTACHMENT at all ? Would not be CODEC_TYPE_DATA sufficient ?
ive thought the same when i saw it, but iam unsure ... ATTACHMENT is more of the single file in extradata kind, DATA is more a continuous stream with timestamps ... just my feeling ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
Hi On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be (not that mpeg-ps/ts and matroska would set codec_tag correctly ...) it causes an unimaginable mess, the whole design breaks down due to this codec_tag is intended to identify the codec in a container specific way while codec_id would be container independant we have code which lists codec_tag-codec_id pairs for each (de)muxer are you suggesting we should duplicate all that now for AVStream.type ? If the existing codec_tag system is not flexible enough improve it, dont write a new system pretending the existing one didnt exist. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
Hi Michael Niedermayer wrote:
Hi
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be
We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id. Now mp3on4 use same object type id as aac, so in that case it won't work anyway. I would agree to set codec_tag to 'esds' objecttype id if mp4 muxer is modified to correctly handle it in case of stream copy, and still where is codec_tag supposed to be put in mp4 ? 'stsd' tag or objecttype id in 'esds' ? We are creating 'isom' brand mp4. Since this is becoming a recurrent issue, I'll just forbid setting 'stsd' tag nor 'esds' objectype id to something specs does not define for 3gp/mp4. I'll apply the modifications soon.
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
Yes, mpeg-ps should set codec_tag to startcode. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
Hi
Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
Yes, mpeg-ps should set codec_tag to startcode.
There is no logical value to put there for mpeg-ps. For mpeg-ts, the codec ID from the PMT would be a natural, albeit pointless, choice. The same value is used in the MPEG-PS PSM when present, but since PSM is optional when only MPEG1/2 video and audio is present, there is no obvious choice for codec_tag. Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another. I feel sorry for all you people who were raised on AVI files. I really do... -- M?ns Rullg?rd mans at mansr.com
On Sun, 2008-01-20 at 16:05 +0000, M?ns Rullg?rd wrote:
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing. Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 16:05 +0000, M?ns Rullg?rd wrote:
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing.
Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
I consider this a design flaw in FFmpeg. I'm afraid it's well beyond correcting now, though. -- M?ns Rullg?rd mans at mansr.com
On Sun, 2008-01-20 at 18:15 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 16:05 +0000, M?ns Rullg?rd wrote:
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing.
Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
I consider this a design flaw in FFmpeg. I'm afraid it's well beyond correcting now, though.
What exactly is a design flaw? That it exports information that allows using it with codecs which FFmpeg itself does not recognize? And you'd want to "correct" that so it's impossible to identify codecs from FFmpeg demuxer output unless it's one of the codecs known by FFmpeg? That seems absurd but I don't see what else you could mean...
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 18:15 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 16:05 +0000, M?ns Rullg?rd wrote:
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing.
Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
I consider this a design flaw in FFmpeg. I'm afraid it's well beyond correcting now, though.
What exactly is a design flaw? That it exports information that allows using it with codecs which FFmpeg itself does not recognize? And you'd want to "correct" that so it's impossible to identify codecs from FFmpeg demuxer output unless it's one of the codecs known by FFmpeg? That seems absurd but I don't see what else you could mean...
No, I mean the opposite. It is impossible for a demuxer to identify an unsupported codec in a container-independent fashion. You guys really are deep in the dark... -- M?ns Rullg?rd mans at mansr.com
On Sun, 2008-01-20 at 18:38 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 18:15 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing.
Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
I consider this a design flaw in FFmpeg. I'm afraid it's well beyond correcting now, though.
What exactly is a design flaw? That it exports information that allows using it with codecs which FFmpeg itself does not recognize? And you'd want to "correct" that so it's impossible to identify codecs from FFmpeg demuxer output unless it's one of the codecs known by FFmpeg? That seems absurd but I don't see what else you could mean...
No, I mean the opposite. It is impossible for a demuxer to identify an unsupported codec in a container-independent fashion.
Where did you get "container-independent" from? I specifically talked about "exporting the container-specific codec type information". And Michael said in an earlier message "codec_tag is intended to identify the codec in a container specific way". Your reply doesn't seem to match what you're replying to at all.
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 18:38 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 18:15 +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
You cannot always interpret the value unless you know which container it is from. However you CAN know the container and in that case it's better than nothing.
Decoders can only map container-specific codec tags to FFmpeg-specific codec id values if the codec in question is known to FFmpeg (and not always even in that case). Demuxers in libavformat can still be useful even if FFmpeg does not recognize the specific codec, but that requires exporting the container-specific codec type information somehow.
I consider this a design flaw in FFmpeg. I'm afraid it's well beyond correcting now, though.
What exactly is a design flaw? That it exports information that allows using it with codecs which FFmpeg itself does not recognize? And you'd want to "correct" that so it's impossible to identify codecs from FFmpeg demuxer output unless it's one of the codecs known by FFmpeg? That seems absurd but I don't see what else you could mean...
No, I mean the opposite. It is impossible for a demuxer to identify an unsupported codec in a container-independent fashion.
Where did you get "container-independent" from?
In all other matters, Michael insists that everything in FFmpeg be independent of any particular implementation. I fail to see what's so special about the codec identifier used by the container.
I specifically talked about "exporting the container-specific codec type information". And Michael said in an earlier message "codec_tag is intended to identify the codec in a container specific way".
Well, it's not doing a very good job of that. Being an 'unsigned int', it has no chance of representing e.g. matroska codec identifiers. To be generic, it would have to be a pointer/size pair like extradata. Some people have really close horizons. -- M?ns Rullg?rd mans at mansr.com
On Sun, 2008-01-20 at 19:25 +0000, M?ns Rullg?rd wrote:
I specifically talked about "exporting the container-specific codec type information". And Michael said in an earlier message "codec_tag is intended to identify the codec in a container specific way".
Well, it's not doing a very good job of that. Being an 'unsigned int', it has no chance of representing e.g. matroska codec identifiers. To be generic, it would have to be a pointer/size pair like extradata.
That I can agree with. However none of your earlier messages in this subthread mentioned such implementation decisions. Is this all your position boils down to?
Hello, On Sun, Jan 20, 2008 at 07:25:21PM +0000, M?ns Rullg?rd wrote:
Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
On Sun, 2008-01-20 at 18:38 +0000, M?ns Rullg?rd wrote: [...]
No, I mean the opposite. It is impossible for a demuxer to identify an unsupported codec in a container-independent fashion.
Where did you get "container-independent" from?
In all other matters, Michael insists that everything in FFmpeg be independent of any particular implementation. I fail to see what's so special about the codec identifier used by the container.
Well, the special thing is as you mentioned above that it is impossible to do in a container-independent way.
I specifically talked about "exporting the container-specific codec type information". And Michael said in an earlier message "codec_tag is intended to identify the codec in a container specific way".
Well, it's not doing a very good job of that. Being an 'unsigned int', it has no chance of representing e.g. matroska codec identifiers.
e.g.? So far matroska seems like the only problematic case to me, at least among the containers we support.
To be generic, it would have to be a pointer/size pair like extradata.
That as well has a load of problems like defining a way to represent all the different places where such codec information may or may not be or the combination of (excuse if I get the names wrong) codec and stream fourcc for AVI (that people like to misuse in every way imaginable). Though of course it is possible to store all of these in a pointer/size pair but without a sane way to do it the pure possibility is not worth that much.
Some people have really close horizons.
Some people are really predictable. I'm starting to wonder if maybe you were somewhen hunted by a wild AVI or what causes that allergic reaction ;-) (you can't seriously believe we do not see AVI's metric ton of problems unless you beat it into us?...) Greetings, Reimar D?ffinger
M?ns Rullg?rd wrote:
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
Hi
Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...) Yes, mpeg-ps should set codec_tag to startcode.
There is no logical value to put there for mpeg-ps. For mpeg-ts, the codec ID from the PMT would be a natural, albeit pointless, choice. The same value is used in the MPEG-PS PSM when present, but since PSM is optional when only MPEG1/2 video and audio is present, there is no obvious choice for codec_tag.
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag. Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
Well atm decoder is considering extradata presence (and some bits) as a meaning of bistream formating (h264), dunno if it's really better. I could decide to use 'f264' as 'stsd' fourcc in mov, and use annex b bitstream formating or another one without nal escaping for example, tag would be different from 'avc1', and a way to differentiate formatting, after all mov is a generic container. It's IMHO wether only codec_tag is sufficient to identify a formating, or pair codec_tag/container info is needed.
I feel sorry for all you people who were raised on AVI files. I really do...
Im not an avi fan either ;) -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Hello, On Sun, Jan 20, 2008 at 05:42:23PM +0100, Baptiste Coudurier wrote:
M?ns Rullg?rd wrote: [...]
I feel sorry for all you people who were raised on AVI files. I really do...
Im not an avi fan either ;)
Well, I may be in a minority, but I prefer AVI for the fact that it is a mess due to evolution and some "clueless" people doing stupid out-of-spec things whereas MPEG is a mess by design without any special reason and mov and mxf are a mess by design by trying to do everything with one format and lots of inconsistent implementations by so-called "professionals". Greetings, Reimar D?ffinger
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
Hello, On Sun, Jan 20, 2008 at 05:42:23PM +0100, Baptiste Coudurier wrote:
M?ns Rullg?rd wrote: [...]
I feel sorry for all you people who were raised on AVI files. I really do...
Im not an avi fan either ;)
Well, I may be in a minority, but I prefer AVI for the fact that it is a mess due to evolution and some "clueless" people doing stupid out-of-spec things
AVI is a mess due to lack of design.
whereas MPEG is a mess by design without any special reason
I disagree about MPEG being a mess. It is perfectly suited to its intended purpose. I have never claimed it to be fully featured.
and mov and mxf are a mess by design by trying to do everything with one format and lots of inconsistent implementations by so-called "professionals".
MOV, with its derivative MP4, and MXF are indeed a mess by design. The ironic thing is that nobody in the industry likes those formats. -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
Hi
Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
Yes, mpeg-ps should set codec_tag to startcode.
There is no logical value to put there for mpeg-ps. For mpeg-ts, the codec ID from the PMT would be a natural, albeit pointless, choice. The same value is used in the MPEG-PS PSM when present, but since PSM is optional when only MPEG1/2 video and audio is present, there is no obvious choice for codec_tag.
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag.
Well fact is, the system is extreemly simple and works extreemly well in detecting buggy divx and xvid whithout false detections, at least none an alternative system would avoid. And no the demuxer has no knowledgle of the container. And hell the whole mplayer uses avi fourccs internally to identify codecs and mplayer plays many files your program doesnt, it cant as you already said you ignore codec_tag which is essential to the playback of many files.
Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
The user app can set codec_tag to 0 for the muxer or set it to a value that is valid for the container, it can do that by using the AVCodecTag table from the muxer. You shouldnt blame the API if the user app sets the codec_tag to a value which isnt valid ...
I feel sorry for all you people who were raised on AVI files. I really do...
I feel happy for you all who like mpeg with its 3 different ways to identify codecs. And then for a dozen cases reuse all ids so the streams need analyzing to identify the codec. (minor snippet of mpeg.c } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 }; unsigned char buf[8]; get_buffer(s->pb, buf, 8); url_fseek(s->pb, -8, SEEK_CUR); if(!memcmp(buf, avs_seqh, 4) && (buf[6] != 0 || buf[7] != 1)) codec_id = CODEC_ID_CAVS; else codec_id = CODEC_ID_MPEG2VIDEO; type = CODEC_TYPE_VIDEO; } else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2; ) avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras
Michael Niedermayer <michaelni at gmx.at> writes:
On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
Hi
Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
Yes, mpeg-ps should set codec_tag to startcode.
There is no logical value to put there for mpeg-ps. For mpeg-ts, the codec ID from the PMT would be a natural, albeit pointless, choice. The same value is used in the MPEG-PS PSM when present, but since PSM is optional when only MPEG1/2 video and audio is present, there is no obvious choice for codec_tag.
Based on what you say, I have to consider the entire concept of codec_tag flawed. Since the decoder does not in general (and certainly should not) know what container the data came in, it cannot know how to interpret the value of codec_tag.
Well fact is, the system is extreemly simple and works extreemly well in detecting buggy divx and xvid whithout false detections, at least none an alternative system would avoid.
System? What system?
And no the demuxer has no knowledgle of the container. ^^^^^^^ I assume you meant decoder.
And hell the whole mplayer uses avi fourccs internally to identify codecs
Well, mplayer is basically an AVI player that also happens to support a some other formats. Besides, MPlayer is hardly a good example of how to do anything whatsoever.
and mplayer plays many files your program doesnt, it cant as you already said you ignore codec_tag which is essential to the playback of many files.
Samples, please.
Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
The user app can set codec_tag to 0 for the muxer or set it to a value that is valid for the container, it can do that by using the AVCodecTag table from the muxer.
What would be the point in doing that?
You shouldnt blame the API if the user app sets the codec_tag to a value which isnt valid ...
I'm blaming the API for existing in the first place.
I feel sorry for all you people who were raised on AVI files. I really do...
I feel happy for you all who like mpeg with its 3 different ways to identify codecs. And then for a dozen cases reuse all ids so the streams need analyzing to identify the codec.
(minor snippet of mpeg.c } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 }; unsigned char buf[8]; get_buffer(s->pb, buf, 8); url_fseek(s->pb, -8, SEEK_CUR); if(!memcmp(buf, avs_seqh, 4) && (buf[6] != 0 || buf[7] != 1)) codec_id = CODEC_ID_CAVS; else codec_id = CODEC_ID_MPEG2VIDEO; type = CODEC_TYPE_VIDEO;
It's not the fault of MPEG that the Chinese chose to ignore the spec.
} else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;
It's not the fault of MPEG that whoever is behind ADX chose to ignore the spec.
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions.
Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers. This is because of fundamental misconceptions in the way AVI and VFW were originally conceived. I've discussed these at length in the past, and I don't feel inclined to repeat it all again. -- M?ns Rullg?rd mans at mansr.com
Hello, On Sun, Jan 20, 2008 at 06:35:58PM +0000, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes: [...]
} else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;
It's not the fault of MPEG that whoever is behind ADX chose to ignore the spec.
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions.
Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers.
It's not the fault of AVI that whoever is behind those chose to ignore the spec...
This is because of fundamental misconceptions in the way AVI and VFW were originally conceived. I've discussed these at length in the past, and I don't feel inclined to repeat it all again.
Obviously you forgot the part of the discussion where it came up that these misconceptions were not in the spec but actually against it... Greetings, Reimar D?ffinger
Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 06:35:58PM +0000, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes: [...]
} else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;
It's not the fault of MPEG that whoever is behind ADX chose to ignore the spec.
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions. Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers.
It's not the fault of AVI that whoever is behind those chose to ignore the spec...
Why didn't they drop avi and choose/design a correct one before hacking it ? It's either a container evolves to support more things (mov), or is being discontinued (avi), which is what MS did, but you guys wants to stick forever with it, just let it go... [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
Hello, On Sun, Jan 20, 2008 at 08:09:32PM +0100, Baptiste Coudurier wrote:
Reimar D?ffinger wrote:
On Sun, Jan 20, 2008 at 06:35:58PM +0000, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes: [...]
} else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;
It's not the fault of MPEG that whoever is behind ADX chose to ignore the spec.
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions. Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers.
It's not the fault of AVI that whoever is behind those chose to ignore the spec...
Why didn't they drop avi and choose/design a correct one before hacking it ?
Well, some hacks were just because some _players_ has stupid restrictions, how would choosing better format help (except that there are no players at all that would play it, so yes supporting outdated players is not an issue then)? Some issues are because some people did not like the spec and just decided to do it their way. That's something you can blame the spec at most partially for, and as proven all the time that affects all specs... And then a good deal of the issues are because loads of people write AVI muxers without even reading the spec. I seriously doubt that MOV or MPEG or whatever would fare even the slightest bit against this kind of "attack". Actually MPEG has enough problems to deal with the mess that so-called standards-organizations make of it... And then comes the part of true problems with AVI. Most people IMO will never come over those because they just do not need them. Nevertheless they are good reason to replace AVI. Though the question is with what? So far the only contender that is not completely laden with hacks yet is mkv, though it has its ugliness in abundance as well. And I'm not at all certain what horrors we will see if it ever reaches the usage level of AVI...
It's either a container evolves to support more things (mov), or is being discontinued (avi), which is what MS did, but you guys wants to stick forever with it, just let it go...
I don't want to stick with AVI, not at all. And in case you haven't noticed I only mocked Mans' way of excusing the problems MPEG has by excusing AVI's in the same way. Either way, attacking and defending AVI is quite pointless when the issue is actually an API issue, and the question is how to provide a way that allows a lavf user to detect and use a codec format that lavc has clue about. Greetings, Reimar D?ffinger
Il Sunday 20 January 2008 20:31:12 Reimar D?ffinger ha scritto:
And then comes the part of true problems with AVI. Most people IMO will never come over those because they just do not need them. Nevertheless they are good reason to replace AVI. Though the question is with what? So far the only contender that is not completely laden with hacks yet is mkv,
sorry but I can't accept any defense of mkv: it's _completely_ full of hacks; its own structure is a pileload of hacks. Just look at how everything has to be specially treated to be muxed in mkv. As far as I'm concerned it's almost as horrible as ogg.
though it has its ugliness in abundance as well. And I'm not at all certain what horrors we will see if it ever reaches the usage level of AVI...
surely
On Sun, Jan 20, 2008 at 06:35:58PM +0000, M?ns Rullg?rd wrote: [...]
And no the demuxer has no knowledgle of the container. ^^^^^^^ I assume you meant decoder.
yes
And hell the whole mplayer uses avi fourccs internally to identify codecs
Well, mplayer is basically an AVI player that also happens to support a some other formats. Besides, MPlayer is hardly a good example of how to do anything whatsoever.
and mplayer plays many files your program doesnt, it cant as you already said you ignore codec_tag which is essential to the playback of many files.
Samples, please.
try http://samples.mplayerhq.hu/V-codecs/UMP4/clip10-640x480-550k.avi it should look better with properly set codec_tag any fourcc=XVIX avi will work as well and show a much bigger difference but it seems theres none on mphq at least not where it should be ... and i cant find one on my disk either ... or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH) anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all files to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Similarly a muxer, whether transcoding or copying, does not know the source of the codec_tag value, and thus cannot interpret it one way or another.
The user app can set codec_tag to 0 for the muxer or set it to a value that is valid for the container, it can do that by using the AVCodecTag table from the muxer.
What would be the point in doing that?
well, some hardware players only support some codec_tags, if you choose the wrong one it simply wont play And as said above the codec_tag is critical to decoding some old xvid/divx xvix/ump4 and likely others, so it has to be preserved on stream copy
You shouldnt blame the API if the user app sets the codec_tag to a value which isnt valid ...
I'm blaming the API for existing in the first place.
You are really becoming annoying, i can accept that you dont like avi and prefer mpeg, that all fine but you should aceppt that there are people who like to be able to watch their files. codec_tag is needed for that. And irronically it would also solve the hddvd h264 problem with mpeg
I feel sorry for all you people who were raised on AVI files. I really do...
I feel happy for you all who like mpeg with its 3 different ways to identify codecs. And then for a dozen cases reuse all ids so the streams need analyzing to identify the codec.
(minor snippet of mpeg.c } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 }; unsigned char buf[8]; get_buffer(s->pb, buf, 8); url_fseek(s->pb, -8, SEEK_CUR); if(!memcmp(buf, avs_seqh, 4) && (buf[6] != 0 || buf[7] != 1)) codec_id = CODEC_ID_CAVS; else codec_id = CODEC_ID_MPEG2VIDEO; type = CODEC_TYPE_VIDEO;
It's not the fault of MPEG that the Chinese chose to ignore the spec.
} else if (startcode >= 0x1c0 && startcode <= 0x1df) { type = CODEC_TYPE_AUDIO; codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;
It's not the fault of MPEG that whoever is behind ADX chose to ignore the spec.
its not the fault of the AVI spec that random people ignore it
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions.
Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers. This is because of fundamental misconceptions in the way AVI and VFW were originally conceived. I've discussed
I just an hour ago wanted to add proper AVCodecTag tables to mpeg, guess why i didnt? Because mpeg has ten times more redundant identifers. but lets just see the code: } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { .... } else if (startcode >= 0x1c0 && startcode <= 0x1df) { .... } else if (startcode >= 0x80 && startcode <= 0x87) { .... } else if ((startcode >= 0x88 && startcode <= 0x8f) .... } else if (startcode >= 0xa0 && startcode <= 0xaf) { type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_PCM_S16BE; } else if (startcode >= 0xb0 && startcode <= 0xbf) { type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_MLP; } else if (startcode >= 0xc0 && startcode <= 0xcf) { /* Used for both AC-3 and E-AC-3 in EVOB files */ type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_AC3; } else if (startcode >= 0x20 && startcode <= 0x3f) { type = CODEC_TYPE_SUBTITLE; codec_id = CODEC_ID_DVD_SUBTITLE; } else if (startcode >= 0xfd55 && startcode <= 0xfd5f) { why has every codec such a huge range?! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
Michael Niedermayer <michaelni at gmx.at> writes:
And irronically it [codec_tag] would also solve the hddvd h264 problem with mpeg
How? Without looking inside the PES payload, it is *impossible* to distinguish these files from spec-compliant MPEG.
avi doesnt have such entertaining identifer system, but uses boring 4 character codes with some similarity to the codec name and suprisingly that anarchistic system is free of colissions while the great mpeg is full of collisions.
Well, with AVI the problem is the opposite. Every codec has a zillion different identifiers. This is because of fundamental misconceptions in the way AVI and VFW were originally conceived. I've discussed
I just an hour ago wanted to add proper AVCodecTag tables to mpeg, guess why i didnt? Because mpeg has ten times more redundant identifers. but lets just see the code: } else if (startcode >= 0x1e0 && startcode <= 0x1ef) { .... } else if (startcode >= 0x1c0 && startcode <= 0x1df) { .... } else if (startcode >= 0x80 && startcode <= 0x87) { .... } else if ((startcode >= 0x88 && startcode <= 0x8f) .... } else if (startcode >= 0xa0 && startcode <= 0xaf) { type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_PCM_S16BE; } else if (startcode >= 0xb0 && startcode <= 0xbf) { type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_MLP; } else if (startcode >= 0xc0 && startcode <= 0xcf) { /* Used for both AC-3 and E-AC-3 in EVOB files */ type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_AC3; } else if (startcode >= 0x20 && startcode <= 0x3f) { type = CODEC_TYPE_SUBTITLE; codec_id = CODEC_ID_DVD_SUBTITLE; } else if (startcode >= 0xfd55 && startcode <= 0xfd5f) {
why has every codec such a huge range?!
I know you know why, so I'm not going to bother explaining it to you. Besides, half of that code is for dealing with non-standard variants of the format. -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 20, 2008 at 08:43:21PM +0000, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
And irronically it [codec_tag] would also solve the hddvd h264 problem with mpeg
How? Without looking inside the PES payload, it is *impossible* to distinguish these files from spec-compliant MPEG.
Yes they are indistinguishable but i think only one of the 2 exists in the wild. So its not needed to distinguish them. If iam wrong and they do exist its a simple matter of not using codec_tag for detecting hddvd h.264. No harm done .. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker, user questions for the command line tools ffmpeg, ffplay, ... as well as questions about how to use libav* should be sent to the ffmpeg-user mailinglist.
On Sun, Jan 20, 2008 at 09:16:12PM +0100, Michael Niedermayer wrote:
or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH)
anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all files to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Since people tend to believe your ramblings: This is nonsense. No files are removed from the samples collection and it is Mike and Roberto that maintain it. That said, I cannot find a file named green.avi on mphq. If you feel it should be in the samples collection, upload it. Diego
Hello, On Mon, Jan 21, 2008 at 10:43:38AM +0100, Diego Biurrun wrote:
On Sun, Jan 20, 2008 at 09:16:12PM +0100, Michael Niedermayer wrote:
or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH)
anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all files to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Since people tend to believe your ramblings: This is nonsense.
Agreed. Only files from incoming are removed when the space gets tight. This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others). Greetings, Reimar Doeffinger
Reimar D?ffinger wrote:
Hello, On Mon, Jan 21, 2008 at 10:43:38AM +0100, Diego Biurrun wrote:
On Sun, Jan 20, 2008 at 09:16:12PM +0100, Michael Niedermayer wrote:
or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH)
anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all
files
to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Since people tend to believe your ramblings: This is nonsense.
Agreed. Only files from incoming are removed when the space gets tight. This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
Yes, and please stop calling us BOFH. If you continue, I'll start calling you Evil Overlord. -- M?ns Rullg?rd mans at mansr.com
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Reimar D?ffinger wrote:
Hello, On Mon, Jan 21, 2008 at 10:43:38AM +0100, Diego Biurrun wrote:
On Sun, Jan 20, 2008 at 09:16:12PM +0100, Michael Niedermayer wrote:
or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH)
anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all
files
to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Since people tend to believe your ramblings: This is nonsense.
Agreed. Only files from incoming are removed when the space gets tight.
I dont remember where all thouse disapeared files were, maybe they were in incoming maybe not. It was very long ago (probably still under arpi) when i dl them from the server ... I just thought someone would ask before deleting them, after all there were questions posted somewhere about which files to delete ...
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH. If you didnt delete them, then no need to be pissed as i didnt call you BOFH in that case ...
I'll start calling you Evil Overlord.
:)))) PS: green.avi is in incoming now [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH.
From what I've read of the BOFH, I think your criteria for lumping someone under that heading are *far* too broad... -- The Wanderer My usual .sig is on vacation while I adjust to my new computer
The Wanderer wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH.
From what I've read of the BOFH, I think your criteria for lumping someone under that heading are *far* too broad...
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to... -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd wrote:
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to...
Err, aren't you the one who walks around Linux conventions with a T-shirt along the lines of, "I have a short temper, a shotgun, and an elevated floor in the server room; don't mess with me"? -- -Mike Melanson
Mike Melanson a ?crit :
M?ns Rullg?rd wrote:
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to...
Err, aren't you the one who walks around Linux conventions with a T-shirt along the lines of, "I have a short temper, a shotgun, and an elevated floor in the server room; don't mess with me"?
I wonder how he would fare against the BOFH and his electric staples gun... -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Mike Melanson schreef:
M?ns Rullg?rd wrote:
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to...
Err, aren't you the one who walks around Linux conventions with a T-shirt along the lines of, "I have a short temper, a shotgun, and an elevated floor in the server room; don't mess with me"?
:-D -- With friendly regards, Takis -- vCard: http://issaris.org/pi.vcf PGP key: http://issaris.org/pi.key
Mike Melanson wrote:
M?ns Rullg?rd wrote:
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to...
Err, aren't you the one who walks around Linux conventions with a T-shirt along the lines of, "I have a short temper, a shotgun, and an elevated floor in the server room; don't mess with me"?
The T-shirt makes no mention of electrocutions or lifts, so there's no contradiction there. I chose my words carefully... -- M?ns Rullg?rd mans at mansr.com
On Mon, Jan 21, 2008 at 09:12:46AM -0800, Mike Melanson wrote:
M?ns Rullg?rd wrote:
I never electrocuted a consultant, nor locked the boss in the lift, if that's the sort of things you're thinking of. Didn't say I wouldn't have liked to...
Err, aren't you the one who walks around Linux conventions with a T-shirt along the lines of, "I have a short temper, a shotgun, and an elevated floor in the server room; don't mess with me"?
I was just going to say that :), but actually the precise workding is: I have a shotgun, a short temper and a raised floor in my server room... Do not trifle with me. Diego
Hello, On Mon, Jan 21, 2008 at 08:33:09AM -0500, The Wanderer wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH.
From what I've read of the BOFH, I think your criteria for lumping someone under that heading are *far* too broad...
And anyway the BOFH does not delete files, those are just the effects of lunar rays interfering and similar unusual occurrences ;-)
On Mon, Jan 21, 2008 at 02:58:19PM +0100, Reimar D?ffinger wrote:
Hello, On Mon, Jan 21, 2008 at 08:33:09AM -0500, The Wanderer wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH.
From what I've read of the BOFH, I think your criteria for lumping someone under that heading are *far* too broad...
And anyway the BOFH does not delete files, those are just the effects of lunar rays interfering and similar unusual occurrences ;-)
ahhh hmmm i see well, anyway i need these files up again, i still have these last backup floppies here, but i cant remember how to copy them could you help me dear operator ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On Mon, 21 Jan 2008 14:18:54 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
There are no cheap HDs that fit into the server. But we don't need any more diskspace at the moment. We still have plenty of free diskspace, but not everything is allocated. If i see that some partition is running out of space i usualy increase it. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
On Mon, Jan 21, 2008 at 02:36:58PM +0100, Attila Kinali wrote:
On Mon, 21 Jan 2008 14:18:54 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
There are no cheap HDs that fit into the server. But we don't
geez, use a long cable and leave it outside :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
On Mon, Jan 21, 2008 at 03:26:26PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:36:58PM +0100, Attila Kinali wrote:
On Mon, 21 Jan 2008 14:18:54 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
There are no cheap HDs that fit into the server. But we don't
geez, use a long cable and leave it outside :)
I doubt the rackspace provider will like that solution... Diego
On Mon, Jan 21, 2008 at 06:39:03PM +0100, Diego Biurrun wrote:
On Mon, Jan 21, 2008 at 03:26:26PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:36:58PM +0100, Attila Kinali wrote:
On Mon, 21 Jan 2008 14:18:54 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
There are no cheap HDs that fit into the server. But we don't
geez, use a long cable and leave it outside :)
I doubt the rackspace provider will like that solution...
You really arent the BOFH [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
Hello,
This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
I will ... Also why dont you put a really cheap and large HD in the server for incoming, its not as if that would need to be reliable ...
Well, then incoming would still be a huge and chaotic mess where nobody except a select few can find anything at all (and most have no access to). Also it is not that rare that a few GB large file ends up there.
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH. If you didnt delete them, then no need to be pissed as i didnt call you BOFH in that case ...
Well, I think there still is an old_incoming with quite a few files that nobody has an idea what they are and what purpose they had... Though I guess Diego did include that in his search.
I'll start calling you Evil Overlord.
:))))
PS: green.avi is in incoming now
Moved to samples/V-codecs/MPEG4, complain if you think that's the wrong place. And you're supposed to upload the files with a .txt file :-P Greetings, Reimar D?ffinger
On Mon, Jan 21, 2008 at 02:56:17PM +0100, Reimar D?ffinger wrote: [...
I'll start calling you Evil Overlord.
:))))
PS: green.avi is in incoming now
Moved to samples/V-codecs/MPEG4, complain if you think that's the wrong
i think V-codecs/XVID/old would be a better place
place. And you're supposed to upload the files with a .txt file :-P
hmm i did upload one, must have been the radiation from satelite debris again ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
Hello, On Mon, Jan 21, 2008 at 03:32:07PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:56:17PM +0100, Reimar D?ffinger wrote: [...
I'll start calling you Evil Overlord.
:))))
PS: green.avi is in incoming now
Moved to samples/V-codecs/MPEG4, complain if you think that's the wrong
i think V-codecs/XVID/old would be a better place
Moved. I actually had looked for an XVID directory but obviously I was too much in a hurry ;-)
On Mon, Jan 21, 2008 at 02:18:54PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH. If you didnt delete them, then no need to be pissed as i didnt call you BOFH in that case ...
The hdd crashed, many files were lost... Diego
On Mon, Jan 21, 2008 at 06:36:22PM +0100, Diego Biurrun wrote:
On Mon, Jan 21, 2008 at 02:18:54PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH. If you didnt delete them, then no need to be pissed as i didnt call you BOFH in that case ...
The hdd crashed, many files were lost...
I thought someone had backups of that? Or was that just the samples and incoming was lost back then? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
On Mon, Jan 21, 2008 at 07:26:51PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 06:36:22PM +0100, Diego Biurrun wrote:
On Mon, Jan 21, 2008 at 02:18:54PM +0100, Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:52:35AM -0000, M?ns Rullg?rd wrote:
Yes, and please stop calling us BOFH. If you continue,
Well someone apparently deleted some files, that person qualifies as BOFH. If you didnt delete them, then no need to be pissed as i didnt call you BOFH in that case ...
The hdd crashed, many files were lost...
I thought someone had backups of that? Or was that just the samples and incoming was lost back then?
I think Attila still had an image of the broken hdd, perhaps you mean that? In any case the hardware was damaged so that image was corrupted and parts could not be restored. Also, the samples collection was not terribly high on the priority list IIRC, repositories, mailing list archives etc. were more important. Diego
On Mon, 21 Jan 2008 19:26:51 +0100 Michael Niedermayer <michaelni at gmx.at> wrote:
The hdd crashed, many files were lost...
I thought someone had backups of that? Or was that just the samples and incoming was lost back then?
Actually none of it. I only made backups of the mailinglist archives and the cvs repo. I didn't had enough free disk space to backup the samples too. What we have now is what i was able to recover from the hd image i took after it crashed, though i didn't put too much energy into it. I still keep the image around. If anyone wants to try, i can put the image online, but i doubt it's worth the effort. It's reiserfs after all. Attila Kinali -- Praised are the Fountains of Shelieth, the silver harp of the waters, But blest in my name forever this stream that stanched my thirst! -- Deed of Morred
On Mon, Jan 21, 2008 at 11:52:35AM +0000, M?ns Rullg?rd wrote:
Reimar D?ffinger wrote:
On Mon, Jan 21, 2008 at 10:43:38AM +0100, Diego Biurrun wrote:
On Sun, Jan 20, 2008 at 09:16:12PM +0100, Michael Niedermayer wrote:
or old xvid like: 87fa4caf85a38d2151f4fcae6848723b green.avi (dunno if its on mphq still or deleted by BOFH)
anyway just try old divx/xvid with no divx/xvid build id in the stream many will show artifacts if the fourcc isnt passed to the decoder id search the server for you if i had a account but i wont download all files to find out if there are any left which havnt been "deleted because they work now" or whatever the excuse ...
Since people tend to believe your ramblings: This is nonsense.
Agreed. Only files from incoming are removed when the space gets tight. This is unavoidable and if you know of files in incoming you want to keep make sure they get moved to samples (ask me, Roberto, Diego, Mans, maybe some others).
Yes, and please stop calling us BOFH. If you continue, I'll start calling you Evil Overlord.
ROTFL :-))) Diego
On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
[...]
I'm a bit late in the thread, but it sounds to me like the "ideal" system would be: codec id: an enum, extracting the maximum amount of information from the container codec tag, to identify the codec. This would mean you would have several codec id's for xvid/divx4/divx5/whatever - but only for ones where it would be useful! If for example "div5" and "xvid" have absoloutely no difference in decoding workarounds, they should have the same codec id. This would be the only useful value for doing playback, and if the codec tag could not be identified to a codec id, then that means that there probably isn't a decoder for this file anyway. However, codec id should be user-forcable. codec tag: the original binary container information that the codec id was derived from, respresented in char* and length. this should only be useful for transcoding (and even then it's doubtful, probably better to use the codec-id as it is container independent), or for showing it to the user in case codec-tag -> codec-id failed. For any other uses, codec-id should probably be used. codec-tag -> codec-id tables should be container dependent, and not some huge table for everything (this could mean anything in actual implementation, it can still be a shared table, but the design is this...) Am I missing any disadvantages in such a system? - ods15
On Sun, Jan 20, 2008 at 09:34:56PM +0200, ods15 at ods15.dyndns.org wrote:
On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
[...]
I'm a bit late in the thread, but it sounds to me like the "ideal" system would be:
codec id: an enum, extracting the maximum amount of information from the container codec tag, to identify the codec. This would mean you would have several codec id's for xvid/divx4/divx5/whatever - but only for ones where it would be useful! If for example "div5" and "xvid" have absoloutely no difference in decoding workarounds, they should have the same codec id. This would be the only useful value for doing playback, and if the codec tag could not be identified to a codec id, then that means that there probably isn't a decoder for this file anyway. However, codec id should be user-forcable.
well, that is surely possible ... though you would need quite a few dummy decoders to handle the ids if people agree that they want that we surely could add these 10-15 dummy codec_ids also what codec_id would cou give the 2 h264 HDDVD / mpeg1/2 ids they would have to be distinct from MPEGVIDEO and H264. And which codec should decode it? mans wants mpeg1/2 because the spec says so everyone else wants h.264 because it is h.264 in practice [...]
codec-tag -> codec-id tables should be container dependent, and not some huge table for everything (this could mean anything in actual implementation, it can still be a shared table, but the design is this...)
see AVCodecTag and AVIn/OutputFormat.codec_tag [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote:
Hi
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be
We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id.
no it is not unclear let me quote from ISO/IEC 14496-12 ----- C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else If its not a mp4 based container, stsd is used
Now mp3on4 use same object type id as aac, so in that case it won't work anyway.
What wont work? Yes both mp3on4 and aac would have the same codec_tag but thats just what is stored in the file (and it violates the spec) the stsd of them doesnt differ either or?
I would agree to set codec_tag to 'esds' objecttype id if mp4 muxer is modified to correctly handle it in case of stream copy,
just change the muxer as well ...
and still where is codec_tag supposed to be put in mp4 ? 'stsd' tag or objecttype id in 'esds' ? We are creating 'isom' brand mp4.
see the spec, stsd is mp4v/mp4a if not its not mp4
Since this is becoming a recurrent issue, I'll just forbid setting 'stsd' tag
ok
nor 'esds' objectype id to something specs does not define for 3gp/mp4. I'll apply the modifications soon.
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote:
Hi
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
> iam against some undocumented char *type > please document precissely what it repressents and how it differs from > codec_tag, stream_codec_tag and codec_id > or even better get rid of it and use codec_tag or explain why the type > here should be special cased relative to these funny codec id strings in > matroska Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id.
no it is not unclear let me quote from ISO/IEC 14496-12 ----- C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used
Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd, so this just becomes untrue, that is if its .mp4 stsd can contain something else than "mp4v/a/t/s". This is exactly what is unclear, and maybe some other codecs allow that (thinking of jpeg2k). What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is used to define the codec. Problem is what to do when user set codec_tag and use mp4 muxer ? We set objecttype id or/and stsd tag ?
Now mp3on4 use same object type id as aac, so in that case it won't work anyway.
What wont work? Yes both mp3on4 and aac would have the same codec_tag but thats just what is stored in the file (and it violates the spec) the stsd of them doesnt differ either or?
It doesn't differ, what won't work is differentiating mp3on4 from aac based on codec_tag, and therefore being able to identify codec based on codec_tag.
I would agree to set codec_tag to 'esds' objecttype id if mp4 muxer is modified to correctly handle it in case of stream copy,
just change the muxer as well ...
and still where is codec_tag supposed to be put in mp4 ? 'stsd' tag or objecttype id in 'esds' ? We are creating 'isom' brand mp4.
see the spec, stsd is mp4v/mp4a if not its not mp4
See my previous reply. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote:
Hi
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
>> iam against some undocumented char *type >> please document precissely what it repressents and how it differs from >> codec_tag, stream_codec_tag and codec_id >> or even better get rid of it and use codec_tag or explain why the type >> here should be special cased relative to these funny codec id strings in >> matroska > Currently, *type stores the standard mime type of the attachment. so it idetifies what the attachment is ... thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id.
no it is not unclear let me quote from ISO/IEC 14496-12 ----- C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used
Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd,
Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it!
so this just becomes untrue, that is if its .mp4 stsd can contain something else than "mp4v/a/t/s". This is exactly what is unclear, and maybe some other codecs allow that (thinking of jpeg2k).
What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is used to define the codec.
Problem is what to do when user set codec_tag and use mp4 muxer ? We set objecttype id or/and stsd tag ?
objecttype id
Now mp3on4 use same object type id as aac, so in that case it won't work anyway.
What wont work? Yes both mp3on4 and aac would have the same codec_tag but thats just what is stored in the file (and it violates the spec) the stsd of them doesnt differ either or?
It doesn't differ, what won't work is differentiating mp3on4 from aac based on codec_tag, and therefore being able to identify codec based on codec_tag.
yes, thats the way it should be, codec_tag is just the identifer stored in the file, if the files has a wrong identifer codec_tag is wrong as well. One could add a special case and export another fake codec_tag but i dont see much sense in that in this case ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote:
Hi
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...] >>> iam against some undocumented char *type >>> please document precissely what it repressents and how it differs from >>> codec_tag, stream_codec_tag and codec_id >>> or even better get rid of it and use codec_tag or explain why the type >>> here should be special cased relative to these funny codec id strings in >>> matroska >> Currently, *type stores the standard mime type of the attachment. > so it idetifies what the attachment is ... > thats what codec_tag does alraedy ... Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id. no it is not unclear let me quote from ISO/IEC 14496-12
C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd,
Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it!
In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as keyword, SVC amendment looks really similar. "To enable the best visibility of, and access to, those features, and to enhance the opportunities for the interchange and interoperability of media, this standard defines a storage format for video streams compressed using AVC and using carrying within the MPEG-4 Systems Framework (ISO/IEC 14496-1:2001 and its various amendments)." "This specification defines a storage format based on, and compatible with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG 2000 file format (ISO/IEC 15444-3) among others. class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){ AVCConfigurationBox config; MPEG4ExtensionDescriptorsBox (); // optional } I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change. I see nowhere in the document the mention of 'mp4v', but document mention the possible use of MPEG-4 Systems mechanisms (object type id) Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag.
so this just becomes untrue, that is if its .mp4 stsd can contain something else than "mp4v/a/t/s". This is exactly what is unclear, and maybe some other codecs allow that (thinking of jpeg2k).
What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is used to define the codec.
Problem is what to do when user set codec_tag and use mp4 muxer ? We set objecttype id or/and stsd tag ?
objecttype id
But we loose the possibility to support other codecs not using 'mp4v' or 'mp4a' as 'stsd' tags. Well, I really think mp4 tags (stsd and object type id) should be enforced. Now considering stream copy from mp4 to mov, it is not safe to put objectype id in 'stsd', so codec_tag must be ignored and recomputed to create compliant files, and I don't feel like breaking stream copy right now. I guess the FIXME in libavformat/utils.c concerning codec tags should be fixed before any action. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Mon, Jan 21, 2008 at 11:58:50PM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote:
Hi
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: > Hello, > On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: > [...] >>>> iam against some undocumented char *type >>>> please document precissely what it repressents and how it differs from >>>> codec_tag, stream_codec_tag and codec_id >>>> or even better get rid of it and use codec_tag or explain why the type >>>> here should be special cased relative to these funny codec id strings in >>>> matroska >>> Currently, *type stores the standard mime type of the attachment. >> so it idetifies what the attachment is ... >> thats what codec_tag does alraedy ... > Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag > certainly does not. E.g. for mp4 files all kind of audio has mp4a as > codec_tag and some other things like that. the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id. no it is not unclear let me quote from ISO/IEC 14496-12
C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd,
Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it!
In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as keyword, SVC amendment looks really similar.
"To enable the best visibility of, and access to, those features, and to enhance the opportunities for the interchange and interoperability of media, this standard defines a storage format for video streams compressed using AVC and using carrying within the MPEG-4 Systems Framework (ISO/IEC 14496-1:2001 and its various amendments)." "This specification defines a storage format based on, and compatible with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG 2000 file format (ISO/IEC 15444-3) among others.
class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){ AVCConfigurationBox config; MPEG4ExtensionDescriptorsBox (); // optional }
I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change.
I see nowhere in the document the mention of 'mp4v', but document mention the possible use of MPEG-4 Systems mechanisms (object type id)
Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag.
If the only spec we have mandates avc1 then it is not variable If its not varible it cannot be changed by the user codec_tag or otherwise because otherwise files wouldnt be compliant besides the thing is a file format spec identifer not a codec identifer the "avc FILE FORMAT" spec mandates "avc1", other file format derivates of the iso format mandate differnt ones switching them is like switching between -f mp4 -f 3gp
so this just becomes untrue, that is if its .mp4 stsd can contain something else than "mp4v/a/t/s". This is exactly what is unclear, and maybe some other codecs allow that (thinking of jpeg2k).
What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is used to define the codec.
Problem is what to do when user set codec_tag and use mp4 muxer ? We set objecttype id or/and stsd tag ?
objecttype id
But we loose the possibility to support other codecs not using 'mp4v' or 'mp4a' as 'stsd' tags. Well, I really think mp4 tags
This statement just doesnt make any sense, stsd name is not a codec identifer in .mp4 its value is mandated by the specific derivative of the mp4 spec the spec specifying how to store h264 mandates avc1 it seems A spec mandating something else will almost certainly also require other chanegs like differnt NAL unit packing ...
(stsd and object type id) should be enforced.
you keep saying this but its not clear what you mean stsd is mandated by a spec setting that to codec_tag generates an invalid file. object id has many values for the same codec for example mpeg2, the muxer does not know the correct value
Now considering stream copy from mp4 to mov, it is not safe to put objectype id in 'stsd', so codec_tag must be ignored and recomputed to create compliant files, and I don't feel like breaking stream copy right now.
I guess the FIXME in libavformat/utils.c concerning codec tags should be fixed before any action.
a patch is welcome ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:58:50PM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote:
Hi
Michael Niedermayer wrote: > Hi > > On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: >> Hello, >> On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: >> [...] >>>>> iam against some undocumented char *type >>>>> please document precissely what it repressents and how it differs from >>>>> codec_tag, stream_codec_tag and codec_id >>>>> or even better get rid of it and use codec_tag or explain why the type >>>>> here should be special cased relative to these funny codec id strings in >>>>> matroska >>>> Currently, *type stores the standard mime type of the attachment. >>> so it idetifies what the attachment is ... >>> thats what codec_tag does alraedy ... >> Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag >> certainly does not. E.g. for mp4 files all kind of audio has mp4a as >> codec_tag and some other things like that. > the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt > agree with the API. And choose to set codec_tag to something else than what > it is supposed to be We already discussed this issue, it is unclear in mp4 if codec_tag is 'stsd' tag or 'esds' objecttype id. no it is not unclear let me quote from ISO/IEC 14496-12
C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd, Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it! In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as keyword, SVC amendment looks really similar.
"To enable the best visibility of, and access to, those features, and to enhance the opportunities for the interchange and interoperability of media, this standard defines a storage format for video streams compressed using AVC and using carrying within the MPEG-4 Systems Framework (ISO/IEC 14496-1:2001 and its various amendments)." "This specification defines a storage format based on, and compatible with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG 2000 file format (ISO/IEC 15444-3) among others.
class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){ AVCConfigurationBox config; MPEG4ExtensionDescriptorsBox (); // optional }
I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change.
I see nowhere in the document the mention of 'mp4v', but document mention the possible use of MPEG-4 Systems mechanisms (object type id)
Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag.
If the only spec we have mandates avc1 then it is not variable If its not varible it cannot be changed by the user codec_tag or otherwise because otherwise files wouldnt be compliant
besides the thing is a file format spec identifer not a codec identifer
This does not make any sense. "this standard defines a storage format for video streams compressed using AVC" Furthermore, you can check all mp4 with h.264, none that I have have an 'esds' atom, therefore no object type id, so how to indentify h.264 if not checking 'stsd' tag ?
the "avc FILE FORMAT" spec mandates "avc1", other file format derivates of the iso format mandate differnt ones
Is that what you call not unclear ? Besides, I have no knowledge of any other derivative mandating differente one, also: "This specification is not a standalone specification; it only specifies how AVC content shall be stored in an ISO Media File format compliant format. Therefore, this specification must always be used in the context of a concrete specification, such as the MP4 file format, derived from the ISO Media File format."
switching them is like switching between -f mp4 -f 3gp
3gp mandates the use of ISO 14496-15 for wrapping h.264.
so this just becomes untrue, that is if its .mp4 stsd can contain something else than "mp4v/a/t/s". This is exactly what is unclear, and maybe some other codecs allow that (thinking of jpeg2k).
What sould be true is "if stsd contains "mp4v/a/t/s", objecttype id is used to define the codec.
Problem is what to do when user set codec_tag and use mp4 muxer ? We set objecttype id or/and stsd tag ? objecttype id
But we loose the possibility to support other codecs not using 'mp4v' or 'mp4a' as 'stsd' tags. Well, I really think mp4 tags
This statement just doesnt make any sense, stsd name is not a codec identifer in .mp4
What are you calling .mp4 exactly ? Files conforming to which specifications, which documents ? Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ? I don't think so. Therefore 'stsd' tag name CAN BE a codec identifier in .mp4. It is stated that ISO 14496-15 defines how to wrap h.264 in any iso media derivative. According to svc amendment you can now even have 'avc1', 'avc2', 'svc1' as 'stsd' tag.
its value is mandated by the specific derivative of the mp4 spec
And ISO 14496-15 overrides it for h.264, and probably other codecs in the future. I persist to say that since you at least have 2 possible stsd tag value in mp4, stsd tag CAN BE a codec identifier.
the spec specifying how to store h264 mandates avc1 it seems
A spec mandating something else will almost certainly also require other chanegs like differnt NAL unit packing ...
(stsd and object type id) should be enforced.
you keep saying this but its not clear what you mean stsd is mandated by a spec setting that to codec_tag generates an invalid file. object id has many values for the same codec for example mpeg2, the muxer does not know the correct value
Object types for mpeg-2 corresponds to all mpeg-2 profiles. Muxer has to parse mpeg2 packet to fetch profile, and put correct object type id (not that hard imho), it should also be done when wrapping aac I must say. [...] -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Tue, Jan 22, 2008 at 01:48:07AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:58:50PM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote: > Hi > > Michael Niedermayer wrote: >> Hi >> >> On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: >>> Hello, >>> On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: >>> [...] >>>>>> iam against some undocumented char *type >>>>>> please document precissely what it repressents and how it differs from >>>>>> codec_tag, stream_codec_tag and codec_id >>>>>> or even better get rid of it and use codec_tag or explain why the type >>>>>> here should be special cased relative to these funny codec id strings in >>>>>> matroska >>>>> Currently, *type stores the standard mime type of the attachment. >>>> so it idetifies what the attachment is ... >>>> thats what codec_tag does alraedy ... >>> Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag >>> certainly does not. E.g. for mp4 files all kind of audio has mp4a as >>> codec_tag and some other things like that. >> the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt >> agree with the API. And choose to set codec_tag to something else than what >> it is supposed to be > We already discussed this issue, it is unclear in mp4 if codec_tag is > 'stsd' tag or 'esds' objecttype id. no it is not unclear let me quote from ISO/IEC 14496-12 ----- C.5 Storage of new media types There are two choices in the definition of how a new media type should be stored. First, if MPEG-4 systems constructs are desired or acceptable, then: a) a new ObjectTypeIndication should be requested and used; b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; c) the access unit format should be defined for this media. The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a sampleentry of type "mp4v". If the MPEG-4 systems layer is not suitable or otherwise not desired, then: a) a new sampleentry four-character code should be requested and used; b) any additional information needed by the decoder should be defined as boxes to be stored within the sampleentry; c) the file-format sample format should be defined for this media. Note that in the second case, the registration authority will also allocate an objecttypeindication for use in MPEG-4 systems. ----- Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the codec identifer is somewhere else
If its not a mp4 based container, stsd is used Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd, Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it! In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as keyword, SVC amendment looks really similar.
"To enable the best visibility of, and access to, those features, and to enhance the opportunities for the interchange and interoperability of media, this standard defines a storage format for video streams compressed using AVC and using carrying within the MPEG-4 Systems Framework (ISO/IEC 14496-1:2001 and its various amendments)." "This specification defines a storage format based on, and compatible with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG 2000 file format (ISO/IEC 15444-3) among others.
class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){ AVCConfigurationBox config; MPEG4ExtensionDescriptorsBox (); // optional }
I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change.
I see nowhere in the document the mention of 'mp4v', but document mention the possible use of MPEG-4 Systems mechanisms (object type id)
Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag.
If the only spec we have mandates avc1 then it is not variable If its not varible it cannot be changed by the user codec_tag or otherwise because otherwise files wouldnt be compliant
besides the thing is a file format spec identifer not a codec identifer
This does not make any sense. "this standard defines a storage format for video streams compressed using AVC"
Furthermore, you can check all mp4 with h.264, none that I have have an 'esds' atom, therefore no object type id, so how to indentify h.264 if not checking 'stsd' tag ?
you identify the specification with the stsd, that is 14496-15 for avc1 14496-15 only allows h.264 so no need for a codec identifer
the "avc FILE FORMAT" spec mandates "avc1", other file format derivates of the iso format mandate differnt ones
Is that what you call not unclear ?
Besides, I have no knowledge of any other derivative mandating differente one
"mp4a" being an example for some audio codecs in .mp4 its not == "avc1" and its written in a different spec
, also:
"This specification is not a standalone specification; it only specifies how AVC content shall be stored in an ISO Media File format compliant format. Therefore, this specification must always be used in the context of a concrete specification, such as the MP4 file format, derived from the ISO Media File format."
yes
switching them is like switching between -f mp4 -f 3gp
3gp mandates the use of ISO 14496-15 for wrapping h.264.
yes "avc1" always identifies ISO 14496-15 it thus identifies the ISO format derivative used NOT the codec, it just happens to, by coincidence identify the codec here too. codec_tag is NOT a file format derivative identifer [...]
Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ?
Huh, why should it enforce that?
I don't think so.
Therefore 'stsd' tag name CAN BE a codec identifier in .mp4.
stsd can in some cases be used to identfy the codec, you can also in some cases use the filename or extension to identify the codec but the value in stsd is NOT a generic codec identifer, that is if you just copy it per stream copy while ignoring the differences in the spec it refers too (like esds) you will have a broken file. It identifies the spec and format used to store things not directly the codec.
It is stated that ISO 14496-15 defines how to wrap h.264 in any iso media derivative.
According to svc amendment you can now even have 'avc1', 'avc2', 'svc1' as 'stsd' tag.
well i dont have that amendment so i cant comment on what exactly these other values mean [...]
the spec specifying how to store h264 mandates avc1 it seems
A spec mandating something else will almost certainly also require other chanegs like differnt NAL unit packing ...
(stsd and object type id) should be enforced.
you keep saying this but its not clear what you mean stsd is mandated by a spec setting that to codec_tag generates an invalid file. object id has many values for the same codec for example mpeg2, the muxer does not know the correct value
Object types for mpeg-2 corresponds to all mpeg-2 profiles. Muxer has to parse mpeg2 packet to fetch profile, and put correct object type id (not that hard imho), it should also be done when wrapping aac I must say.
It should be done by the AVParser not duplicated in several muxers [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
Hi Michael Niedermayer wrote:
On Tue, Jan 22, 2008 at 01:48:07AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 11:58:50PM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote:
On Mon, Jan 21, 2008 at 02:24:40AM +0100, Baptiste Coudurier wrote:
Michael Niedermayer wrote: > On Sun, Jan 20, 2008 at 04:43:05PM +0100, Baptiste Coudurier wrote: >> Hi >> >> Michael Niedermayer wrote: >>> Hi >>> >>> On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote: >>>> Hello, >>>> On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: >>>> [...] >>>>>>> iam against some undocumented char *type >>>>>>> please document precissely what it repressents and how it differs from >>>>>>> codec_tag, stream_codec_tag and codec_id >>>>>>> or even better get rid of it and use codec_tag or explain why the type >>>>>>> here should be special cased relative to these funny codec id strings in >>>>>>> matroska >>>>>> Currently, *type stores the standard mime type of the attachment. >>>>> so it idetifies what the attachment is ... >>>>> thats what codec_tag does alraedy ... >>>> Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag >>>> certainly does not. E.g. for mp4 files all kind of audio has mp4a as >>>> codec_tag and some other things like that. >>> the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt >>> agree with the API. And choose to set codec_tag to something else than what >>> it is supposed to be >> We already discussed this issue, it is unclear in mp4 if codec_tag is >> 'stsd' tag or 'esds' objecttype id. > no it is not unclear > let me quote from ISO/IEC 14496-12 > ----- > C.5 Storage of new media types > There are two choices in the definition of how a new media type should be stored. > First, if MPEG-4 systems constructs are desired or acceptable, then: > a) a new ObjectTypeIndication should be requested and used; > b) the decoderspecificinformation for this codec should be defined as an MPEG-4 descriptor; > c) the access unit format should be defined for this media. > The media then uses the MPEG-4 code-points in the file format; for example, a new video codec would use a > sampleentry of type "mp4v". > If the MPEG-4 systems layer is not suitable or otherwise not desired, then: > a) a new sampleentry four-character code should be requested and used; > b) any additional information needed by the decoder should be defined as boxes to be stored within > the sampleentry; > c) the file-format sample format should be defined for this media. > Note that in the second case, the registration authority will also allocate an objecttypeindication for use in > MPEG-4 systems. > ----- > Thus unless i misunderstand it. If its .mp4 stsd contains "mp4v/a/t/s" and the > codec identifer is somewhere else > > If its not a mp4 based container, stsd is used Even when using MPEG-4 brands (mp41,mp42), h.264 can use 'avc1' in stsd, Which spec says that? Please quote the specific part or provide a URL to that spec, id like to read it! In a draft of ISO 14496-15 AVC File format, using AVCSampleEntry as keyword, SVC amendment looks really similar.
"To enable the best visibility of, and access to, those features, and to enhance the opportunities for the interchange and interoperability of media, this standard defines a storage format for video streams compressed using AVC and using carrying within the MPEG-4 Systems Framework (ISO/IEC 14496-1:2001 and its various amendments)." "This specification defines a storage format based on, and compatible with, the ISO Base Media File format ISO/IEC 14496-12 | 15444-12), which is used by the MP4 file format (ISO/IEC 14496-14) and the Motion JPEG 2000 file format (ISO/IEC 15444-3) among others.
class AVCSampleEntry() extends VisualSampleEntry (?jvt1?){ AVCConfigurationBox config; MPEG4ExtensionDescriptorsBox (); // optional }
I guess 'jvt1' was replaced by 'avc1', SVC amendment reflect this change.
I see nowhere in the document the mention of 'mp4v', but document mention the possible use of MPEG-4 Systems mechanisms (object type id)
Besides all mp4 containing h.264 I have seen use 'avc1' as 'stsd' tag. If the only spec we have mandates avc1 then it is not variable If its not varible it cannot be changed by the user codec_tag or otherwise because otherwise files wouldnt be compliant
besides the thing is a file format spec identifer not a codec identifer This does not make any sense. "this standard defines a storage format for video streams compressed using AVC"
Furthermore, you can check all mp4 with h.264, none that I have have an 'esds' atom, therefore no object type id, so how to indentify h.264 if not checking 'stsd' tag ?
you identify the specification with the stsd, that is 14496-15 for avc1 14496-15 only allows h.264 so no need for a codec identifer
the "avc FILE FORMAT" spec mandates "avc1", other file format derivates of the iso format mandate differnt ones Is that what you call not unclear ?
Besides, I have no knowledge of any other derivative mandating differente one
"mp4a" being an example for some audio codecs in .mp4 its not == "avc1" and its written in a different spec
, also:
"This specification is not a standalone specification; it only specifies how AVC content shall be stored in an ISO Media File format compliant format. Therefore, this specification must always be used in the context of a concrete specification, such as the MP4 file format, derived from the ISO Media File format."
yes
switching them is like switching between -f mp4 -f 3gp 3gp mandates the use of ISO 14496-15 for wrapping h.264.
yes
"avc1" always identifies ISO 14496-15 it thus identifies the ISO format derivative used NOT the codec, it just happens to, by coincidence identify the codec here too.
codec_tag is NOT a file format derivative identifer
[...]
Does 14496-1 enforce the use of 'mp4v' for h.264, can you quote it ?
Huh, why should it enforce that?
I don't think so.
Therefore 'stsd' tag name CAN BE a codec identifier in .mp4.
stsd can in some cases be used to identfy the codec, you can also in some cases use the filename or extension to identify the codec
but the value in stsd is NOT a generic codec identifer, that is if you just copy it per stream copy while ignoring the differences in the spec it refers too (like esds) you will have a broken file. It identifies the spec and format used to store things not directly the codec.
It is stated that ISO 14496-15 defines how to wrap h.264 in any iso media derivative.
According to svc amendment you can now even have 'avc1', 'avc2', 'svc1' as 'stsd' tag.
well i dont have that amendment so i cant comment on what exactly these other values mean
Just remembered of SMPTE RP2025: "This document was initiated by C24 in response to the need to store VC-1 coded bitstreams in file formats derived from the ISO Base Media File Format such as the MP4 file format and the 3GPP file format." "The purpose of this specification is to define the necessary structures for the integration of VC-1 coded bitstreams in a file format that is compliant with the ISO Base Media File Format. Examples of file formats that are derived from the ISO Base Media File Format include the MP4 file format and the 3GPP file format." "6 VC1SampleEntry definition The box type of the VC1SampleEntry Box shall be 'vc-1'." Now we got 2 differents codecs using stsd tag as a codec identifier. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Mon, Jan 28, 2008 at 10:49:13AM +0100, Baptiste Coudurier wrote: [...]
Just remembered of SMPTE RP2025:
"This document was initiated by C24 in response to the need to store VC-1 coded bitstreams in file formats derived from the ISO Base Media File Format such as the MP4 file format and the 3GPP file format." "The purpose of this specification is to define the necessary structures for the integration of VC-1 coded bitstreams in a file format that is compliant with the ISO Base Media File Format. Examples of file formats that are derived from the ISO Base Media File Format include the MP4 file format and the 3GPP file format."
"6 VC1SampleEntry definition The box type of the VC1SampleEntry Box shall be 'vc-1'."
Now we got 2 differents codecs using stsd tag as a codec identifier.
Ive said it already, the stsd identifies the specification It here identifies the specification about how to store vc-1, you even quote this above: "The purpose of this specification is to define the necessary structures for the integration of VC-1 coded bitstreams in a file format that is compliant with the ISO Base Media File Format" And this is not vc-1 or avc1 but every derivation of the ISO Base Media File Format ive seen. They each define their own stsd value to identify the spec. codec_tag is not the specification identifer! If you want to we could add a spec_tag to export this information but please stop misusing codec_tag for it! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
On Sun, Jan 20, 2008 at 04:26:36PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be (not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
and if mpeg-ps where setting it, mplayer could use it do identify hddvd/h264 even if our mpeg-ps maintainer chooses to follow the mpeg-1/2 standard of mapping it to CODEC_ID_MPEGVIDEO [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
On Sun, Jan 20, 2008 at 04:43:15PM +0100, Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:26:36PM +0100, Michael Niedermayer wrote:
Hi
On Sun, Jan 20, 2008 at 10:10:50AM +0100, Reimar D?ffinger wrote:
Hello, On Sun, Jan 20, 2008 at 03:42:09AM +0100, Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
Currently, *type stores the standard mime type of the attachment.
so it idetifies what the attachment is ... thats what codec_tag does alraedy ...
Sorry to be so flameish, but no, maybe codec_id does that, but codec_tag certainly does not. E.g. for mp4 files all kind of audio has mp4a as codec_tag and some other things like that.
the mp4 demuxer is buggy, it intentionally violates the API as baptiste doesnt agree with the API. And choose to set codec_tag to something else than what it is supposed to be (not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
and if mpeg-ps where setting it, mplayer could use it do identify hddvd/h264 even if our mpeg-ps maintainer chooses to follow the mpeg-1/2 standard of mapping it to CODEC_ID_MPEGVIDEO
anyway, heres a patch to set codec_tag -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
Michael Niedermayer <michaelni at gmx.at> writes:
On Sun, Jan 20, 2008 at 04:43:15PM +0100, Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:26:36PM +0100, Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
and if mpeg-ps where setting it, mplayer could use it do identify hddvd/h264 even if our mpeg-ps maintainer chooses to follow the mpeg-1/2 standard of mapping it to CODEC_ID_MPEGVIDEO
anyway, heres a patch to set codec_tag
Index: mpeg.c =================================================================== --- mpeg.c (revision 11521) +++ mpeg.c (working copy) @@ -403,7 +403,7 @@ { MpegDemuxContext *m = s->priv_data; AVStream *st; - int len, startcode, i, type, codec_id = 0, es_type; + int len, startcode, i, type, codec_id = 0, es_type, codec_tag; int64_t pts, dts, dummy_pos; //dummy_pos is needed for the index building to work
redo: @@ -419,7 +419,10 @@ }
es_type = m->psm_es_type[startcode & 0xff]; + if(es_type <= 0) + codec_tag= MPEG_CODEC_TAG_PREFIX + startcode; if(es_type > 0){ + codec_tag= MPEG_CODEC_TAG_PREFIX + es_type + 0x200; if(es_type == STREAM_TYPE_VIDEO_MPEG1){ codec_id = CODEC_ID_MPEG2VIDEO; type = CODEC_TYPE_VIDEO; @@ -494,6 +497,7 @@ goto skip; st->codec->codec_type = type; st->codec->codec_id = codec_id; + st->codec->codec_tag = codec_tag; if (codec_id != CODEC_ID_PCM_S16BE) st->need_parsing = AVSTREAM_PARSE_FULL; found: Index: mpeg.h =================================================================== --- mpeg.h (revision 11520) +++ mpeg.h (working copy) @@ -55,6 +55,8 @@ #define STREAM_TYPE_AUDIO_AC3 0x81 #define STREAM_TYPE_AUDIO_DTS 0x8a
+#define MPEG_CODEC_TAG_PREFIX (('M'<<24) + ('P'<<16)) + static const int lpcm_freq_tab[4] = { 48000, 96000, 44100, 32000 };
/**
Rejected. That makes no sense whatsoever. You knew I'd say that, so why did you even bother with this? -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 20, 2008 at 06:29:41PM +0000, M?ns Rullg?rd wrote:
Michael Niedermayer <michaelni at gmx.at> writes:
On Sun, Jan 20, 2008 at 04:43:15PM +0100, Michael Niedermayer wrote:
On Sun, Jan 20, 2008 at 04:26:36PM +0100, Michael Niedermayer wrote:
(not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
and if mpeg-ps where setting it, mplayer could use it do identify hddvd/h264 even if our mpeg-ps maintainer chooses to follow the mpeg-1/2 standard of mapping it to CODEC_ID_MPEGVIDEO
anyway, heres a patch to set codec_tag
Index: mpeg.c =================================================================== --- mpeg.c (revision 11521) +++ mpeg.c (working copy) @@ -403,7 +403,7 @@ { MpegDemuxContext *m = s->priv_data; AVStream *st; - int len, startcode, i, type, codec_id = 0, es_type; + int len, startcode, i, type, codec_id = 0, es_type, codec_tag; int64_t pts, dts, dummy_pos; //dummy_pos is needed for the index building to work
redo: @@ -419,7 +419,10 @@ }
es_type = m->psm_es_type[startcode & 0xff]; + if(es_type <= 0) + codec_tag= MPEG_CODEC_TAG_PREFIX + startcode; if(es_type > 0){ + codec_tag= MPEG_CODEC_TAG_PREFIX + es_type + 0x200; if(es_type == STREAM_TYPE_VIDEO_MPEG1){ codec_id = CODEC_ID_MPEG2VIDEO; type = CODEC_TYPE_VIDEO; @@ -494,6 +497,7 @@ goto skip; st->codec->codec_type = type; st->codec->codec_id = codec_id; + st->codec->codec_tag = codec_tag; if (codec_id != CODEC_ID_PCM_S16BE) st->need_parsing = AVSTREAM_PARSE_FULL; found: Index: mpeg.h =================================================================== --- mpeg.h (revision 11520) +++ mpeg.h (working copy) @@ -55,6 +55,8 @@ #define STREAM_TYPE_AUDIO_AC3 0x81 #define STREAM_TYPE_AUDIO_DTS 0x8a
+#define MPEG_CODEC_TAG_PREFIX (('M'<<24) + ('P'<<16)) + static const int lpcm_freq_tab[4] = { 48000, 96000, 44100, 32000 };
/**
Rejected. That makes no sense whatsoever.
You knew I'd say that,
yes
so why did you even bother with this?
some people have their own forks of lav* ... btw, how do you plan to deal with hddvd h264? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On Sunday 20 January 2008 04:56:20 Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so [...]
* AVStream.type removed * more types added to ff_mkv_mime_tags * AVStream.filename comment added It is fine now ?
On Sat, Jan 26, 2008 at 09:13:22PM +0300, Evgeniy Stepanov wrote:
On Sunday 20 January 2008 04:56:20 Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so [...]
* AVStream.type removed * more types added to ff_mkv_mime_tags * AVStream.filename comment added
It is fine now ?
[...]
+ + /* source filename of the stream */ + char *filename;
not doxygen compatible [...]
+/* IDs in the attachments master */ +#define MATROSKA_ID_ATTACHEDFILE 0x61A7 +#define MATROSKA_ID_FILENAME 0x466E +#define MATROSKA_ID_FILEMIMETYPE 0x4660 +#define MATROSKA_ID_FILEDATA 0x465C +#define MATROSKA_ID_FILEUID 0x46AE
tabs are forbidden in svn and i cant speak for the matroska part but the libav* part looks mostly ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
On Sunday 27 January 2008 06:57:42 Michael Niedermayer wrote:
On Sat, Jan 26, 2008 at 09:13:22PM +0300, Evgeniy Stepanov wrote:
On Sunday 20 January 2008 04:56:20 Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so
[...]
* AVStream.type removed * more types added to ff_mkv_mime_tags * AVStream.filename comment added
It is fine now ?
[...]
+ + /* source filename of the stream */ + char *filename;
not doxygen compatible
[...]
+/* IDs in the attachments master */ +#define MATROSKA_ID_ATTACHEDFILE 0x61A7 +#define MATROSKA_ID_FILENAME 0x466E +#define MATROSKA_ID_FILEMIMETYPE 0x4660 +#define MATROSKA_ID_FILEDATA 0x465C +#define MATROSKA_ID_FILEUID 0x46AE
tabs are forbidden in svn
and i cant speak for the matroska part but the libav* part looks mostly ok
[...]
Fixed.
On Sun, 27 Jan 2008 15:46:09 +0300 Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
On Sunday 27 January 2008 06:57:42 Michael Niedermayer wrote:
On Sat, Jan 26, 2008 at 09:13:22PM +0300, Evgeniy Stepanov wrote:
On Sunday 20 January 2008 04:56:20 Michael Niedermayer wrote: [...]
iam against some undocumented char *type please document precissely what it repressents and how it differs from codec_tag, stream_codec_tag and codec_id or even better get rid of it and use codec_tag or explain why the type here should be special cased relative to these funny codec id strings in matroska
filename should be documented as well, and in stream type independant way like the "source filename" of the stream or so
[...]
* AVStream.type removed * more types added to ff_mkv_mime_tags * AVStream.filename comment added
It is fine now ?
[...]
+ + /* source filename of the stream */ + char *filename;
not doxygen compatible
[...]
+/* IDs in the attachments master */ +#define MATROSKA_ID_ATTACHEDFILE 0x61A7 +#define MATROSKA_ID_FILENAME 0x466E +#define MATROSKA_ID_FILEMIMETYPE 0x4660 +#define MATROSKA_ID_FILEDATA 0x465C +#define MATROSKA_ID_FILEUID 0x46AE
tabs are forbidden in svn
and i cant speak for the matroska part but the libav* part looks mostly ok
[...]
Fixed.
Fine with me. Applied. BTW: sorry, I forgot to update this patch as I promised one week ago Aurel
On Thursday 03 January 2008 02:38, Aurelien Jacobs wrote:
- Attachement may not be related to any other stream (poster of the movie), or related to one or more stream (ttf fonts for example) - Streams might be "linked" to one of the attachment (subtitle stream linked to one ttf font for example), but I have not verified if it's used in practice.
What's the practice with linked mkv files, are the "required" attachments such as fonts stored in both files or just the first?
participants (19)
-
astrange＠ithinksw.com -
attila＠kinali.ch -
aurel＠gnuage.org -
baptiste.coudurier＠smartjog.com -
dalias＠aerifal.cx -
diego＠biurrun.de -
eugeni.stepanov＠gmail.com -
inverseparadox＠comcast.net -
jknutar＠nic.fi -
lorenm＠u.washington.edu -
mans＠mansr.com -
mbardiaux＠mediaxim.be -
michaelni＠gmx.at -
mike＠multimedia.cx -
Nicola.Sabbi＠poste.it -
ods15＠ods15.dyndns.org -
Reimar.Doeffinger＠stud.uni-karlsruhe.de -
takis.issaris＠uhasselt.be -
uoti.urpala＠pp1.inet.fi