subhandler-devel Mailing List for subhandler
Status: Alpha
Brought to you by:
jsanchez
Menu
▾
▴
subhandler-devel — Development of subhandler
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-25 08:04:33
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: R. B. <ro...@pa...> - 2004-01-15 04:09:49
|
I've recently been adding SVCD and CVD subtitle handling in VideoLan's vlc client. I started with subhandler which ahs been extremely helpful. Although I'm not totally finished with this, folks might be interested in looking or trying the code. In some small ways, it may be a tad cleaner; some duplicated code has been made into a macros or a procedures. One thing that I think has been a win has been taking out the color palette encoding and using an underlying YUV format. When trying to scale to counteract the scaling effects of scaled chromas like YUY2 or I420, having individual pixel entries helps I think. The routine that does the scaling I think is pretty simple and seems to work well. It scales down and works for aspect ratios between 1/2 and 1 (the inverse of say 4:3 or 16:9) where you combine at most 3 linear pixels into one. In vlc I've noticed as alluded to above that for YUY2 or I420 formats I've had to reverse scale the subtitles (e.g. 3:4 for a 4:3 aspect ratio). However for the RGB formats, no scaling should be done. I looked at the subhandler code and I don't see if it has to deal with the problem as well. (It does look like there is a bug somewhere in subhandler at the ends of the lines of the boundaries of the subtitles. Perhaps the next line data is bleading through.) One bad thing about vlc in its current form, is that there really isn't a image library that I can use to do the blending. Nothing as simple as what you do in xine and say put pixel with color c at postion x/y. In fact I'm not sure there are *simple* routines exposed in the the core to say convert YUV to RGB. (There are some *complicated*, not very well documented, and not exposed routines or macros though.) So alas I've had to write code blend in all the different chromas and that's been tough going. Anyway, to close. If folks have nice non-proprietary subtitle test cases - e.g. subtitles in different colors, maybe with different transparancies I'd appreciate of learning. Of course I could over time create such, but I'd rather be coding and not possibly recreating work that others might have. Thanks |
|
From: Julio <j.s...@te...> - 2003-12-09 23:53:25
|
El s=E1b, 06-12-2003 a las 13:15, R. Bernstein escribi=F3: > A structure in xine-lib's metronom.h has seems to have changed. I > needed to make the following small patch to spuogt_decoder.c to get it > to compile. The metronom.h version I was compiling against has CVS id > 1.56 from around Nov 20, 2003. (This puts it between xine-lib 1-rc2 and > xine-lib 1-rc3). I see. I will try this patch. I think a new release of xine-libspuogt is needed (there are a couple of changes on CVS that are needed too to compile with later xine-lib versions). >=20 > ______________________________________________________________________ > Also, I've recently patched xine-lib's mpeg demuxer (demux_mpeg.c) so > it will filter out SVCD and CVD streams. Previously this was done in > both the demux_mpeg_block.c and demux_mpeg_pes.c demuxers. If one > plays a MPEG file outside of VCD demux_mpeg.c is used. Great, I found the same and raised it on xine-devel, only I don't quite remember what was the conclusion on the role of demux_mpeg_pes vs. demux_mpeg, I seem to remember one was thought to be redundant. > One last small thing. I use autoconf 2.55 and this works with that. So > I'd appreciate if the AC_PREREQ in configure.ac were bumped back to > 2.55 (from 2.57). If it works, it's OK with me. It's just that I am using 2.57 and did not know whether it was compatible with earlier versions. Thanks, Julio |
|
From: R. B. <ro...@pa...> - 2003-12-06 12:15:19
|
A structure in xine-lib's metronom.h has seems to have changed. I needed to make the following small patch to spuogt_decoder.c to get it to compile. The metronom.h version I was compiling against has CVS id 1.56 from around Nov 20, 2003. (This puts it between xine-lib 1-rc2 and xine-lib 1-rc3). |
|
From: Julio S. <jsa...@us...> - 2003-10-27 12:18:17
|
El s=E1b, 25-10-2003 a las 13:48, Laurent Pinchart escribi=F3: > So basically you're reimplementing GObject from the glib ? No at all, GObject is much more ambitious. If I had the most remote thoughts of reinventing that, I would leave for C++ right away. I have just defined a minimal set of conventions and macros that help in writing the different modules. Deliberately I want to avoid going overboard with it. This project is not about building object-oriented frameworks. What about using GObject? I am not sure what to think of it. I have the feeling that either I did not understand its purpose or that their desire to avoid C++ took them too far. In other words, if GObject is the answer, I probably did not understand the question. Is there a sample, small application or tutorial, that showcases its use? Everytime I read the reference documentation I feel overwhelmed and I don't feel it like something I would willingly use. > Why do we need to store pointers to the class and instance methods in the= =20 > class object instance ? Can't we call the methods explicitely like in=20 > glib/gtk+ ? Only pointers to the virtual methods must be stored in the cl= ass=20 > object instance. Economy of concepts. Since virtual functions are unavoidable, we treat them all like that for implementation purposes. Calling the functions directly require, except from the same class, name mangling that we get rid of too this way. Notice that this is nothing like GObject, the object model is implemented mostly by syntactic sugar, no run-time evaluation of inter-class relationships (the model is "early binding").=20 So the ability to call a method depends on its syntactic visibility and it is determined at compile-time, this provides a limited type-checking at compile-time that avoids some mistakes. In fact, I do not see an easy way to have correct inheritance of classes that are not accessed by pointers (I cannot even imaginge how C++ achieves it). I see no problem in accesing methods directly from the class they are defined in. It's good for private methods that are not meant to be visible or refinable: it let us hide their definition. But going beyond that requires special-casing public methods and having a different calling convention for each. Again, this has to be simple to use and maintain. If this goes too far, I think we are better off moving to C++. > I don't like the idea of having an initialized field in the class. Wouldn= 't it=20 > be better to use an accessor function ? Something like Good idea, consider it done. I mean it, it is already in. I implemented your suggestion and has made the thing cleaner. Before that, the class had to be a global struct (since it was needed everywhere). Now it is hidden. We incur the cost of an additional function call everytime a class method is invoked, but there is a benefit for it. On the other hand, I have found that class initialization requires some thinking. Let me explain why initialization there is not sufficient. Suppose a program that reads input in an unknown format and produces output in some other format. Say: subhandler -i input.srt -o output.sub -oformat microdvd \ --timeshift=3D+34s where we want to convert from SRT to MicroDVD format while correcting the time of each subtitle by 34 seconds. There has to be a way to create an object of a class chosen from a set of possibilities we do not know beforehand and that tne choice can be somehow described with a string (like --oformat above or maybe some kind of URL, MRL or similar) or determined from the data itself. Hardwiring the set of choices makes subsetting difficult, so each format has to register somehow its presence (e.g. it could provide a set of file extensions understood, a pattern to look for in the input or some other selector method plus some constructor that would return an object of the that class). I have a similar case with demultiplexing subtitles where I did not want to hardwire the set of substream types that can appear inside an MPEG stream. Forgive me for not elaborating this further, suffice to say that there is the need of making an initialization call per class and that doing it at the accessor is too late. That initialization call can be combined with _init_class, but it could be kept separate. In any case, the program may need to make a call to initialize_subhandler or somesuch that I find regrettable. Is there any method to have something called at program start time in C? In Ada this would be trivial, though. Even Perl would make this easy. > about defining wrapper methods to them ? We could even inline the wrapper= =20 > methods. I am not sure to understand what you suggest. Those wrapper methods, how would they be named? I mean, if I have a virtual method called destroy and I have and object obj, what would be the syntax to call that method? And how would it be implemented? > I don't have a lot of experience with gtk+, so I don't really care, but I= =20 > think that it will be easier to attract developpers if we stick to a the = gtk+=20 > coding rules. So can you suggest a naming scheme for classes? Just dropping underscores? Or should we reorder things in the process? For instance, how would you rename the following classes? Subhandler_IO_MPEG Subhandler_Subtitle_Bitmap Subhandler_Stream_CVD I'd like to get this settled soon, since I do not want to start committing to CVS with names that are *known* to change. Regards, Julio |
|
From: Laurent P. <lau...@sk...> - 2003-10-25 12:05:17
|
> > What is a Subhandler_Object ? What kind of methods and/or properties will
> > it hold ?
>
> It contains mostly artifacts of the class-system implementation. Each
So basically you're reimplementing GObject from the glib ?
> object instance contains a pointer to a class descriptor (actually it is
> a singleton, just one instance per class) that contains internal data
> (name of the class, a pointer to the superior class descriptor), maybe
> class or static properties and pointers to all methods, both class
> methods and instance methods.
Why do we need to store pointers to the class and instance methods in the
class object instance ? Can't we call the methods explicitely like in
glib/gtk+ ? Only pointers to the virtual methods must be stored in the class
object instance.
> Because of limitations of static
> initializers in C, some of this pointers cannot be initialized
> (especially method inheritance I could not implement statically), so
> classes have to be initialized. The class descriptor, thus, contains a
> flag that indicates whether the class has been initialized and a pointer
> to the class initialization function. So, the class descriptor for
> Subhandler_Object contains:
>
> int _initialized;
> void(*_init_class)();
> char * name;
> _Descriptor(SUPCLASS) * sup;
> void(*destroy)(CLASS *this);
>
> Here, destroy is the only real method that is defined at this level and
> is inherited or refined by other classes that add more fields here.
I don't like the idea of having an initialized field in the class. Wouldn't it
be better to use an accessor function ? Something like
SHClass get_some_subhandler_class(void)
{
static SHClass *class = NULL;
if ( class == NULL )
{
... initialize the class here ...
}
return class;
}
> As far as properties go, at this level the only property defined is a
> pointer to the class descriptor struct:
>
> _Descriptor(CLASS) *_class;
>
> Then, instance and class method calls are made easier with the help of
> the following macros:
>
> #define _MCALL(object, method, ...) (object->_class->method(object,
> ##__VA_ARGS__)) #define _CCALL(class, method, ...)
> (_Class(class).method(&_Class(class), ##__VA_ARGS__))
>
> I think the above use with __VA_ARGS__ is C99-compliant and does not
> require GNU extensions. I would hate to have to define _MCALL, _MCALL1,
> _MCALL2 and so on.
If we only store pointers to virtual methods in the class structure, what
about defining wrapper methods to them ? We could even inline the wrapper
methods.
> There is a double indirection to get to the real method address, but I
> am counting on the compiler optimization and I think that, anyway, the
> overhead will be dwarfed by the cost of the lack of inlining.
Once again, the double indirection overhead would only occur for virtual
methods, which is also the case in C++ anyway.
> > Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind
> > immediately) Don't use underscores in the name of the classes. Shouldn't
> > we stick to the same rules (for letter of each work in uppercase for
> > class names, without underscores, and lowercase with underscores for
> > members and functions).
>
> I have no preference on that. I am happy to change if it makes things
> clearer.
I don't have a lot of experience with gtk+, so I don't really care, but I
think that it will be easier to attract developpers if we stick to a the gtk+
coding rules.
Laurent Pinchart
|
|
From: Julio S. <jsa...@us...> - 2003-10-22 10:44:02
|
El mar, 21-10-2003 a las 22:04, Laurent Pinchart escribi=F3:
> What is a Subhandler_Object ? What kind of methods and/or properties will=
it=20
> hold ?
It contains mostly artifacts of the class-system implementation. Each
object instance contains a pointer to a class descriptor (actually it is
a singleton, just one instance per class) that contains internal data
(name of the class, a pointer to the superior class descriptor), maybe=20
class or static properties and pointers to all methods, both class
methods and instance methods. Because of limitations of static
initializers in C, some of this pointers cannot be initialized
(especially method inheritance I could not implement statically), so
classes have to be initialized. The class descriptor, thus, contains a
flag that indicates whether the class has been initialized and a pointer
to the class initialization function. So, the class descriptor for
Subhandler_Object contains:
int _initialized;
void(*_init_class)();
char * name;
_Descriptor(SUPCLASS) * sup;
void(*destroy)(CLASS *this);
Here, destroy is the only real method that is defined at this level and
is inherited or refined by other classes that add more fields here.
As far as properties go, at this level the only property defined is a
pointer to the class descriptor struct:
_Descriptor(CLASS) *_class;
Then, instance and class method calls are made easier with the help of
the following macros:
#define _MCALL(object, method, ...) (object->_class->method(object, ##__VA_=
ARGS__))
#define _CCALL(class, method, ...) (_Class(class).method(&_Class(class), ##=
__VA_ARGS__))
I think the above use with __VA_ARGS__ is C99-compliant and does not
require GNU extensions. I would hate to have to define _MCALL, _MCALL1,
_MCALL2 and so on.
=
=20
Hope it will become clear later. It seems confusing, but everything is
recipe-based and supported by macros, so you get the hang of it quickly.
Or so I hope.
There is a double indirection to get to the real method address, but I
am counting on the compiler optimization and I think that, anyway, the
overhead will be dwarfed by the cost of the lack of inlining.
> Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind=20
> immediately) Don't use underscores in the name of the classes. Shouldn't =
we=20
> stick to the same rules (for letter of each work in uppercase for class=20
> names, without underscores, and lowercase with underscores for members an=
d=20
> functions).
I have no preference on that. I am happy to change if it makes things
clearer.
> I have some trouble figuring exactly what you put in which class, but I=20
> suppose it will be clear when I'll have a look at the code.
Well, I am pretty much doing it as I go. I think when I have the sample
I am doing I will be able to look back and see what makes sense where
and then write some sort of specification or guideline.
> I don't have more comments for now. I'm still reading docs about MPEG and=
=20
> subtitles.
Adrie Stolk has provided a few other links that are interesting in
themselves or that point to other efforts that are working on related
subtitle handling. I will update the link page with them.
Regards,
Julio
|
|
From: Laurent P. <lau...@sk...> - 2003-10-22 06:36:56
|
> The library may live as a shared object on its own used by a number of > applications but it may also be stripped for direct integration on other > applications (some like xine or transcode tend to favor this approach > except for very general and well-established libraries). So the > library has to be constructed so that it is easy to select a subset of > it. Agreed. > For subsetting, an architecture based on some kind of polymorphism seems > easier that case switches. > [...] > Of course, this immediately suggests an object-oriented approach. Agreed too. > So, why not an OO language, such as C++? Would all applications gladly > use the dependency on a C++ compiler? Not sure. Besides, it is > possible to get a lot of the benefits of an OO language simply by > thinking in the right frame. For example, xine gets some benefit from it > and with the help of a few macros it is possible to go a long way. On > the other hand it is easy to go overboard with this. I think I have > found the right balance, so I think I will progress with C. But I am > willing to reconsider at anytime. Agreed again :-) I've been writing OO-oriented programs in C for years. I have to agree that using C++ is easier, as the compiler handles things that must be handled manually otherwise, but if we don't need all features of C++ (especially exceptions and multi-heritance), C will do the job. > So, at the top we have a Subhandler_Object class, ancestor to all > classes. The general hierarchy would go like this: What is a Subhandler_Object ? What kind of methods and/or properties will it hold ? > Subhandler_Object > Subhandler_Subtitle > Subhandler_Subtitle_Bitmap > Subhandler_Subtitle_Text > Subhandler_Stream > Subhandler_Stream_Submux (subrip/submux) > Subhandler_Stream_Philips_IMG > Subhandler_Stream_DVD > Subhandler_Stream_SVCD > Subhandler_Stream_CVD > Subhandler_Stream_SRT > Subhandler_Stream_PPML > Subhandler_Stream_SSA > Subhandler_Stream_MicroDVD > [etc.] > Subhandler_IO > Subhandler_IO_Text > Subhandler_IO_MPEG_PS > Subhandler_IO_MPEG_PES > Subhandler_IO_VobSub > Subhandler_IO_PS1 > Subhandler_IO_Program Most OO-oriented frameworks written in plain C (Gtk+/Gnome comes to mind immediately) Don't use underscores in the name of the classes. Shouldn't we stick to the same rules (for letter of each work in uppercase for class names, without underscores, and lowercase with underscores for members and functions). > Up to yesterday, I thought that IO was part of the Stream. But then I > found I was not getting enough reuse of code. And I am separating > tentatively both concepts to see if I can make sense of that structure. > An IO can be seen also as a container. This way it is possible to > combine a stream with different IOs (I don't think it is a really good > name, conduit might be better). Not all combinations make sense, > though. For instance writing a SRT stream inside a VobSub would not > produce an useful result. I have some trouble figuring exactly what you put in which class, but I suppose it will be clear when I'll have a look at the code. > Notice how we could select a subset of Stream and IO classes to provide > a stripped-down version of the library. OO rules :-) > Feel free to comment on this. As soon as I have a couple of classes > semi operative, I will start commiting. I am concentrating now on > cloning the functionality of vobsub/submux (no multiplexing, though, > just producing a PES). I don't have more comments for now. I'm still reading docs about MPEG and subtitles. But don't worry, I'll jump in when you'll start commiting :-) Laurent Pinchart |
|
From: Julio S. <jsa...@us...> - 2003-10-20 17:27:50
|
Hi all,
I have been doing some preliminary work. Mostly I have been throwing
ideas to the wall to see if any would stick and I think I have much
better understanding of what is needed. But I have changed my mind
several times over the few days and I cannot rule out further changes.
Anyway, if I don't write down right now what I have in mind, I might
regret it later. So excuse me if I brain dump on the list.
First, let's try to state the problem. We want to provide a library
that is able to handle subtitles in a variety of forms to support
operations such as input, output, display, multiplexing, format
conversion, time shifting/scaling, etc.
The library may live as a shared object on its own used by a number of
applications but it may also be stripped for direct integration on other
applications (some like xine or transcode tend to favor this approach
except for very general and well-established libraries). So the
library has to be constructed so that it is easy to select a subset of
it.
For subsetting, an architecture based on some kind of polymorphism seems
easier that case switches. For example, a switch example is:
switch(subtitle->type) {
case TYPE1: do_this; break;
case TYPE2: do_that; break;
/* and so on */
}
This structure is difficult to extend (it requires changes to every
module that uses it) but, what is worse, it is difficult to subset.
On the other hand, an architecture based on polymorphism such as:
subtitle->do_something(...);
can be extended easily, because callers do not need to know whether all
subtitles implement the same do_something or not, they just need to
provide a consistent interface. Of course, this immediately suggests an
object-oriented approach.
So, why not an OO language, such as C++? Would all applications gladly
use the dependency on a C++ compiler? Not sure. Besides, it is
possible to get a lot of the benefits of an OO language simply by
thinking in the right frame. For example, xine gets some benefit from it
and with the help of a few macros it is possible to go a long way. On
the other hand it is easy to go overboard with this. I think I have
found the right balance, so I think I will progress with C. But I am
willing to reconsider at anytime.
Anyway, the architecture is classy, i.e. OO-ish. Up to now, I had a
couple of class hierarchies: one for subtitles, one for streams. At
first I thought subtitles were most important, but that is not really
the case. Streams are, by far, more interesting and subtitles are
uninteresting, dull objects. Streams are vehicles for input and output
and where most interesting things happen. While trying to restructure
the thing, I have found there is another kind of objects that need
recognition: IO channels and I hope it will be clear later.
So, at the top we have a Subhandler_Object class, ancestor to all
classes. The general hierarchy would go like this:
Subhandler_Object
Subhandler_Subtitle
Subhandler_Subtitle_Bitmap
Subhandler_Subtitle_Text
Subhandler_Stream
Subhandler_Stream_Submux (subrip/submux)
Subhandler_Stream_Philips_IMG
Subhandler_Stream_DVD
Subhandler_Stream_SVCD
Subhandler_Stream_CVD
Subhandler_Stream_SRT
Subhandler_Stream_PPML
Subhandler_Stream_SSA
Subhandler_Stream_MicroDVD
[etc.]
Subhandler_IO
Subhandler_IO_Text
Subhandler_IO_MPEG_PS
Subhandler_IO_MPEG_PES
Subhandler_IO_VobSub
Subhandler_IO_PS1
Subhandler_IO_Program
Up to yesterday, I thought that IO was part of the Stream. But then I
found I was not getting enough reuse of code. And I am separating
tentatively both concepts to see if I can make sense of that structure.
An IO can be seen also as a container. This way it is possible to
combine a stream with different IOs (I don't think it is a really good
name, conduit might be better). Not all combinations make sense,
though. For instance writing a SRT stream inside a VobSub would not
produce an useful result.
Let's do now the exercise of seeing how some cases would be managed.
* Taking the PS1 output from transcode and preparing a SVCD PES
for mplex. This would entail associating a Subhandler_IO_PS1 to
a Subhandler_Stream_DVD that would be used for input, every
subtitle would then be appended to a Subhandler_Stream_SVCD
associated to a Subhandler_IO_MPEG_PES.
* Taking the output from the Philips authoring tool and prepare
output for multiplexing at mplex. We would read form a
Subhandler_Stream_Philips_IMG associated to a Subhandler_IO_Text
and output would be like in the case below.
* Same thing but producing subtitles to accompany a XViD file. In
this case, the output would be a Subhandler_Stream_DVD
associated to a Subhandler_IO_VobSub.
* Likewise, conversions from/to text can be done, but they are
harder. Converting from text to bitmap require font rendering
but, more important, they frequently require placement
decisions. Converting from bitmap to text require OCR. This
will not be available soon in the project.
* The xine plugin (I have found easier to concentrate on
everything else first) would use a Subhandler_IO_Program channel
connected to a Subhandler_Stream of the appropriate type. Here,
the control flow is inverted and requires some asynchronicity
that I working on.
* mplex could make use of a few of the components or it might just
do the work on its own.
Notice how we could select a subset of Stream and IO classes to provide
a stripped-down version of the library.
Feel free to comment on this. As soon as I have a couple of classes
semi operative, I will start commiting. I am concentrating now on
cloning the functionality of vobsub/submux (no multiplexing, though,
just producing a PES).
Best wishes.
Julio
|
|
From: Julio S. <jsa...@us...> - 2003-10-17 12:30:30
|
El jue, 16-10-2003 a las 23:57, Laurent Pinchart escribi=F3: > What is PES ? PES is a Packetized Elementary Stream, that is, the raw stream that is multiplexed into a Program Stream. > Do you mean that all the subtitles are multiplexed in a single elementary= =20 > stream ? Well, yes. Basic MPEG is a number of elementary streams multiplexed together. However, the private stream PS1 (stream code 0xBD) has a number of substreams. The first byte in the payload tells which substream it is. The standard says nothing about what those substreams are: they are private extensions. We know, however, that AC3 audio is there and so are subtitles. Substream codes starting with 0x00 to 0x03 are CVD subtitles. Starting with 0x20 up to 0x3f (I think) are the DVD subtitles. But all four channels of SVCD subtitles share the same substream 0x70 and have to be differentiated by an additional sub-substream code. So SVCD subtitles are multiplexed together in PS1 substream 0x70 that is multiplexed with other material to form the PS1 substream that is then multiplexed with video (stream code 0xE0), audio (stream code 0xC0 and 0xC1) and other things to produce the program stream that is actually stored on the CD. DVDs are similar, except they may have up to 8 audio channels (0xC0 to 0xC7 if MP, but AC3 sound is on PS1, no idea about DTS). Broadcast video is still more bizarre: it can have several video channels (0xE0 to 0xEF) that share the same carrier. So, conceptually, it is sort of a stream hierarchy that gets all multiplexed together. In practice, multiplexing hierarchically does not make sense, since further multiplexing may break the compromises chosen by prior steps. That's why submux is wrong and subtitle multiplexing should be put in mplex. > > And the PS1 format probably would have to be extended to signal the kin= d > > of subtitle so that the image can be reconstructed. >=20 > What do you mean ? It presumes the picture is DVD subtitle. That cannot be input to mplex unless it learns how to transcode those subtitles into SVCD or CVD, precisely what we wanted to avoid. > Do you have more information about MPEG2, especially an overview and the=20 > headers/packets format ? I don't. Most information returned by Google is either too general and consumer-oriented or too video research oriented. I suppose a good book would be best. The standard is expensive and probably hard to read. The link I gave that is now commercial is good. It used to have detailed tables of the headers, explaining bit by bit of them. I have it in print from when it was a free resource. If it is half as good as it was back then, I can recommend it heartily. For the web, we need a good collection of links to free resources, but this link may be worth the 5 dollars or so the guys asks for access. I am tempted,,, If you find worthwhile links, drop a note. > Done :-) Great, I am answering on the mailing list myself. This way, it gets archived automatically and others can correct our mistakes or misunderstandings. Regards, Julio |
|
From: Laurent P. <lau...@sk...> - 2003-10-16 22:33:45
|
> > What about the format generated by transcode ? > > > > $ tccat -i /path/to/vob/ -T 1 -L | tcextract -x ps1 -t vob -a 0x22 > > > subs-en > > Yes, I think that's one candidate. Though we must ponder what are the > advantages and disadvantages, what is gained and what is lost when > compared to the PES or VobSub. What is PES ? > Notice, anyway, that transcode is unable to extract SVCD articles (I > don't know if CVD would work) because, at least, there is the problem > that all SVCD subtitles are at stream 0x70 so, even if no other problems > appeared, it would mix them in the output. Do you mean that all the subtitles are multiplexed in a single elementary stream ? > And the PS1 format probably would have to be extended to signal the kind > of subtitle so that the image can be reconstructed. What do you mean ? > The disadvantage of PES, if I recall correctly is that it has no palette > information on DVD subtitle streams (it comes from the IFO). Does it > matter for multiplexing? I don't know. I'll keep that in mind. It might not matter for multiplexing but it probably will later. > If we have to propose one, and only one, format as input to the > multiplexer then it should be one that makes sense. Agreed. > I have added some links (the Philips links were hard to get) to the > project web page at: > > http://subhandler.sourceforge.net Do you have more information about MPEG2, especially an overview and the headers/packets format ? > Also, I created a mailing list for developers. I suggest we move > general discussion there, so that it is archived and visible to others > that might jump in. Done :-) Laurent Pinchart |
