From: James T. <ja...@ta...> - 2003-04-26 18:53:02
|
I'm not sure if this is a xine bug, or a problem with dvdauthor. When playing a dvd authored with dvdauthor-274, using xine 0.9.20 I usually get a segault after about 3 chapters: gdb gives the following traceback: (gdb) where #0 0x40275911 in kill () from /lib/libc.so.6 #1 0x4005a24b in pthread_kill () from /lib/libpthread.so.0 #2 0x4005a521 in raise () from /lib/libpthread.so.0 #3 0x40276846 in abort () from /lib/libc.so.6 #4 0x080ad3a9 in xitk_signal_handler (sig=0) at xitk.c:290 (gdb) I did not have this problem with 0.9.17, not do I see it with commercial dvds. I do however see it both with the actual DVD and when playing from the hard disk from which it was created. I have remastered without fixing the problem. It occurs both with the source-built version of xine on my Debian Woody box, and the version installed from debs on my Sid box. The problem happens with all titlesets, and can also occur on switching between menus. Clues, fixes... all appreciated. Best regards, James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-04-27 11:42:46
|
Hi James, Could you please go to the file xine-lib/src/input/libdvdnav/dvdnav_internal.h in the xine-lib source tree and remove the comment marks around line 46 (#define TRACE). This will enable VM tracing. Then recompile and reinstall xine-lib, try playing your disc until it crashes and sent the full console output here. Maybe this will give some useful information about what is going wrong. Michael -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c |
From: James T. <ja...@ta...> - 2003-04-27 12:15:37
Attachments:
seg.log.gz
|
On Sun, 27 Apr 2003 13:42:39 +0200 Michael Roitzsch <mr...@us...> wrote: > Hi James, > > Could you please go to the file > xine-lib/src/input/libdvdnav/dvdnav_internal.h in the xine-lib source > tree and remove the comment marks around line 46 (#define TRACE). This > will enable VM tracing. > Then recompile and reinstall xine-lib, try playing your disc until it > crashes and sent the full console output here. Maybe this will give > some useful information about what is going wrong. I've done that (output attached). It doesn't look to be very helpful. In this case it played 4 chapters (starting at #4) before crashing. I also noticed that the chapter number on the progress indicator doesn't update (whether that's in any way connnected I have no idea). Best regards, James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-04-28 20:08:03
|
Hi James, > > Could you please go to the file > > xine-lib/src/input/libdvdnav/dvdnav_internal.h in the xine-lib > > source tree and remove the comment marks around line 46 (#define > > TRACE). This will enable VM tracing. > > Then recompile and reinstall xine-lib, try playing your disc until > > it crashes and sent the full console output here. Maybe this will > > give some useful information about what is going wrong. > > I've done that (output attached). It doesn't look to be very helpful. Indeed, it seems not. > In this case it played 4 chapters (starting at #4) before crashing. I > also noticed that the chapter number on the progress indicator > doesn't update (whether that's in any way connnected I have no idea). Maybe a backtrace of the segfault could give us a clue. Could you provide one? (recompile and reinstall xine and xine-ui with 'make debug install-debug', launch xine inside gdb and type 'bt' when it crashes.) Michael -- panic("Tell me what a watchpoint trap is, and I'll then deal with such a beast..."); 2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c |
From: James T. <ja...@ta...> - 2003-04-28 21:55:53
|
On Mon, 28 Apr 2003 22:07:55 +0200 Michael Roitzsch <mr...@us...> wrote: > Maybe a backtrace of the segfault could give us a clue. Could you > provide one? (recompile and reinstall xine and xine-ui with > 'make debug install-debug', launch xine inside gdb and type 'bt' when it > > crashes.) I can't quite do that, as I can't persuade xine to run in gdb, but examining the coredump after recompiling gives: (gdb) where #0 0x40114041 in xine_message (stream=0x8680e68, type=9) at xine_interface.c:730 #1 0x4048d54d in demux_mpeg_block_parse_pack (this=0x8c95ac8, preview_mode=0) at demux_mpeg_block.c:457 #2 0x4048d941 in demux_mpeg_block_send_chunk (this_gen=0x8c95ac8) at demux_mpeg_block.c:701 #3 0x401121e3 in demux_loop (stream_gen=0x8680e68) at demux.c:212 #4 0x40057d53 in pthread_start_thread () from /lib/libpthread.so.0 (gdb) It seems to always be after playing 4 chapters, or making 4 menu jumps. Hope this is of some use. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-04-29 13:45:34
|
Hi James, > > Maybe a backtrace of the segfault could give us a clue. Could you > > provide one? (recompile and reinstall xine and xine-ui with > > 'make debug install-debug', launch xine inside gdb and type 'bt' > > when it crashes.) > > I can't quite do that, as I can't persuade xine to run in gdb, but > examining the coredump after recompiling gives: No problem, the coredump backtrace gives us the same info. > (gdb) where > #0 0x40114041 in xine_message (stream=0x8680e68, type=9) > at xine_interface.c:730 > #1 0x4048d54d in demux_mpeg_block_parse_pack (this=0x8c95ac8, > preview_mode=0) at demux_mpeg_block.c:457 > #2 0x4048d941 in demux_mpeg_block_send_chunk (this_gen=0x8c95ac8) > at demux_mpeg_block.c:701 > #3 0x401121e3 in demux_loop (stream_gen=0x8680e68) at demux.c:212 > #4 0x40057d53 in pthread_start_thread () from /lib/libpthread.so.0 > (gdb) > > It seems to always be after playing 4 chapters, or making 4 menu > jumps. If you look into the message log, the top messages should say something in the lines of: "stream may be encrypted". The problem is, that some of the PES headers of the MPEG stream (the ones on the chapter starts it would seem) have the "encrypted content" flag set. After encountering five of these conditions, xine will bail out believing that this stream is encrypted. So this looks like you discovered two problems. The segfault in xine (I just don't know where it is yet) and a problem in dvdauthor, which seems to set this flag wrong. Michael -- LOAD "WIN95",8,1 RUN |
From: James T. <ja...@ta...> - 2003-04-29 17:52:13
|
On Tue, 29 Apr 2003 15:45:10 +0200 Michael Roitzsch <mr...@us...> wrote: > If you look into the message log, the top messages should say something > in the lines of: "stream may be encrypted". Nothing obvious to that effect, there's a comment about using libdvdcss version 1.2.5, and a little later: libdvdnav: First Play Domain: - libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 1 libdvdnav: VTS:-1 PGC:0 PG:1 CELL:0 BLOCK:0 VTS_TTN:1 TTN:1 TT_PGCN:0 libdvdnav: Before printout ends. > The problem is, that some of the PES headers of the MPEG stream (the > ones on the chapter starts it would seem) have the "encrypted content" > flag set. After encountering five of these conditions, xine will bail > out believing that this stream is encrypted. To the dvdauthor folks -- any idea where this might be? > So this looks like you discovered two problems. The segfault in xine (I > just don't know where it is yet) and a problem in dvdauthor, which > seems to set this flag wrong. The segfault has gone with xine-lib-1-beta11, I now get a pop-up saying "Upgrade your frontend to see the error messages". Best regards, James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Scott S. <sc...@ge...> - 2003-04-29 20:02:06
|
> > The problem is, that some of the PES headers of the MPEG stream (the > > ones on the chapter starts it would seem) have the "encrypted content" > > flag set. After encountering five of these conditions, xine will bail > > out believing that this stream is encrypted. > > To the dvdauthor folks -- any idea where this might be? dvdauthor shouldn't modify the PES headers other than the SCR, though submux does generate its own. Did you filter the mpeg through submux? Scott |
From: James T. <ja...@ta...> - 2003-04-29 20:55:40
|
On Tue, 29 Apr 2003 13:01:02 -0700 Scott Smith <sc...@ge...> wrote: > > > > The problem is, that some of the PES headers of the MPEG stream (the > > > > > > ones on the chapter starts it would seem) have the "encrypted > > > content" flag set. After encountering five of these conditions, xine > > > will bail out believing that this stream is encrypted. > > > > To the dvdauthor folks -- any idea where this might be? > > dvdauthor shouldn't modify the PES headers other than the SCR, though > submux does generate its own. Did you filter the mpeg through submux? Only the menus, so unless kino is doing something nasty when exporting to DVD format, I'm puzzled as to where this is getting in. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-04-30 14:21:21
|
Hi James, > > If you look into the message log, the top messages should say > > something in the lines of: "stream may be encrypted". > > Nothing obvious to that effect, there's a comment about using > libdvdcss version 1.2.5, and a little later: > libdvdnav: First Play Domain: - > libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 1 > libdvdnav: VTS:-1 PGC:0 PG:1 CELL:0 BLOCK:0 VTS_TTN:1 TTN:1 TT_PGCN:0 > libdvdnav: Before printout ends. I should have been more clear: not the console output, but the message log. You get it by hitting Alt-l in xine-ui. > > So this looks like you discovered two problems. The segfault in > > xine (I just don't know where it is yet) and a problem in > > dvdauthor, which seems to set this flag wrong. > > The segfault has gone with xine-lib-1-beta11, I now get a pop-up > saying "Upgrade your frontend to see the error messages". No segfault? That's nice. Michael -- LOAD "WIN95",8,1 RUN |
From: James T. <ja...@ta...> - 2003-04-30 19:17:19
|
On Wed, 30 Apr 2003 16:21:12 +0200 Michael Roitzsch <mr...@us...> wrote: > Hi James, > > > > If you look into the message log, the top messages should say > > > something in the lines of: "stream may be encrypted". > > > > Nothing obvious to that effect, there's a comment about using > > libdvdcss version 1.2.5, and a little later: > > libdvdnav: First Play Domain: - > > libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 1 > > libdvdnav: VTS:-1 PGC:0 PG:1 CELL:0 BLOCK:0 VTS_TTN:1 TTN:1 TT_PGCN:0 > > libdvdnav: Before printout ends. > > I should have been more clear: not the console output, but the message > log. You get it by hitting Alt-l in xine-ui. Indeed it's there, claimins an encryption mode of 3. > > > So this looks like you discovered two problems. The segfault in > > > xine (I just don't know where it is yet) and a problem in > > > dvdauthor, which seems to set this flag wrong. > > > > The segfault has gone with xine-lib-1-beta11, I now get a pop-up > > saying "Upgrade your frontend to see the error messages". > > No segfault? That's nice. But I guess we have to wait for xine-ui-0.9.21 to get any more information:-( [I've tried recompiling 0.9.20]. The problem now is what's setting that bit? Is it dvdauthor, or mjpegtools (which is what kino uses to export)? and how to stop it doing so? James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-05-01 10:16:44
|
Hi James, > > > > If you look into the message log, the top messages should say > > > > something in the lines of: "stream may be encrypted". > > > > > > Nothing obvious to that effect, there's a comment about using > > > libdvdcss version 1.2.5, and a little later: > > > libdvdnav: First Play Domain: - > > > libdvdnav: get_PGCN failed. Was trying to find pgcN in domain 1 > > > libdvdnav: VTS:-1 PGC:0 PG:1 CELL:0 BLOCK:0 VTS_TTN:1 TTN:1 > > > TT_PGCN:0 libdvdnav: Before printout ends. > > > > I should have been more clear: not the console output, but the > > message log. You get it by hitting Alt-l in xine-ui. > > Indeed it's there, claimins an encryption mode of 3. > > The problem now is what's setting that bit? Is it dvdauthor, or > mjpegtools (which is what kino uses to export)? and how to stop it > doing so? I don't know these programs, but I would not expect an authoring tool to touch the internals of the underlying MPEG stream. Could you try playing the output of the mjpegtools with xine? You should force the usage of the MPEG block demuxer, when doing so: 'xine yourfile.vob#demux:mpeg_block' Michael -- "The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense." -E.W. Dijkstra |
From: James T. <ja...@ta...> - 2003-05-01 20:06:44
|
On Thu, 1 May 2003 12:16:37 +0200 Michael Roitzsch <mr...@us...> wrote: > > Indeed it's there, claimins an encryption mode of 3. > > > > The problem now is what's setting that bit? Is it dvdauthor, or > > mjpegtools (which is what kino uses to export)? and how to stop it > > doing so? > > I don't know these programs, but I would not expect an authoring tool to > > touch the internals of the underlying MPEG stream. Could you try > playing the output of the mjpegtools with xine? You should force the > usage of the MPEG block demuxer, when doing so: > 'xine yourfile.vob#demux:mpeg_block' This is getting wierder & wierder. Playing the main body .VOBs with or without #demux:mpeg_block does not generate any messages about things being encrypted, and they play for about 6 chapters before exiting (since the DVD has 2 levels of menus this at least makes some sense). The menu .VOBs do give 2 identical messages about possible encryption (again the #demux:mpeg_block doesn't make any difference) when I played the pseudo DVD I also got 2 such messages so presumable they both came from the menu system. By going through the menu generation one step at a time, it looks as if mplex is most likely to blame, BUT the other files have also gone through mplex with apparently the same options. Time to probe the mjpeg-tools and kino mailing lists I think. Many thanks for all your help. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-05-02 11:28:15
|
Hi James, > > > Indeed it's there, claimins an encryption mode of 3. > > > > > > The problem now is what's setting that bit? Is it dvdauthor, or > > > mjpegtools (which is what kino uses to export)? and how to stop > > > it doing so? > > > > I don't know these programs, but I would not expect an authoring > > tool to > > touch the internals of the underlying MPEG stream. Could you try > > playing the output of the mjpegtools with xine? You should force > > the usage of the MPEG block demuxer, when doing so: > > 'xine yourfile.vob#demux:mpeg_block' > > This is getting wierder & wierder. > > Playing the main body .VOBs with or without #demux:mpeg_block does > not generate any messages about things being encrypted, and they play > for about 6 chapters before exiting (since the DVD has 2 levels of > menus this at least makes some sense). The menu .VOBs do give 2 > identical messages about possible encryption (again the > #demux:mpeg_block doesn't make any difference) when I played the > pseudo DVD I also got 2 such messages so presumable they both came > from the menu system. By going through the menu generation one step > at a time, it looks as if mplex is most likely to blame, BUT the > other files have also gone through mplex with apparently the same > options. Time to probe the mjpeg-tools and kino mailing lists I > think. Is this the mplex tool which is also included in transcode? I tried this once, but the VOB-files it creates are useless. Neither the NAV PTS values nor the Cell-elapsed time were set correctly. The only tool I found so far to create well-behaving VOBs is Windows' IfoEdit. It runs well in wine and it also comes with a tool called VobEdit, with which you can inspect and edit VOB file headers and stuff. Michael -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c |
From: Gregoire F. <gr...@ul...> - 2003-05-02 11:48:49
|
On Fri, May 02, 2003 at 01:28:03PM +0200, Michael Roitzsch wrote: > Is this the mplex tool which is also included in transcode? I tried thi= s=20 > once, but the VOB-files it creates are useless. Neither the NAV PTS=20 > values nor the Cell-elapsed time were set correctly. The only tool I=20 > found so far to create well-behaving VOBs is Windows' IfoEdit. It runs=20 > well in wine and it also comes with a tool called VobEdit, with which=20 > you can inspect and edit VOB file headers and stuff. ??? Well, I have made one DVD using tcmplex (because the use of mplex from mjeg didn't works with two soundtracks (fixed in CVS)) and my DVD plays really good ;-) I don't know about IfoEdit, but mplex create an mpeg files, that you need to author to make the DVD, with dvdauthor (last version is just tremendous) :-) Have a great day, Gr=E9goire ________________________________________________________________ http://ulima.unil.ch/greg ICQ:16624071 mailto:gr...@ul... |
From: James T. <ja...@ta...> - 2003-05-02 18:37:22
|
On Fri, 2 May 2003 13:28:03 +0200 Michael Roitzsch <mr...@us...> wrote: > Is this the mplex tool which is also included in transcode? I tried this > > once, but the VOB-files it creates are useless. Neither the NAV PTS > values nor the Cell-elapsed time were set correctly. The only tool I > found so far to create well-behaving VOBs is Windows' IfoEdit. It runs > well in wine and it also comes with a tool called VobEdit, with which > you can inspect and edit VOB file headers and stuff. No, it's not, it's the one from mjpegtools. The DVD format it makes is pretty basic apparently (as I understand it anyway), but it just leaves the right amount of space for dvdauthor to fill in the bits and pieces when making the .VOB files. However dvdauthor doesn't do much in the PES headers other than some stuff with inter-chapter pauses. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-05-02 12:27:02
|
Hi Gr=E9goire, > > Is this the mplex tool which is also included in transcode? I tried > > this once, but the VOB-files it creates are useless. Neither the > > NAV PTS values nor the Cell-elapsed time were set correctly. The > > only tool I found so far to create well-behaving VOBs is Windows' > > IfoEdit. It runs well in wine and it also comes with a tool called > > VobEdit, with which you can inspect and edit VOB file headers and > > stuff. > > ??? Well, I have made one DVD using tcmplex (because the use of mplex > from mjeg didn't works with two soundtracks (fixed in CVS)) and my > DVD plays really good ;-) Ahh, now that you tell, this was tcmplex I tried. I used some command=20 like 'tcmplex -o test.vob -i test.m2v -p test.mpa -m d' like it is said=20 on the transcode examples page. When I looked at the NAV packets I=20 realized that the resulting stream was useless, since big parts of the=20 NAV packets were just plain zeros. This is bad when your player (xine)=20 depends on these informations to get sync (NAV PTS needed) and time=20 display (Cell elapsed time needed) correctly. > I don't know about IfoEdit, but mplex create an mpeg files, that you > need to author to make the DVD, with dvdauthor (last version is just > tremendous) :-) I have never used it and http://dvdauthor.sourceforge.net/ is either not=20 their official homepage or it is just not very informative: What does=20 it actually do? Michael --=20 "The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense." -E.W. Dijkstra |
From: Gregoire F. <gr...@ul...> - 2003-05-02 12:44:55
|
On Fri, May 02, 2003 at 02:26:40PM +0200, Michael Roitzsch wrote: > Ahh, now that you tell, this was tcmplex I tried. I used some command=20 > like 'tcmplex -o test.vob -i test.m2v -p test.mpa -m d' like it is said= =20 > on the transcode examples page. When I looked at the NAV packets I=20 > realized that the resulting stream was useless, since big parts of the=20 > NAV packets were just plain zeros. This is bad when your player (xine)=20 > depends on these informations to get sync (NAV PTS needed) and time=20 > display (Cell elapsed time needed) correctly. I might be wrong, but I don't think you can create a vob file with tcmplex (nor mplex)... just an mpeg2 file, that you should then use with dvdauthor... > I have never used it and http://dvdauthor.sourceforge.net/ is either no= t=20 > their official homepage or it is just not very informative: What does=20 > it actually do? It's tremendous, it allow you to take your mpeg2 files, make a real DVD out of it, with title, chapters and menu ;-) Just have for example a look at http://www.tappin.me.uk/Linux/dvd.html Have a great day!!! Gr=E9goire ________________________________________________________________ http://ulima.unil.ch/greg ICQ:16624071 mailto:gr...@ul... |
From: Markus P. <dvd...@gi...> - 2003-05-02 13:57:19
|
On Fri, 2 May 2003, Michael Roitzsch wrote: > Ahh, now that you tell, this was tcmplex I tried. I used some command > like 'tcmplex -o test.vob -i test.m2v -p test.mpa -m d' like it is > said on the transcode examples page. When I looked at the NAV packets > I realized that the resulting stream was useless, since big parts of > the NAV packets were just plain zeros. That's how it is supposed to be. > This is bad when your player (xine) depends on these informations to > get sync (NAV PTS needed) and time display (Cell elapsed time needed) > correctly. > >> I don't know about IfoEdit, but mplex create an mpeg files, that you >> need to author to make the DVD, with dvdauthor (last version is just >> tremendous) :-) > > I have never used it and http://dvdauthor.sourceforge.net/ is either > not their official homepage or it is just not very informative: What > does it actually do? It's the official homepage and yes it isn't really very informative. It is supposed to take a MPEG stream (from 'tcmplex -m d' or 'mplex -f 8') and create a DVD-Video Structure from it. It also fills the NAV packets. And it can also create menus and stuff. So it is an authoring software, just as the name suggests ;-) regards Markus |
From: Michael R. <mr...@us...> - 2003-05-03 13:59:35
|
Hi Markus, > > Ahh, now that you tell, this was tcmplex I tried. I used some > > command like 'tcmplex -o test.vob -i test.m2v -p test.mpa -m d' > > like it is said on the transcode examples page. When I looked at > > the NAV packets I realized that the resulting stream was useless, > > since big parts of the NAV packets were just plain zeros. > > That's how it is supposed to be. > > > This is bad when your player (xine) depends on these informations > > to get sync (NAV PTS needed) and time display (Cell elapsed time > > needed) correctly. > > > >> I don't know about IfoEdit, but mplex create an mpeg files, that > >> you need to author to make the DVD, with dvdauthor (last version > >> is just tremendous) :-) > > > > I have never used it and http://dvdauthor.sourceforge.net/ is > > either not their official homepage or it is just not very > > informative: What does it actually do? > > It's the official homepage and yes it isn't really very informative. I guess coding C is more fun than "coding" (X)HTML. (At least I would agree to that.) > It is supposed to take a MPEG stream (from 'tcmplex -m d' or 'mplex > -f 8') and create a DVD-Video Structure from it. It also fills the > NAV packets. And it can also create menus and stuff. So it is an > authoring software, just as the name suggests ;-) Thanks for this informative note. So these tools all go hand in hand. Good to know. I will try it eventually. Michael -- /* Identify the flock of penguins. */ 2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c |
From: Michael R. <mr...@us...> - 2003-05-03 13:59:35
|
Hi James, > > once, but the VOB-files it creates are useless. Neither the NAV PTS > > values nor the Cell-elapsed time were set correctly. The only tool > > I found so far to create well-behaving VOBs is Windows' IfoEdit. It > > runs well in wine and it also comes with a tool called VobEdit, > > with which you can inspect and edit VOB file headers and stuff. > > No, it's not, it's the one from mjpegtools. The DVD format it makes > is pretty basic apparently (as I understand it anyway), but it just > leaves the right amount of space for dvdauthor to fill in the bits > and pieces when making the .VOB files. However dvdauthor doesn't do > much in the PES headers other than some stuff with inter-chapter > pauses. So dvdauthor inherited the encrypted flag from either mjpegtools' multiplexer or from even before that. Does the file play without errors before multiplexing it? Michael -- In the beginning was the word, and the word was content-type: text/plain |
From: James T. <ja...@ta...> - 2003-05-05 12:32:15
|
On Sat, 3 May 2003 15:59:24 +0200 Michael Roitzsch <mr...@us...> wrote: > > No, it's not, it's the one from mjpegtools. The DVD format it makes > > is pretty basic apparently (as I understand it anyway), but it just > > leaves the right amount of space for dvdauthor to fill in the bits > > and pieces when making the .VOB files. However dvdauthor doesn't do > > much in the PES headers other than some stuff with inter-chapter > > pauses. > > So dvdauthor inherited the encrypted flag from either mjpegtools' > multiplexer or from even before that. Does the file play without errors > before multiplexing it? Things are getting still more confused now. Playing a menu .VOB file on its own produces the encryption warning, which shows twice. Playing a non-menu .VOB file on its own does not produce the encryption warning. But after about 6 chapters worth of playing (obviously playing a .VOB as a file doesn't show the DVD structure) xine gives up. Playing the DVD image from disk. Xine gives an encryption warning on showing any ne menu. After going through the main menu and the title's menu, 4 chapters are played before xine gives up. If however I go to a differnt title menu then back to main first, only 2 chapters are played. As of dvdauthor 0.5.3, the chapter numbers are correctly displayed by xine, whereas with alpha-274 the chapter boundaries generated were not recognized by xine (although the targets were). The encryption warning appears on the output of mplex and not on its input. Since the whole setup is using 1 file/chapter, I can't (on this one at any rate) really test whether the earlier stages of the generation really work correctly. I find it confusing that the mplex'ed output from kino doesn't have the encryption warning while the output from the menu-generating script does. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: Michael R. <mr...@us...> - 2003-05-05 18:02:04
|
Hi James, > > > No, it's not, it's the one from mjpegtools. The DVD format it > > > makes is pretty basic apparently (as I understand it anyway), but > > > it just leaves the right amount of space for dvdauthor to fill in > > > the bits and pieces when making the .VOB files. However dvdauthor > > > doesn't do much in the PES headers other than some stuff with > > > inter-chapter pauses. > > > > So dvdauthor inherited the encrypted flag from either mjpegtools' > > multiplexer or from even before that. Does the file play without > > errors before multiplexing it? > > Things are getting still more confused now. Not really much confusion. Just a small explanation at the start: When xine encounters a header saying "encrypted content", it will not bail out immediately, but increase an internal counter. It will stop playback, when this counter reaches 5. > Playing a menu .VOB file on its own produces the encryption warning, > which shows twice. > Playing a non-menu .VOB file on its own does not produce the > encryption warning. But after about 6 chapters worth of playing > (obviously playing a .VOB as a file doesn't show the DVD structure) > xine gives up. Maybe the VOB really ends after those 6 chapters? You do not get the encryption warning most likely because xine uses a different demuxer when playing the plain files. You can force the "DVD-demuxer" by appending "#demux:mpeg_block" to the MRL: 'xine vts_01_1.vob#demux:mpeg_block' You should see the warnings then. > Playing the DVD image from disk. Xine gives an > encryption warning on showing any ne menu. After going through the > main menu and the title's menu, 4 chapters are played before xine > gives up. If however I go to a differnt title menu then back to main > first, only 2 chapters are played. Because you went through more menus, the counter has been increased more often and reaches 5 earlier. > As of dvdauthor 0.5.3, the chapter numbers are correctly displayed by > xine, whereas with alpha-274 the chapter boundaries generated were > not recognized by xine (although the targets were). Could you explain that a bit more detailed? I did not understand you. (That might be because "chapter" is not a term used in the DVD structures officially, there are only "titles", "parts", "program chains" and "programs".) > The encryption warning appears on the output of mplex and not on its > input. Then mplex is guilty of setting this flag? Michael -- Linux is for Network Mac is for Artwork Windows is for Solitaire |
From: James T. <ja...@ta...> - 2003-05-05 18:44:19
|
On Mon, 5 May 2003 20:01:57 +0200 Michael Roitzsch <mr...@us...> wrote: > Hi James, > > > > > No, it's not, it's the one from mjpegtools. The DVD format it > > > > makes is pretty basic apparently (as I understand it anyway), but > > > > it just leaves the right amount of space for dvdauthor to fill in > > > > the bits and pieces when making the .VOB files. However dvdauthor > > > > doesn't do much in the PES headers other than some stuff with > > > > inter-chapter pauses. > > > > > > So dvdauthor inherited the encrypted flag from either mjpegtools' > > > multiplexer or from even before that. Does the file play without > > > errors before multiplexing it? > > > > Things are getting still more confused now. > > Not really much confusion. Just a small explanation at the start: When > xine encounters a header saying "encrypted content", it will not bail > out immediately, but increase an internal counter. It will stop > playback, when this counter reaches 5. > > > Playing a menu .VOB file on its own produces the encryption warning, > > which shows twice. > > Playing a non-menu .VOB file on its own does not produce the > > encryption warning. But after about 6 chapters worth of playing > > (obviously playing a .VOB as a file doesn't show the DVD structure) > > xine gives up. > > Maybe the VOB really ends after those 6 chapters? No; the .VOBs (some of them anyway) have 20-30 chapters in one file of about 750Mb. > You do not get the encryption warning most likely because xine uses a > different demuxer when playing the plain files. You can force the > "DVD-demuxer" by appending "#demux:mpeg_block" to the MRL: > > 'xine vts_01_1.vob#demux:mpeg_block' > > You should see the warnings then. > No, not on the main body .VOBs, only on the menu VOBs (and it looks as if it is using mpeg_block by default). Interestingly sometimes, instead of exiting after 6 chapters it goes back to the beginning, and just keeps on looping. > > Playing the DVD image from disk. Xine gives an > > encryption warning on showing any ne menu. After going through the > > main menu and the title's menu, 4 chapters are played before xine > > gives up. If however I go to a different title menu then back to main > > first, only 2 chapters are played. > > Because you went through more menus, the counter has been increased more > often and reaches 5 earlier. I thought that was probably the case. > > > As of dvdauthor 0.5.3, the chapter numbers are correctly displayed by > > xine, whereas with alpha-274 the chapter boundaries generated were > > not recognized by xine (although the targets were). > > Could you explain that a bit more detailed? I did not understand you. > (That might be because "chapter" is not a term used in the DVD > structures officially, there are only "titles", "parts", "program > chains" and "programs".) What I mean here is that in the progress slider in the xine gui, in the text line that gives title, chapter and volume ID. For DVD images generated by the older version of dvdauthor, this always showed the entry point, whereas with commercial DVDs and those generated with the latest version, the chapter number updates when it crosses the chapter boundaries. (I had wondered whether improperly written chapter boundaries were involved in some way). > > The encryption warning appears on the output of mplex and not on its > > input. > > Then mplex is guilty of setting this flag? Very probably. I've sent samples to one of the developers for investigation, but I've not heard anything back yet--then it was only a day or so ago. However if xine is telling the truth, the whole truth and nothing but the truth about encryption flags; then why do the mpegs that were mplex'ed by kino's export not have it set, but still cause xine problems? (the only guess I can hazard about the first is that mplex has problems with single-frame movies). James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |
From: James T. <ja...@ta...> - 2003-05-06 06:18:48
|
On Mon, 5 May 2003 19:43:09 +0100 James Tappin <ja...@ta...> wrote: > Very probably. I've sent samples to one of the developers for > investigation, but I've not heard anything back yet--then it was only a > day or so ago. However if xine is telling the truth, the whole truth and > nothing but the truth about encryption flags; then why do the mpegs that > were mplex'ed by kino's export not have it set, but still cause xine > problems? (the only guess I can hazard about the first is that mplex has > problems with single-frame movies). > Michael, Just a quick extra note on this one (I should have thought of this before). gxine does give a usable error on exiting. Even with the apparently un-flagged .VOBs the message is that it encountered an encrypted stream. James -- James Tappin, O__ "I forget the punishment for using ja...@ta... -- \/` Microsoft --- Something lingering http://www.tappin.me.uk/ with data loss in it I fancy" |