From slhomme at matroska.org Mon May 10 21:55:13 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 10 May 2010 21:55:13 +0200 Subject: [Matroska-devel] questions about SimpleBlock element In-Reply-To: References:

Message-ID: Mh, it appears I was just talking BS. SimpleBlock is in v2 *only*. And it's now listed correctly as such in the specs: http://www.matroska.org/technical/specs/index.html On Tue, Mar 9, 2010 at 6:36 PM, Steve Lhomme wrote: > Yes 1 is fine for SimpleBlock. There is no Matroska v2 yet. > If Alexnoe was correct anyway, that means only the "Invisible" flag is not > usable with v1. Which you don't need and is likely not to be used anywhere > for now. > > On Tue, Mar 9, 2010 at 5:31 PM, Matthew Heaney > wrote: > >> >> >> >> >> *From:* matroska-devel-bounces at lists.matroska.org [mailto: >> matroska-devel-bounces at lists.matroska.org] *On Behalf Of *Steve Lhomme >> *Sent:* Tuesday, 09 March, 2010 11:11 >> *To:* Discussion about the current and future development of Matroska >> *Subject:* Re: [Matroska-devel] questions about SimpleBlock element >> >> >> >> >> >> What values in the EBML Header element change to allow a SimpleBlock >> element >> to be used? Candidates are: >> >> EBML Version [42][86] >> EBML Read Version [42][F7] >> Doc Type Version [42][87] >> Doc Type Read Version [42][85] >> >> Right now my muxer is using 1 for all of these values. What value should >> I >> use to enable the use of the SimpleBlock element? >> >> >> >> 1 is correct. >> >> >> >> The Matroska File Format by Alexander Noe says (on p. 40) that: >> >> >> >> ?The following flags are only defined for Matroska v2 and can thus only be >> used in a SimpleBlock: keyframe, invisible, discardable.? >> >> >> >> What does he mean by ?Matroska v2?? Are you sure the value 1 is >> appropriate for all values in the EBML Header, if SimpleBlock elements are >> being used? >> >> >> >> Thanks, >> >> Matt >> >> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvacek1 at gmail.com Wed May 12 16:15:43 2010 From: vvacek1 at gmail.com (Vladimir Vacek) Date: Wed, 12 May 2010 16:15:43 +0200 Subject: [Matroska-devel] fast forward/backward in windows 7 native applications Message-ID: Hello, fast forward does not work in wmp and wmc (where it is quite usefull) in windows 7. I'm not 100% sure if it is h.264 or MKV issue, but it work for every avi file. Very strange thing however is that it worked for me in about 1 out of 100 files in mkv container that i tried. I looked this file in mediainfo and did not found anything special. Can you please tell me what is the issue? Thank you, Vladimir Vacek -------------- next part -------------- An HTML attachment was scrubbed... URL: From songokussj at gmx.net Sun May 16 14:58:23 2010 From: songokussj at gmx.net (Mirko Rolfes) Date: Sun, 16 May 2010 14:58:23 +0200 Subject: [Matroska-devel] Portable version of Haali Splitter and Haali Video Renderer? Message-ID: <20100516125823.179970@gmx.net> Dear Matroska developers, is it planned to create a portable version? I want to use it with The KMPlayer, but using the extracted files from the setup changes the mode to Windows 7 basic. Also if I use Haali, the video decoder from MPC-HC Standalone Filters (MPCVideoDec.ax) doesn't show that it is using DXVA. Does not Haali support DXVA? Kind regards Mirko Rolfes -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From netmonitoring at mail.ru Fri May 21 09:36:15 2010 From: netmonitoring at mail.ru (netmonitoring) Date: Fri, 21 May 2010 11:36:15 +0400 Subject: [Matroska-devel] Representation of a Matroksa file [building the right structure for the file in mkv format] Message-ID: Hello, ???????? developers team. I have a question about representation of a Matroksa file. In http://matroska.org/technical/diagram/index.html Matroska diagram shown, that sequency of structures must be: Header, Meta Seek Information, Segment Information, Track, Chapters, Clusters, Cueing, Data, Attachment, Tagging. As shown, the "Meta Seek Information" must going after "Header" and before "Segment Information". Like this sample: movie.mkv { EBML { DocType DocTypeVersion DocTypeReadVersion } Segment { SeekHead Void Info Tracks Cluster Cues } } To make it, i must reserve some space for "Meta Seek Information" before i create "Segment Information" structure, and replace reserved space with "Meta Seek Information" at the end of file. It is not convinient and perspective, because "you do not know how much space you need". Reminds the story about AVI OpenDML container memory reserving for the file size. The question is: is it neccessarily to reserve space and replace it with "Meta Seek Information" structure later or it's possible to put "Meta Seek Information" at the end of "Segment Information" without reserving space? The Matroska file structure will not be distorted? If my file structure is like this: movie.mkv { EBML { DocType DocTypeVersion DocTypeReadVersion } Segment { Info Tracks Cluster Cues SeekHead } } From slhomme at matroska.org Mon May 24 09:54:46 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 24 May 2010 09:54:46 +0200 Subject: [Matroska-devel] Fwd: WebM file validation tool In-Reply-To: References: <4BF7F67D.8030701@v2v.cc> <4BF8005F.7060808@v2v.cc> Message-ID: A lot of discussions are happening on the WebM mailing list. This one may end up removing TrackTimecodeScale from Matroska (or simply mark it as deprecated). ---------- Forwarded message ---------- From: Steve Lhomme Date: Mon, May 24, 2010 at 9:24 AM Subject: Re: WebM file validation tool To: Frank Galligan Cc: j , WebM Discussion Also the explanation seem bogus. The Cluster timecode should not be scaled by the track, otherwise that means that data from 2 tracks don't have the same time base to be muxed in the same Cluster. Given there are as many possible ways as there are channels the resulting muxing will end up being suboptimal for only 1 track combination. For the others, the audio corresponding to a video channel may end up being in a another Cluster, maybe even many Clusters away if the stream is long enough. That's terrible for playback. Wether the TrackTimecodeScale is applied during playback or during muxing, the problem is still there. After some time the actual audio timecode may be too far from the video data and b0rk the player caching resulting in jerky or loss of playback. So in the end the TrackTimecodeScale is a bad solution to a tricky (and rare) problem. On Mon, May 24, 2010 at 8:59 AM, Steve Lhomme wrote: > Hi Frank, > > A lot of Matroska readers/players can read and handle the value. But I > don't know any program that can output something else than 1.0 (the default > value). The only program that may have is mkvmerge, but I checked the code > and it doesn't. So dropping the element, even player side, could be fine. At > worse those file where it's written it can be discarded. > > The reason for TrackTimecodeScale to exist is described here: > http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale > > It > was designed when you could get the video from a framerate and then the > audio from another source (in another language) and you try to mux them > together without reencoding. Technically it's always possible to adjust the > video framerate to match the audio (although it won't look natural). It > becomes impossible when you merge more than 1 "heterogeneous" source > together. > > This is a very corner case, so much that it's not in use anywhere, and may > likely never be used. The only use is when the encoded audio doesn't get > reencoded. So maybe it can be useful for storage of a "Master", but that's > it. > > On Mon, May 24, 2010 at 3:25 AM, Frank Galligan wrote: > >> Steve, >> >> Do you know if any Matroska implementations use TrackTimecodeScale? I >> would like to submit a patch to FFmpeg but they would like to use as much of >> the same code for Webm and Matroska. >> >> Frank >> >> >> On Sat, May 22, 2010 at 12:06 PM, Steve Lhomme wrote: >> >>> On Sat, May 22, 2010 at 6:03 PM, wrote: >>> >>>> > Yup, it's called mkvalidator: >>>> > http://www.matroska.org/downloads/mkvalidator.html >>>> > >>>> > It was broken with "live streams" but I fixed it today. I haven't made >>>> a >>>> > new package though. You can always build it from SVN. >>>> > >>>> >>>> for files created with the latest patches and ffmpeg i get ERR201 >>>> is this a know problem with the current ffmpeg patches? >>>> >>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 386 in >>>> TrackEntry >>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 461 in >>>> TrackEntry >>>> >>> >>> Yes, TrackTimecodeScale is not part of webm. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwiesner at matroska.org Mon May 24 11:30:49 2010 From: cwiesner at matroska.org (Christian Wiesner) Date: Mon, 24 May 2010 11:30:49 +0200 Subject: [Matroska-devel] Fwd: WebM file validation tool In-Reply-To: References: <4BF7F67D.8030701@v2v.cc> <4BF8005F.7060808@v2v.cc> Message-ID: Is this really clever ? Why can't we leave matroska as it is, and have a WebM subset of matroska ? Christian 2010/5/24 Steve Lhomme > A lot of discussions are happening on the WebM mailing list. > This one may end up removing TrackTimecodeScale from Matroska (or simply > mark it as deprecated). > > ---------- Forwarded message ---------- > From: Steve Lhomme > Date: Mon, May 24, 2010 at 9:24 AM > Subject: Re: WebM file validation tool > To: Frank Galligan > Cc: j , WebM Discussion > > > Also the explanation seem bogus. The Cluster timecode should not be scaled > by the track, otherwise that means that data from 2 tracks don't have the > same time base to be muxed in the same Cluster. Given there are as many > possible ways as there are channels the resulting muxing will end up being > suboptimal for only 1 track combination. For the others, the audio > corresponding to a video channel may end up being in a another Cluster, > maybe even many Clusters away if the stream is long enough. That's terrible > for playback. > > Wether the TrackTimecodeScale is applied during playback or during muxing, > the problem is still there. After some time the actual audio timecode may be > too far from the video data and b0rk the player caching resulting in jerky > or loss of playback. So in the end the TrackTimecodeScale is a bad solution > to a tricky (and rare) problem. > > > On Mon, May 24, 2010 at 8:59 AM, Steve Lhomme wrote: > >> Hi Frank, >> >> A lot of Matroska readers/players can read and handle the value. But I >> don't know any program that can output something else than 1.0 (the default >> value). The only program that may have is mkvmerge, but I checked the code >> and it doesn't. So dropping the element, even player side, could be fine. At >> worse those file where it's written it can be discarded. >> >> The reason for TrackTimecodeScale to exist is described here: >> http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale >> >> It >> was designed when you could get the video from a framerate and then the >> audio from another source (in another language) and you try to mux them >> together without reencoding. Technically it's always possible to adjust the >> video framerate to match the audio (although it won't look natural). It >> becomes impossible when you merge more than 1 "heterogeneous" source >> together. >> >> This is a very corner case, so much that it's not in use anywhere, and may >> likely never be used. The only use is when the encoded audio doesn't get >> reencoded. So maybe it can be useful for storage of a "Master", but that's >> it. >> >> On Mon, May 24, 2010 at 3:25 AM, Frank Galligan wrote: >> >>> Steve, >>> >>> Do you know if any Matroska implementations use TrackTimecodeScale? I >>> would like to submit a patch to FFmpeg but they would like to use as much of >>> the same code for Webm and Matroska. >>> >>> Frank >>> >>> >>> On Sat, May 22, 2010 at 12:06 PM, Steve Lhomme wrote: >>> >>>> On Sat, May 22, 2010 at 6:03 PM, wrote: >>>> >>>>> > Yup, it's called mkvalidator: >>>>> > http://www.matroska.org/downloads/mkvalidator.html >>>>> > >>>>> > It was broken with "live streams" but I fixed it today. I haven't >>>>> made a >>>>> > new package though. You can always build it from SVN. >>>>> > >>>>> >>>>> for files created with the latest patches and ffmpeg i get ERR201 >>>>> is this a know problem with the current ffmpeg patches? >>>>> >>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 386 in >>>>> TrackEntry >>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 461 in >>>>> TrackEntry >>>>> >>>> >>>> Yes, TrackTimecodeScale is not part of webm. >>>> >>>> >>> >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpjuhel1 at free.fr Mon May 24 11:58:06 2010 From: jpjuhel1 at free.fr (Jean-Philippe JUHEL) Date: Mon, 24 May 2010 11:58:06 +0200 Subject: [Matroska-devel] haali media filter v1.10.175 Message-ID: <4BFA4DAE.1000000@free.fr> Hey, I recently install the new filter v1.10.175 in place off the old version v1.10.120.0. I notice that the H264 DXVA decoder of MPC TH does not work any more. I now oblige to active the FFMPEG H264 decoder. JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Mon May 24 12:42:20 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Mon, 24 May 2010 12:42:20 +0200 Subject: [Matroska-devel] Fwd: WebM file validation tool In-Reply-To: References: <4BF7F67D.8030701@v2v.cc> <4BF8005F.7060808@v2v.cc>

Message-ID: In this case it's about deprecating TrackTimecodeScale that is currently not in use. It's not about WebM, just cleaning the specs in general, which needs to be done anyway. And yes, we need profiles too. It could be put in an "ultimate" profile with features noone will probably ever use. On Mon, May 24, 2010 at 11:30 AM, Christian Wiesner wrote: > > Is this really clever ? > > Why can't we leave matroska as it is, and have a WebM subset of matroska ? > > Christian > > > 2010/5/24 Steve Lhomme > >> A lot of discussions are happening on the WebM mailing list. >> This one may end up removing TrackTimecodeScale from Matroska (or simply >> mark it as deprecated). >> >> ---------- Forwarded message ---------- >> From: Steve Lhomme >> Date: Mon, May 24, 2010 at 9:24 AM >> Subject: Re: WebM file validation tool >> To: Frank Galligan >> Cc: j , WebM Discussion >> >> >> Also the explanation seem bogus. The Cluster timecode should not be scaled >> by the track, otherwise that means that data from 2 tracks don't have the >> same time base to be muxed in the same Cluster. Given there are as many >> possible ways as there are channels the resulting muxing will end up being >> suboptimal for only 1 track combination. For the others, the audio >> corresponding to a video channel may end up being in a another Cluster, >> maybe even many Clusters away if the stream is long enough. That's terrible >> for playback. >> >> Wether the TrackTimecodeScale is applied during playback or during muxing, >> the problem is still there. After some time the actual audio timecode may be >> too far from the video data and b0rk the player caching resulting in jerky >> or loss of playback. So in the end the TrackTimecodeScale is a bad solution >> to a tricky (and rare) problem. >> >> >> On Mon, May 24, 2010 at 8:59 AM, Steve Lhomme wrote: >> >>> Hi Frank, >>> >>> A lot of Matroska readers/players can read and handle the value. But I >>> don't know any program that can output something else than 1.0 (the default >>> value). The only program that may have is mkvmerge, but I checked the code >>> and it doesn't. So dropping the element, even player side, could be fine. At >>> worse those file where it's written it can be discarded. >>> >>> The reason for TrackTimecodeScale to exist is described here: >>> http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale >>> >>> It >>> was designed when you could get the video from a framerate and then the >>> audio from another source (in another language) and you try to mux them >>> together without reencoding. Technically it's always possible to adjust the >>> video framerate to match the audio (although it won't look natural). It >>> becomes impossible when you merge more than 1 "heterogeneous" source >>> together. >>> >>> This is a very corner case, so much that it's not in use anywhere, and >>> may likely never be used. The only use is when the encoded audio doesn't get >>> reencoded. So maybe it can be useful for storage of a "Master", but that's >>> it. >>> >>> On Mon, May 24, 2010 at 3:25 AM, Frank Galligan wrote: >>> >>>> Steve, >>>> >>>> Do you know if any Matroska implementations use TrackTimecodeScale? I >>>> would like to submit a patch to FFmpeg but they would like to use as much of >>>> the same code for Webm and Matroska. >>>> >>>> Frank >>>> >>>> >>>> On Sat, May 22, 2010 at 12:06 PM, Steve Lhomme wrote: >>>> >>>>> On Sat, May 22, 2010 at 6:03 PM, wrote: >>>>> >>>>>> > Yup, it's called mkvalidator: >>>>>> > http://www.matroska.org/downloads/mkvalidator.html >>>>>> > >>>>>> > It was broken with "live streams" but I fixed it today. I haven't >>>>>> made a >>>>>> > new package though. You can always build it from SVN. >>>>>> > >>>>>> >>>>>> for files created with the latest patches and ffmpeg i get ERR201 >>>>>> is this a know problem with the current ffmpeg patches? >>>>>> >>>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 386 in >>>>>> TrackEntry >>>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 461 in >>>>>> TrackEntry >>>>>> >>>>> >>>>> Yes, TrackTimecodeScale is not part of webm. >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel at lists.matroska.org >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: >> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkoshevoy at sorensonmedia.com Tue May 25 22:11:09 2010 From: pkoshevoy at sorensonmedia.com (Pavel Koshevoy) Date: Tue, 25 May 2010 14:11:09 -0600 Subject: [Matroska-devel] CueBlockNumber Message-ID: <4BFC2EDD.9090609@sorensonmedia.com> Hi, I am looking for a confirmation on CueBlockNumber spec. It's default value is specified as 1. It's range is specified as not 0. I take it this means it's a base-1 index of the (simple) block within a cluster. Is that correct? Thank you, Pavel. From slhomme at matroska.org Wed May 26 17:39:54 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Wed, 26 May 2010 17:39:54 +0200 Subject: [Matroska-devel] CueBlockNumber In-Reply-To: <4BFC2EDD.9090609@sorensonmedia.com> References: <4BFC2EDD.9090609@sorensonmedia.com> Message-ID: On Tue, May 25, 2010 at 10:11 PM, Pavel Koshevoy < pkoshevoy at sorensonmedia.com> wrote: > Hi, > > I am looking for a confirmation on CueBlockNumber spec. > It's default value is specified as 1. > It's range is specified as not 0. > > I take it this means it's a base-1 index of the (simple) block within a > cluster. Is that correct? > The first (simple)block of the cluster is 1, the second is 2, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu May 27 09:21:07 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 27 May 2010 09:21:07 +0200 Subject: [Matroska-devel] About mkclean and attachment placement In-Reply-To: References: Message-ID: Hi Ben, Are you sure that all the demuxers look for attachments prior playback ? That doesn't sound efficient if there is no subtitles in the file anyway. Also seeking is only bad when streamed over a slow connection. On a local file or local network, you will not see a noticeable difference where the attachments are located. It may only have an impact when playing files from the web. And even though, it would be odd to read 3 MB of font before playback if the user is never going to chose subtitles. Steve On Thu, May 27, 2010 at 1:51 AM, Ben Danper wrote: > > Hi, > > I've been testing mkclean, it works pretty well. > > However I noticed it places attachments at the end, unlike some other > muxers. Then I found http://www.matroska.org/technical/order/index.htmlwhich suggests that attachment placement. It makes sense in general terms, > however it's based on the assumption that "Attachments are not meant to use > by default when playing the file." > > A large (the largest?) use case of attachments seems to be embedded fonts > for subtitles, which need to be read before playback starts. > > To make matters worse, demuxers that support fonts (pretty much all > demuxers used on desktop apps, at least Haali's, libavformat's, mplayer's > and VLC's) have no way to know whether the attachments contain fonts or not > beforehand. The end result is that they'll seek to the end of file if there > are any attachments. > > So I think at least font attachments should be placed at the front. It > isn't very important in the grand scheme of things but it would be a nice > touch. > > Thanks > > > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu May 27 13:22:08 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 27 May 2010 13:22:08 +0200 Subject: [Matroska-devel] About mkclean and attachment placement In-Reply-To: References:

Message-ID: The problem is "what is the goal of putting it at the front" ? If that's to avoid seeking once very far in the file, like I said locally or on aLAN, you won't notice a difference. Now on a slow connection you may see a difference. But then if you put 1 MB at the front that you are never going to use, the impact could be even worse. Imagine a 512 kbps stream on a 512 kbps connection. That would take 1024*1024 * 8 / 512000 = 16 s to load. And all that time waiting before playback can start in basic playback conditions (ie it doesn't seek over the data but read them in sequence until the next element is found). In the end I can see drawbacks for basic players but no advantage for basic or advanced players. Steve On Thu, May 27, 2010 at 1:11 PM, Ben Danper wrote: > > I checked them, all of the demuxers parse attachments as part of the header > reading process. It doesnt matter if there are subtitles or not. They all > will seek. The only demuxer that I know of that won't seek is libnestegg (to > be used on Firefox for WebM playback), which just doesn't know about > attachments at all and ignores them like any unknown element. > > I know a seek isn't a big deal but since mkclean places great effort to > pack all the headers at the beginning putting something at the end defeats > that a bit. > > Thanks for your time > > Date: Thu, 27 May 2010 09:21:07 +0200 > Subject: Re: About mkclean and attachment placement > From: slhomme at matroska.org > To: sebten at live.com > CC: matroska-devel at lists.matroska.org > > Hi Ben, > Are you sure that all the demuxers look for attachments prior playback ? > That doesn't sound efficient if there is no subtitles in the file anyway. > Also seeking is only bad when streamed over a slow connection. On a local > file or local network, you will not see a noticeable difference where the > attachments are located. It may only have an impact when playing files from > the web. And even though, it would be odd to read 3 MB of font before > playback if the user is never going to chose subtitles. > > Steve > > On Thu, May 27, 2010 at 1:51 AM, Ben Danper wrote: > > Hi, > > I've been testing mkclean, it works pretty well. > > However I noticed it places attachments at the end, unlike some other > muxers. Then I found http://www.matroska.org/technical/order/index.htmlwhich suggests that attachment placement. It makes sense in general terms, > however it's based on the assumption that "Attachments are not meant to use > by default when playing the file." > > A large (the largest?) use case of attachments seems to be embedded fonts > for subtitles, which need to be read before playback starts. > > To make matters worse, demuxers that support fonts (pretty much all > demuxers used on desktop apps, at least Haali's, libavformat's, mplayer's > and VLC's) have no way to know whether the attachments contain fonts or not > beforehand. The end result is that they'll seek to the end of file if there > are any attachments. > > So I think at least font attachments should be placed at the front. It > isn't very important in the grand scheme of things but it would be a nice > touch. > > Thanks > > > _________________________________________________________________ > Hotmail: Trusted email with powerful SPAM protection. > https://signup.live.com/signup.aspx?id=60969 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu May 27 14:04:56 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 27 May 2010 14:04:56 +0200 Subject: [Matroska-devel] About mkclean and attachment placement In-Reply-To: References:

Message-ID: well, mkclean (and mkvalidator) are there to make sure the files use the optimum choices for all sort of playback scenarios (as defined here http://www.matroska.org/technical/order/index.html). It's not because the current players decide to parse the attachments no matter what that it's best in all cases. They made that choice knowing attachments could be at the end. On Thu, May 27, 2010 at 1:54 PM, Ben Danper wrote: > > Well, if avoiding a seek to the end for advanced players isn't enough of an > advantage, then yeah, the way it is right now is fine. Note that "advanced > players" means "all players", so trying to "hide" or make them ignore > attachments placing them at the end won't work. > > Usually attachments aren't as large as 1 MB (which is much more than a > typical font plus some cover art image), and besides for files meat for > Internet playback you wouldn't use large attachments anyway (even if you > place them at the end, they'll end up read - they have to be parsed anyway > to check if there are more clusters after them, so it's just moving the > pause at the beginning to the end). > > Nonetheless it doesn't matter much, thanks anyway > > ________________________________ > > Date: Thu, 27 May 2010 13:22:08 +0200 > > Subject: Re: About mkclean and attachment placement > > From: slhomme at matroska.org > > To: sebten at live.com > > CC: matroska-devel at lists.matroska.org > > > > The problem is "what is the goal of putting it at the front" ? > > > > If that's to avoid seeking once very far in the file, like I said locally > or on aLAN, you won't notice a difference. Now on a slow connection you may > see a difference. But then if you put 1 MB at the front that you are never > going to use, the impact could be even worse. Imagine a 512 kbps stream on a > 512 kbps connection. That would take 1024*1024 * 8 / 512000 = 16 s to load. > And all that time waiting before playback can start in basic playback > conditions (ie it doesn't seek over the data but read them in sequence until > the next element is found). In the end I can see drawbacks for basic players > but no advantage for basic or advanced players. > > > > > > Steve > > > > On Thu, May 27, 2010 at 1:11 PM, Ben Danper> wrote: > > > > > > > > I checked them, all of the demuxers parse attachments as part of the > header reading process. It doesnt matter if there are subtitles or not. They > all will seek. The only demuxer that I know of that won't seek is libnestegg > (to be used on Firefox for WebM playback), which just doesn't know about > attachments at all and ignores them like any unknown element. > > > > > > > > > > I know a seek isn't a big deal but since mkclean places great effort to > pack all the headers at the beginning putting something at the end defeats > that a bit. > > > > > > > > Thanks for your time > > > > > > > > Date: Thu, 27 May 2010 09:21:07 +0200 > > > > Subject: Re: About mkclean and attachment placement > > > > From: slhomme at matroska.org > > > > To: sebten at live.com > > > > CC: matroska-devel at lists.matroska.org > > > > > > > > Hi Ben, > > > > Are you sure that all the demuxers look for attachments prior playback ? > That doesn't sound efficient if there is no subtitles in the file anyway. > > > > Also seeking is only bad when streamed over a slow connection. On a local > file or local network, you will not see a noticeable difference where the > attachments are located. It may only have an impact when playing files from > the web. And even though, it would be odd to read 3 MB of font before > playback if the user is never going to chose subtitles. > > > > > > > > > > Steve > > > > > > > > On Thu, May 27, 2010 at 1:51 AM, Ben Danper> wrote: > > > > > > > > Hi, > > > > > > > > I've been testing mkclean, it works pretty well. > > > > > > > > However I noticed it places attachments at the end, unlike some other > muxers. Then I found http://www.matroska.org/technical/order/index.htmlwhich suggests that attachment placement. It makes sense in general terms, > however it's based on the assumption that "Attachments are not meant to use > by default when playing the file." > > > > > > > > > > A large (the largest?) use case of attachments seems to be embedded fonts > for subtitles, which need to be read before playback starts. > > > > > > > > To make matters worse, demuxers that support fonts (pretty much all > demuxers used on desktop apps, at least Haali's, libavformat's, mplayer's > and VLC's) have no way to know whether the attachments contain fonts or not > beforehand. The end result is that they'll seek to the end of file if there > are any attachments. > > > > > > > > > > So I think at least font attachments should be placed at the front. It > isn't very important in the grand scheme of things but it would be a nice > touch. > > > > > > > > Thanks > > > > > > > > > > > > _________________________________________________________________ > > > > Hotmail: Trusted email with powerful SPAM protection. > > > > https://signup.live.com/signup.aspx?id=60969 > > > > _________________________________________________________________ > Hotmail: Free, trusted and rich email service. > https://signup.live.com/signup.aspx?id=60969 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Thu May 27 14:06:57 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Thu, 27 May 2010 14:06:57 +0200 Subject: [Matroska-devel] About mkclean and attachment placement In-Reply-To: References:

Message-ID: Also subtitles should be able to work without the required font. If not that means the font should be put in the Codec Private of the subtitle track and not attachments. Attachments are not supposed to be needed for playback. On the other end if you have 10 languages that use the same font it would be sub-optimal to have 10 copies in the Codec Private area. But then subtitles that require a specific font to work are broken anyway... On Thu, May 27, 2010 at 2:04 PM, Steve Lhomme wrote: > well, mkclean (and mkvalidator) are there to make sure the files use the > optimum choices for all sort of playback scenarios (as defined here > http://www.matroska.org/technical/order/index.html). It's not because the > current players decide to parse the attachments no matter what that it's > best in all cases. They made that choice knowing attachments could be at the > end. > > > On Thu, May 27, 2010 at 1:54 PM, Ben Danper wrote: > >> >> Well, if avoiding a seek to the end for advanced players isn't enough of >> an advantage, then yeah, the way it is right now is fine. Note that >> "advanced players" means "all players", so trying to "hide" or make them >> ignore attachments placing them at the end won't work. >> >> Usually attachments aren't as large as 1 MB (which is much more than a >> typical font plus some cover art image), and besides for files meat for >> Internet playback you wouldn't use large attachments anyway (even if you >> place them at the end, they'll end up read - they have to be parsed anyway >> to check if there are more clusters after them, so it's just moving the >> pause at the beginning to the end). >> >> Nonetheless it doesn't matter much, thanks anyway >> >> ________________________________ >> > Date: Thu, 27 May 2010 13:22:08 +0200 >> > Subject: Re: About mkclean and attachment placement >> > From: slhomme at matroska.org >> > To: sebten at live.com >> > CC: matroska-devel at lists.matroska.org >> > >> > The problem is "what is the goal of putting it at the front" ? >> > >> > If that's to avoid seeking once very far in the file, like I said >> locally or on aLAN, you won't notice a difference. Now on a slow connection >> you may see a difference. But then if you put 1 MB at the front that you are >> never going to use, the impact could be even worse. Imagine a 512 kbps >> stream on a 512 kbps connection. That would take 1024*1024 * 8 / 512000 = 16 >> s to load. And all that time waiting before playback can start in basic >> playback conditions (ie it doesn't seek over the data but read them in >> sequence until the next element is found). In the end I can see drawbacks >> for basic players but no advantage for basic or advanced players. >> > >> > >> > Steve >> > >> > On Thu, May 27, 2010 at 1:11 PM, Ben Danper> wrote: >> > >> > >> > >> > I checked them, all of the demuxers parse attachments as part of the >> header reading process. It doesnt matter if there are subtitles or not. They >> all will seek. The only demuxer that I know of that won't seek is libnestegg >> (to be used on Firefox for WebM playback), which just doesn't know about >> attachments at all and ignores them like any unknown element. >> > >> > >> > >> > >> > I know a seek isn't a big deal but since mkclean places great effort to >> pack all the headers at the beginning putting something at the end defeats >> that a bit. >> > >> > >> > >> > Thanks for your time >> > >> > >> > >> > Date: Thu, 27 May 2010 09:21:07 +0200 >> > >> > Subject: Re: About mkclean and attachment placement >> > >> > From: slhomme at matroska.org >> > >> > To: sebten at live.com >> > >> > CC: matroska-devel at lists.matroska.org >> > >> > >> > >> > Hi Ben, >> > >> > Are you sure that all the demuxers look for attachments prior playback ? >> That doesn't sound efficient if there is no subtitles in the file anyway. >> > >> > Also seeking is only bad when streamed over a slow connection. On a >> local file or local network, you will not see a noticeable difference where >> the attachments are located. It may only have an impact when playing files >> from the web. And even though, it would be odd to read 3 MB of font before >> playback if the user is never going to chose subtitles. >> > >> > >> > >> > >> > Steve >> > >> > >> > >> > On Thu, May 27, 2010 at 1:51 AM, Ben Danper> wrote: >> > >> > >> > >> > Hi, >> > >> > >> > >> > I've been testing mkclean, it works pretty well. >> > >> > >> > >> > However I noticed it places attachments at the end, unlike some other >> muxers. Then I found http://www.matroska.org/technical/order/index.htmlwhich suggests that attachment placement. It makes sense in general terms, >> however it's based on the assumption that "Attachments are not meant to use >> by default when playing the file." >> > >> > >> > >> > >> > A large (the largest?) use case of attachments seems to be embedded >> fonts for subtitles, which need to be read before playback starts. >> > >> > >> > >> > To make matters worse, demuxers that support fonts (pretty much all >> demuxers used on desktop apps, at least Haali's, libavformat's, mplayer's >> and VLC's) have no way to know whether the attachments contain fonts or not >> beforehand. The end result is that they'll seek to the end of file if there >> are any attachments. >> > >> > >> > >> > >> > So I think at least font attachments should be placed at the front. It >> isn't very important in the grand scheme of things but it would be a nice >> touch. >> > >> > >> > >> > Thanks >> > >> > >> > >> > >> > >> > _________________________________________________________________ >> > >> > Hotmail: Trusted email with powerful SPAM protection. >> > >> > https://signup.live.com/signup.aspx?id=60969 >> > >> >> _________________________________________________________________ >> Hotmail: Free, trusted and rich email service. >> https://signup.live.com/signup.aspx?id=60969 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr2017 at hotmail.com Fri May 28 06:42:17 2010 From: dr2017 at hotmail.com (dan r) Date: Fri, 28 May 2010 00:42:17 -0400 Subject: [Matroska-devel] MP4 problems Message-ID: The latest build seems to be causing problems with MP4 videos, particularly with players like Winamp. Mainly it's when pausing the videos then restarting they almost always skip back several seconds, sometimes minutes. Anyone else experiencing this? It's happening in all the OSs I've tested, including Windows 7. As much as I wanted the WebM support I've reinstalled a prior version because I need the MP4s working properly. From cmorve69 at yahoo.es Sat May 29 11:08:01 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Sat, 29 May 2010 11:08:01 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version Message-ID: A VLC compiled against 0.8.1/0.7.8 and running with 0.9.0/0.8.0 segfaults when opening a matroska file. For reproducibility purposes lets say it fails with http://matroska.free.fr/samples/anamorphic/starwars10MB-1.mkv, but happens with all the files I tried. Compile the same VLC against 0.9.0/0.8.0 and there is no problem. Should I change the soname in the openSUSE package (if so, to what? I'm not sure about how will you name libebml2) or this can be fixed? The backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb49dc910 (LWP 16059)] libebml::EbmlMaster::ReadData (this=0x15e0860, input=..., ReadFully=18) at /usr/src/debug/libebml-0.8.0/src/EbmlMaster.cpp:172 172 input.setFilePointer(GetSize(), seek_current); Current language: auto The current source language is "auto; currently c++". (gdb) bt #0 libebml::EbmlMaster::ReadData (this=0x15e0860, input=..., ReadFully=18) at /usr/src/debug/libebml-0.8.0/src/EbmlMaster.cpp:172 #1 0x00007fffd9f45b61 in EbmlParser::Get (this=0x9d36b0) at Ebml_parser.cpp:173 #2 0x00007fffd9f44600 in demux_sys_t::AnalyseAllSegmentsFound (this=0x15dfef0, p_demux=, p_estream=, b_initial=) at demux.cpp:107 #3 0x00007fffd9f33039 in Open (p_this=0x9d3598) at mkv.cpp:117 #4 0x00007ffff796a2e3 in __module_need (p_this=0x9d3598, psz_capability=, psz_name=, b_strict=) at modules/modules.c:581 #5 0x00007ffff7927a35 in __demux_New (p_obj=0x7fffb49dbc88, psz_access=0xc

, psz_demux=, psz_path=, s=, out=0x0, b_quick=false) at input/demux.c:167 #6 0x00007ffff793778d in InputSourceInit (p_input=0x9cf2e8, in=0x9cff10, psz_mrl=0x9d5e80 "/home/reddwarf/test/starwars10MB-1.mkv", psz_forced_demux=) at input/input.c:2602 #7 0x00007ffff793886b in Init (p_input=0x9cf2e8) at input/input.c:1177 #8 0x00007ffff793b7a5 in Run (p_this=) at input/input.c:540 #9 0x00007ffff79707e4 in thread_entry (data=) at misc/threads.c:1093 #10 0x00007ffff76cd65d in start_thread () from /lib64/libpthread.so.0 #11 0x00007ffff743ce1d in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () And, for what is worth, here is the differences in the vlc binaries that openSUSE's build-compare script detects: compare orig/vlc-noX-1.0.6-2.pm.2.3.x86_64.rpm new/vlc-noX-1.0.6-2.pm.2.3.x86_64.rpm /usr/lib64/vlc/demux/libmkv_plugin.so differs in assembler output --- /tmp/tmp.J1RpX9mHjD 2010-05-29 10:57:12.676422882 +0200 +++ /tmp/tmp.LURQDwuOjX 2010-05-29 10:57:14.113547826 +0200 @@ -224,6 +224,11 @@ pushq $something jmpq <_init + ofs> +_ZN7libebml19EDocTypeReadVersionC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + _ZNSt8ios_base4InitC1Ev at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -479,6 +484,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska10KaxNextUIDC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + _ZN14chapter_item_c15PublishChaptersER13input_title_tRii at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -509,6 +519,16 @@ pushq $something jmpq <_init + ofs> +_ZN7libebml11EbmlElementD2Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + +_ZN11libmatroska22KaxContentCompSettingsC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + _ZN10EbmlParser12IsTopPresentEPN7libebml11EbmlElementE at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -564,6 +584,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska16KaxSegmentFamilyC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + _ZNK11demux_sys_t13IsUsedSegmentER18matroska_segment_c at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -619,6 +644,11 @@ pushq $something jmpq <_init + ofs> +_ZN7libebml8EDocTypeC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + __stream_UrlNew at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -699,6 +729,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska13KaxSegmentUIDC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + memmove at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -879,6 +914,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska21KaxChapterProcessDataC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + sysfs_get_device_attributes at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -919,6 +959,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska21KaxChapterTranslateIDC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + strncpy at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -1029,6 +1074,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska10KaxPrevUIDC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + fwrite at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -1044,6 +1094,11 @@ pushq $something jmpq <_init + ofs> +_ZN11libmatroska24KaxChapterProcessPrivateC1Ev at plt: + jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> + pushq $something + jmpq <_init + ofs> + __stream_MemoryNew at plt: jmpq *offset(%rip) # <_ZTVN7libebml10IOCallbackE + ofs> pushq $something @@ -2040,9 +2095,9 @@ mov %rbp,%rdi mov offset(%r8),%r12 callq *offset(%r14) - mov offset(%rax),%edi mov (%rax),%edx - cmp offset(%r12),%edi + mov offset(%r12),%rdi + cmp %rdi,offset(%rax) jne <_ZN18matroska_segment_c4SeekElll + ofs> cmp (%r12),%edx jne <_ZN18matroska_segment_c4SeekElll + ofs> @@ -2078,14 +2133,13 @@ pop %r14 pop %r15 retq - nop jle <_ZN18matroska_segment_c4SeekElll + ofs> cltq - mov offset(%rbx),%r10 - mov offset(%rbp),%r11 + mov offset(%rbx),%r11 + mov offset(%rbp),%r10 dec %rax shl $something,%rax - cmp %r11,offset(%r10,%rax,1) + cmp %r10,offset(%r11,%rax,1) jge <_ZN18matroska_segment_c4SeekElll + ofs> jmp <_ZN18matroska_segment_c4SeekElll + ofs> nop @@ -2212,12 +2266,12 @@ lea offset(%rbp,%rax,1),%rdx mov offset(%rdx),%rbp mov offset(%rdx),%r14 - mov offset(%rbx),%r11 + mov offset(%rbx),%r10 lea offset(%rsp),%rdx mov $something,%esi xor %eax,%eax - mov offset(%r11),%r10 - mov offset(%r10),%rdi + mov offset(%r10),%r11 + mov offset(%r11),%rdi callq mov $something,%edi mov %rbp,%rax @@ -6992,8 +7046,8 @@ nop nop -_ZNK7libebml11EbmlElementltERKS0_: - mov $something,%eax +_ZNK7libebml11EbmlElement7GetSizeEv: + mov offset(%rdi),%rax retq nop nop @@ -7005,6 +7059,7 @@ nop nop nop + nop _ZNK7libebml11EbmlElement7IsDummyEv: xor %eax,%eax @@ -7055,8 +7110,8 @@ nop nop -_ZNK7libebml10EbmlBinary7GetSizeEv: - mov offset(%rdi),%rax +_ZNK7libebml10EbmlBinary14IsDefaultValueEv: + xor %eax,%eax From moritz at bunkus.org Sun May 30 11:11:58 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 30 May 2010 11:11:58 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: References: Message-ID: <201005301111.59065.moritz@bunkus.org> Hey, On Saturday 29 May 2010 11:08:01 Cristian Morales Vega wrote: > Should I change the soname in the openSUSE package (if so, to what? > I'm not sure about how will you name libebml2) or this can be fixed? This will not be fixed. As a matter of fact the next release due in the next couple of days will probably be binary incompatible as well. So if you can wait another week you should probably not release libebml 0.8.0/libmatroska 0.9.0 now in order not to have to change the soname twice. The libebml 2 that Steve Lhomme is working on is a complete rewrite in C. Maybe it'll be named something else in the file system entirely (e.g. libcebml ?). This has not been decided yet. Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From cmorve69 at yahoo.es Sun May 30 11:23:31 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Sun, 30 May 2010 11:23:31 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: <201005301111.59065.moritz@bunkus.org> References: <201005301111.59065.moritz@bunkus.org> Message-ID: 2010/5/30 Moritz Bunkus : > Hey, > > On Saturday 29 May 2010 11:08:01 Cristian Morales Vega wrote: > >> Should I change the soname in the openSUSE package (if so, to what? >> I'm not sure about how will you name libebml2) or this can be fixed? > > This will not be fixed. As a matter of fact the next release due in the > next couple of days will probably be binary incompatible as well. So if > you can wait another week you should probably not release libebml > 0.8.0/libmatroska 0.9.0 now in order not to have to change the soname > twice. No problem. But can I expect the next release to directly build libraries with a different soname? It's not a difficult patch in the distro-side, but if just for the sake of cross-distro compatibility it would be better if you directly released something with a new soname. Also, is this something exceptional or should I never expect binary compatibility between libebml/libmatroska releases? From slhomme at matroska.org Sun May 30 12:10:19 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 30 May 2010 12:10:19 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: <201005301111.59065.moritz@bunkus.org> References: <201005301111.59065.moritz@bunkus.org> Message-ID: I often refer to it as libebml2 (currently 0.9.7 or something like that). I suppose a linux package would be libebml2-0.9.7 For the new libs that are incompatible, I suspect any C++ lib in general that has API additions is binary incompatible. Isn't there a way to tell a package is incompatible with the previous version ? Package dependencies are also there to avoid mismatch. On Sun, May 30, 2010 at 11:11 AM, Moritz Bunkus wrote: > Hey, > > On Saturday 29 May 2010 11:08:01 Cristian Morales Vega wrote: > > > Should I change the soname in the openSUSE package (if so, to what? > > I'm not sure about how will you name libebml2) or this can be fixed? > > This will not be fixed. As a matter of fact the next release due in the > next couple of days will probably be binary incompatible as well. So if > you can wait another week you should probably not release libebml > 0.8.0/libmatroska 0.9.0 now in order not to have to change the soname > twice. > > The libebml 2 that Steve Lhomme is working on is a complete rewrite in > C. Maybe it'll be named something else in the file system entirely > (e.g. libcebml ?). This has not been decided yet. > > Regards, > Mosu > > -- > If Darl McBride was in charge, he'd probably make marriage > unconstitutional too, since clearly it de-emphasizes the commercial > nature of normal human interaction, and probably is a major impediment > to the commercial growth of prostitution. - Linus Torvalds > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slhomme at matroska.org Sun May 30 12:12:24 2010 From: slhomme at matroska.org (Steve Lhomme) Date: Sun, 30 May 2010 12:12:24 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: References: <201005301111.59065.moritz@bunkus.org> Message-ID: On Sun, May 30, 2010 at 11:23 AM, Cristian Morales Vega wrote: > 2010/5/30 Moritz Bunkus : > > Hey, > > > > On Saturday 29 May 2010 11:08:01 Cristian Morales Vega wrote: > > > >> Should I change the soname in the openSUSE package (if so, to what? > >> I'm not sure about how will you name libebml2) or this can be fixed? > > > > This will not be fixed. As a matter of fact the next release due in the > > next couple of days will probably be binary incompatible as well. So if > > you can wait another week you should probably not release libebml > > 0.8.0/libmatroska 0.9.0 now in order not to have to change the soname > > twice. > > No problem. But can I expect the next release to directly build > libraries with a different soname? It's not a difficult patch in the > distro-side, but if just for the sake of cross-distro compatibility it > would be better if you directly released something with a new soname. > It's possible to change the .soname although programs that currently depend on libmatroska will have to update their build system too. Also if the goal is to have old and new versions co-exist, shouldn't the headers be in separate dirs too ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at bunkus.org Sun May 30 12:24:39 2010 From: moritz at bunkus.org (Moritz Bunkus) Date: Sun, 30 May 2010 12:24:39 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: References:

Message-ID: <201005301224.39552.moritz@bunkus.org> Hey, On Sunday 30 May 2010 12:12:24 Steve Lhomme wrote: > It's possible to change the .soname although programs that currently > depend on libmatroska will have to update their build system too. Also > if the goal is to have old and new versions co-exist, shouldn't the > headers be in separate dirs too ? As far as I know you don't have to change anything in the app's build system. You usually link against "-lmatroska -lebml", and you have symlinks libebml.so pointing to the currently active one, e.g. libebml.so.2. The linker embeds the full library name, so upon execution it is looking for libebml.so.2 so you can change the symlink after linking without breaking existing applications. For example: [0 mosu at tionne ~] ls -l /usr/lib/libQtCore.so* lrwxrwxrwx 1 root root 18 2010-05-25 11:43 /usr/lib/libQtCore.so -> libQtCore.so.4.6.2 lrwxrwxrwx 1 root root 18 2010-05-25 11:43 /usr/lib/libQtCore.so.4 -> libQtCore.so.4.6.2 lrwxrwxrwx 1 root root 18 2010-05-25 11:44 /usr/lib/libQtCore.so.4.6 -> libQtCore.so.4.6.2 -rw-r--r-- 1 root root 2630464 2010-04-14 07:42 /usr/lib/libQtCore.so.4.6.2 The headers' installation directory won't have to be changed either. The C version libebml2 is different matter. Regards, Mosu -- If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution. - Linus Torvalds From cmorve69 at yahoo.es Sun May 30 13:03:26 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Sun, 30 May 2010 13:03:26 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: References: <201005301111.59065.moritz@bunkus.org> Message-ID: 2010/5/30 Steve Lhomme : > I often refer to it as libebml2 (currently 0.9.7 or something like that). I > suppose a linux package would be libebml2-0.9.7 > For the new libs that are incompatible, I suspect any C++ lib in general > that has API additions is binary incompatible. Isn't there a way to tell a > package is incompatible with the previous version ? Package dependencies are > also there to avoid mismatch. Ulrich Drepper, glibc maintainer, wrote a good article about all this: "How to Write Shared Libraries". It is available at http://people.redhat.com/drepper/, under ELF section. He also developed a symbol versioning scheme, available since glibc 2.1, that allows what you ask for (http://people.redhat.com/drepper/symbol-versioning). But "How to Write Shared Libraries" is the document to read, in there it's explained not just the Linux way but also other schemes like the Solaris one: http://people.redhat.com/drepper/dsohowto.pdf (chapter 3: "Maintianing APIs and ABIs") Quick explanation for Linux: For libebml 0.8.1 what it's expected is: libebml.so libebml.so.0 libebml.so.0.8 libebml.so.0.8.1 libebml.so.0.8.1 being the real file and all the others symlinks to it. And the soname being libebml.so.0. To the linker you give "-lebml", so it can find always the library. But it reads the soname and adds a DT_NEEDED entry to the binary with the content libebml.so.0. Now at load time the libebml.so.0 is the file that is searched for. Now after 0.8.1: A bugfix release, without API additions, should be "0.8.2". A release with API additions should be "0.9.0". A release that breaks binary compatibility should be "1.0.0". When you break the binary compatibility the distro packager will create: - A libebml0 package with libebml.so.0, libebml.so.0.8 and libebml.so.0.8.1 - A libebml1 package with libebml.so.1, libebml.so.1.0 and libebml.so.1.0.0 - A libebml-devel package with libebml.so (a symlink to libebml.so.1.0.0) and the headers of version 1.0.0. So new packages will be only compiled against the new version (you don't want new users to continue using the old version), but old binaries compiled against the old version will continue to work. The headers should be in /usr/include/ebml for all 0.x.y releases. You don't need to version the headers dir with minor and micro versions since only one version (the latest) will be installed at the same time. But if you are going to provide an all new API for libebml2 then yes, the headers should be versioned (/usr/include/ebml2). Every binary compiled with version z.x will run with version z.y if y > x. Since it's expected that after compilation the user will upgrade the libraries but never downgrade them this is enough. But you are correct in that a binary compiled with version 0.9.0 could not work if at runtime there is version 0.8.1. And the error will not be detected until the program fails. What Drepper added with its symbol versioning scheme is support to NEVER break the binary compatibility. You can change the interface with a new version, but you can create a library that provides both the new and the old interfaces, and at runtime the binaries will get the correct interface. The thing is that the scheme is pretty complex, not supported in other Unixes and so has not been used a lot (I think nowhere outside of glibc). Still, you can use that versioning scheme in a simple way so that binaries compiled against libebml 0.8.1 will refuse to start if at runtime there is only libebml 0.8.0 and the binary uses a new function added in 0.8.1. That's it, a way to know if the library is new enough (notice that if you compile against 0.8.1 but your program doesn't uses any new function it will still work with 0.8.0 at runtime). The best part is that since the RPM build system analyzes binaries to add automatically dependencies (I don't explicitly say man requires libc, RPM sees that in the binary) the minor required version of the libraries will be also added if symbol versioning is used. See mkvtoolnix: $ rpm -q --requires mkvtoolnix libebml >= 0.8.0 libmatroska >= 0.9.0 ... libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libebml.so.0()(64bit) ... libmatroska.so.0()(64bit) ... It was compiled with libebml 0.8.0 and libmatroska 0.9.0. But since them don't use symbol versioning rpm just added "libebml.so.0()(64bit)" and "libmatroska.so.0()(64bit)", I had to manually add the "libebml >= 0.8.0" and "libmatroska >= 0.9.0" requirement. And it was compiled against glibc 2.10.1, but it didn't used any function added after glibc 2.4. Since glibc uses symbol versioning rpm automatically added the "libc.so.6(GLIBC_2.4)(64bit)" requirement. Again, "How to Write Shared Libraries" of Drepper is THE document to read. From cmorve69 at yahoo.es Sun May 30 13:27:42 2010 From: cmorve69 at yahoo.es (Cristian Morales Vega) Date: Sun, 30 May 2010 13:27:42 +0200 Subject: [Matroska-devel] libmatroska/ebml 0.9.0/0.8.0 is binary incompatible with previous version In-Reply-To: <201005301224.39552.moritz@bunkus.org> References:

<201005301224.39552.moritz@bunkus.org> Message-ID: 2010/5/30 Moritz Bunkus : > Hey, > > On Sunday 30 May 2010 12:12:24 Steve Lhomme wrote: > >> It's possible to change the .soname although programs that currently >> depend on libmatroska will have to update their build system too. Also >> if the goal is to have old and new versions co-exist, shouldn't the >> headers be in separate dirs too ? > > As far as I know you don't have to change anything in the app's build > system. You usually link against "-lmatroska -lebml", and you have > symlinks libebml.so pointing to the currently active one, > e.g. libebml.so.2. The linker embeds the full library name, so upon > execution it is looking for libebml.so.2 so you can change the symlink > after linking without breaking existing applications. For example: > > [0 mosu at tionne ~] ls -l /usr/lib/libQtCore.so* > lrwxrwxrwx 1 root root ? ? ?18 2010-05-25 11:43 /usr/lib/libQtCore.so -> libQtCore.so.4.6.2 > lrwxrwxrwx 1 root root ? ? ?18 2010-05-25 11:43 /usr/lib/libQtCore.so.4 -> libQtCore.so.4.6.2 > lrwxrwxrwx 1 root root ? ? ?18 2010-05-25 11:44 /usr/lib/libQtCore.so.4.6 -> libQtCore.so.4.6.2 > -rw-r--r-- 1 root root 2630464 2010-04-14 07:42 /usr/lib/libQtCore.so.4.6.2 > > The headers' installation directory won't have to be changed either. > > The C version libebml2 is different matter. True. To summarize, what I would like: - For libebml2/libmatroska2 Use symbol versioning - For libebml/libmatroska I suppose it will be deprecated once libebml2/libmatroska2 is released (soon?), so don't worry about symbol versioning now. If you have the policy of not thinking about binary compatibility at all it's ok, but make that clear. Don't name the library libebml.so.0.8.1, with soname libebml.so.0; but libebml-0.8.1.so, with soname libebml-0.8.1.so. If you are going to try to maintain binary compatibility change the soname when it breaks. So next version should have soname libebml.so.1 or libebml.so.2 (in case some distro already changed the soname). From chanyuhao at hotmail.com Mon May 31 13:40:25 2010 From: chanyuhao at hotmail.com (Thomas Chan) Date: Mon, 31 May 2010 11:40:25 +0000 Subject: [Matroska-devel] Is there any royalty or license fee for splitter or demux implementation? Message-ID: Hi, If I would like to implement a MKV splitter or demux, will there be any royalty or license fee for commercial use? I will not do any extension to the format but only do a demux to split out the video and audio data in the MKV files. Best regards, Thomas _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwiesner at matroska.org Mon May 31 14:27:05 2010 From: cwiesner at matroska.org (Christian Wiesner) Date: Mon, 31 May 2010 14:27:05 +0200 Subject: [Matroska-devel] Is there any royalty or license fee for splitter or demux implementation? In-Reply-To: References: Message-ID: Hi, the specs of matroska are in the public domain, meaning they belong to everybody. As long as you don't use any existing code for your demuxer, you are fully free to program your own spiltter. In such case, no royalty fee will apply. However, should you plan to use one of the many existing demuxers, you have to get in contact with the author of the program to see if he will charge you for that or not. Will you code your own splitter/demuxer ? Or do you plan to use existing software ? Christian project admin 2010/5/31 Thomas Chan > Hi, > > > > If I would like to implement a MKV splitter or demux, will there be any > royalty or license fee for commercial use? > > I will not do any extension to the format but only do a demux to split out > the video and audio data in the MKV files. > > > > Best regards, > > Thomas > > ------------------------------ > The New Busy is not the too busy. Combine all your e-mail accounts with > Hotmail. Get busy. > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel at lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: