From: Miguel F. <mi...@ce...> - 2001-12-22 20:55:09
|
Hi folks, Some experiments with metronom revealed interesting bits: - my idea of metronom convergence (wrap_offsets) is wrong. I had good results with some cases (mostly dvd) but several avi's and asf's worked much better with the current code. I saw avi's where video and audio pts started so different that the best we can do is to fix xxx_wrap_offsets at once. The convergence approach generated several audio gaps along the movie... - i'm very happy with the metronom bugfixes over the last week. Not only it fixed some annoying pausing effects after discontinuities but it also improved sync with avi/asf streams that were affected by this bug on starting. One trailer i have for testing (whatliesbeneath_highres.wmv) the audio was off by about 2 seconds and now it's perfect. - i checked in some coments to metronom.h about it's internals. It's not meant to provide a complete description of all metronom's "magic" but should give some insight on issues like discontinuity handling. Now about 0.9.8: Guenter, i know you must be busy with your presentation, but perhaps you could share some ideas on future schedule and your current todo list. Some nice stuff already added since 0.9.7 includes a much improved dxr3 decoder from Harm (I don't have dxr3 card to test, but i saw the code and i think he's getting it right), nice antialised osd fonts and highlight positions clearing on dvd menu switch. (Not to mention a lot of improvements and bugfixes at the gui side!!) I would like to finish the ever pending issue of still frame detection before 1.0. I'm using the patch i sent to xine-dev for more than a week now with no problems. I tested all dvds i have and all menus worked. Some rare false triggering have been seen that may need some investigation, but nothing really show stopper... Anyway we need people to test this and some discussion whether this is the right approach or not... Miguel |
From: <bar...@t-...> - 2001-12-23 00:22:02
|
Hi Miguel, On Sat, 22 Dec 2001, Miguel Freitas wrote: > Guenter, i know you must be busy with your presentation, but perhaps you > could share some ideas on future schedule and your current todo list. well, the still frame detection is on top of my todo list at the moment. Besides that I agree that a 0.9.8 release should come soon, if possible it should contain the still frame detection. However, I'll be out of town from tomorrow evening until 2./3. january 2002, so I wont be able to make that release before that date - but if you or siggi or heiko want to have 0.9.8 earlier that's ok with me :-) otherwise, I'd shedule 0.9.8 for Sat 05 jan 2002. > I would like to finish the ever pending issue of still frame detection > before 1.0. I'm using the patch i sent to xine-dev for more than a week > now with no problems. I tested all dvds i have and all menus worked. actually I've finally found some time to test your patch this weekend. It failed detecting most of the still menus with audio I have here (actually quite a few DVDs in my collection have these, X-Men and Sleepy Hollow for example). The biggest problem seems to be that your code assumes that flushing the video decoder will actually release another frame which doesn't seem to be true; I'm currently experimenting with a slightly more aggresive aproach (based on your patch), hope to be able to commit or send a patch tomorrow before I leave. Cheers, Guenter -- time is a funny concept |
From: Harm v. d. H. <ha...@et...> - 2001-12-23 03:02:38
|
On Sun, Dec 23, 2001 at 01:21:40AM +0100, Guenter Bartsch wrote: > well, the still frame detection is on top of my todo list at the moment. > About Miguel's patch (I've already mailed Miguel about this): I haven't tested it yet with dxr3 playback but from the looks of it means there'll be less Xv and dxr3 specific code and that's a good thing. One issue with the patch as is: the dxr3 video out driver does not allocate YUV buffers for the dxr3 decoder since it would be a waste of memory. It does, however, set all vo_frame_t->base[] pointers to NULL so it's easily checked. So, if someone commits a patch based on Miguels work, please add a check whether base[] isn't NULL before the xine_fastmemcpy calls. A message on xine-devel would be nice too, in case I still haven't gotten around to testing it. > Besides that I agree that a 0.9.8 release should come soon, if possible it > should contain the still frame detection. However, I'll be out of town > from tomorrow evening until 2./3. january 2002, so I wont be able to make > that release before that date - but if you or siggi or heiko want to have > 0.9.8 earlier that's ok with me :-) otherwise, I'd shedule 0.9.8 for > Sat 05 jan 2002. Would 0.9.8 be based on the HEAD or stable branch? I'd like to have the new dxr3 code (now in HEAD) in 0.9.8. I've used it for about a week now and it works pretty well. It's certainly better than what's in 0.9.7 and the stable branch. Regards, Harm |
From: <bar...@t-...> - 2001-12-23 09:12:10
|
Hi Harm, On Sun, 23 Dec 2001, Harm van der Heijden wrote: > > Besides that I agree that a 0.9.8 release should come soon, if possible it > > should contain the still frame detection. However, I'll be out of town > > from tomorrow evening until 2./3. january 2002, so I wont be able to make > > that release before that date - but if you or siggi or heiko want to have > > 0.9.8 earlier that's ok with me :-) otherwise, I'd shedule 0.9.8 for > > Sat 05 jan 2002. > > Would 0.9.8 be based on the HEAD or stable branch? I'd like to have the > new dxr3 code (now in HEAD) in 0.9.8. I've used it for about a week now > and it works pretty well. It's certainly better than what's in 0.9.7 > and the stable branch. 0.9.8 will be released from the head branch. Stable releases will be called 0.99.x, but I don't think the stable branch is in shape for a release at the moment. Also, there is still some stuff to do on the head branch will I think should later be merged to the stable branch before 1.0: - still image detection (of course) - if possible move the logo output from xine-ui to xine-lib so video_out-loop is always running and outputting the logo if not opened by a video decoder - I think this could make true osd possible and also make some of the video output plugin code simpler - unicode support for avi subtitles - more? Cheers, Guenter -- time is a funny concept |
From: Harm v. d. H. <ha...@et...> - 2001-12-23 15:52:41
|
On Sun, Dec 23, 2001 at 10:11:55AM +0100, Guenter Bartsch wrote: > 0.9.8 will be released from the head branch. Stable releases will be > called 0.99.x, but I don't think the stable branch is in shape for a > release at the moment. OK, I'll make sure I only commit dxr3 stuff that's good enough for 0.9.8 release. A few days between the commit of the still frame detection code and the next release would be nice, then I can make sure it doesn't break dxr3. > - more? I have a few setup/config ideas; - it would be nice if the xine-ui setup window shows which variables have a callback, and which don't. That also might encourage developers to implement them. I think those callback functions are really cool, and having such 'hands-on' control over the plugins is one of xine's strong points. - it appears that the setup window does not update the ui element after a callback; in my boolean call-back, I set entry->num_value back to 0 but the window still shows a pressed button. - how about a feature where certain variables are not saved in .xine/config? (for example, if you set description to NULL). The reason I'm asking is because I'm "abusing" the config system as a global variable; I need some way in which the dxr3 vo driver can tell the dxr3 decoder plugin that it is active; if the dxr3 vo is not the current vo driver, the dxr3 decoder must return 0 capabilities. I use the "dxr3.active" variable for that, but it shouldn't be saved to file. Would a 'no save if description == NULL' feature be acceptable? OTOH a cleaner solution might be to add a 'save' boolean field to cfg_entry_t, which defaults to true. Regards, Harm |
From: Porter S. <sc...@ea...> - 2001-12-24 01:33:15
|
* Guenter Bartsch (bar...@t-...) wrote: > - unicode support for avi subtitles What avi subtitle formats is support planned for? In the past, I saw many avi's subtitles coming in the form of OCRed text. In more recent times the trend seems to be the use of the dvobsub filter for Directshow, which iirc uses subtitles stored as bitmaps so as to avoid poor OCR software not adequetly/accurately reading the subtitles from the dvd source. The former subtitle format lends itself to use of the OSD, but what about the latter? In a discussion on the avifile-dev mailing list sometime back, Arpi (one of the mplayer developer) mentioned that he thought these dvobsub compatable subtitles were the same format as the subtitles that are stored on a dvd, so if xine already supports dvd subtitles it would merely be a matter of understanding the dvobsub timing file syntax etc. I am personally very interested in support for this format as it seems to be the standard for avi subtitles for japanese animated films (a large genre where practically every film is subtitled). Does anyone have any more concrete information regarding the dvobsub format? =20 As well, is there any support planned for loading the dubbing on a film from an external file? Most subtitled avi's do not seem to have the second dubbing track in the avi stream (although avi does support multiple audio tracks) but rather the second dubbing comes in the form of a seperate mp3. -- Porter |
From: <bar...@t-...> - 2001-12-24 10:00:59
|
Hi, On Sun, 23 Dec 2001, Porter Schermerhorn wrote: > * Guenter Bartsch (bar...@t-...) wrote: > > - unicode support for avi subtitles > > What avi subtitle formats is support planned for? currently the same subtitle formats as in mplayer should be supported: #define FORMAT_MICRODVD 0 #define FORMAT_SUBRIP 1 #define FORMAT_SUBVIEWER 2 #define FORMAT_SAMI 3 #define FORMAT_VPLAYER 4 #define FORMAT_RT 5 #define FORMAT_SSA 6 /* Sub Station Alpha */ #define FORMAT_DUNNO 7 /*... erm ... dunnowhat. tell me if you know */ #define FORMAT_MPSUB 8 #define FORMAT_AQTITLE 9 > As well, is there any support planned for loading the dubbing on a > film from an external file? it's the only way it's implemented actually. Try something like xine foo.avi:bar.sub the feature is experimental at the moment, though (tested it with two microdvds which worked) Cheers, Guenter -- time is a funny concept |
From: Porter S. <sc...@ea...> - 2001-12-24 22:58:41
|
* Guenter Bartsch (bar...@t-...) wrote: > currently the same subtitle formats as in mplayer should be supported: >=20 > #define FORMAT_MICRODVD 0 > #define FORMAT_SUBRIP 1 > #define FORMAT_SUBVIEWER 2 > #define FORMAT_SAMI 3 > #define FORMAT_VPLAYER 4 > #define FORMAT_RT 5 > #define FORMAT_SSA 6 /* Sub Station Alpha */ > #define FORMAT_DUNNO 7 /*... erm ... dunnowhat. tell me if you know */ > #define FORMAT_MPSUB 8 > #define FORMAT_AQTITLE 9 Awesome, glad to see such a long list of supported formats! What about the dvobsub format? > > As well, is there any support planned for loading the dubbing on a > > film from an external file? >=20 > it's the only way it's implemented actually. Try something like >=20 > xine foo.avi:bar.sub Hrm, I am running into a little trouble with this myself, but I am using 0.9.7 not cvs atm. I use: xine VTS_01_1.vob:STS_01_1.sub (The filenames are weird, but that is how MicroDVD seems to do it, the vob is actually just an avi) But the subtitles are not displayed, I only see an OSD of "spudecoder text", perhaps this is because subtitles aren't fully implemented in 0.9.7 but just in current cvs? Also, the mp3 file that contains the japanese dubbing is not loaded. I will try using latest cvs checkout and see if this fixes these problems.=20 -- Porter |
From: James <ja...@pi...> - 2001-12-16 14:12:04
|
[2001-12-15 22:44 +0100] Guenter Bartsch wrote: | The only thing I noticed is that the current metronom seems to get the | framerate wrong some times and then slowly adjusts to the correct | framerate, resulting in a jerky playback after a discontinuity. I can't | say much about performance, I have a mid-range athlon (1.4 GHz) here which | hardly ever drops frames. | | Anyone have details on slower systems? On my 'mere' Celeron 525, 512MB ram with a DXR3 and the nav plugin I get the odd bout of '200 frames delivered, 20 dropped" (and sometimes 0 dropped). I also get a few warnings about discontinuities. Sometimes it'll go through half the film spewing timer corrections up the screen, but the playback appears unaffected. Generally, the DVDs are quite watchable. The picture quality is great (the odd mpeg artefacts show up on blocks of colour, etc) and the sound gets nicely downmixed to stereo so not only can I hear people talk, but also bangs and explosions (so I can hear Mulder talk in the X-Files instead of mumbling, and when they shoot stuff it doesn't blow my windows out). If I skip chapters the audio is completely off for a few seconds, but then it gradually gets back into sync - usually within 5 seconds. Things like scrolling text, panning scenes, and ending credits jerk a bit though. Oh, and I can rip and encode CDs to ogg files while watching a DVD without any loss of performance. -- The universe is an island, surrounded by whatever it is that surrounds universes. 6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc E4C4 DEEA 7D08 D511 E149 | jjj.cvxh.bet.hx wn...@cv...t.hx (rot13'd) |
From: Robin K. <kom...@my...> - 2001-12-16 14:31:54
|
> On my 'mere' Celeron 525, 512MB ram with a DXR3 and the nav plugin I > get the odd bout of '200 frames delivered, 20 dropped" (and sometimes 0 > dropped). The DXR3 does MPEG decoding in hardware. Either that means that the suspicious code is never executed or that (as with high-end machines) your CPU utilization is too low for any problems in the suspicious code to show up. Try xine using the Xv plugin and see if that exposes any problems. You machine should be powerful enough to play DVDs flawlessly with Xv, so any problems that show up should be caused by xine bugs. --Robin Kay-- http://www.gekkou.co.uk |
From: Harm v. d. H. <ha...@et...> - 2001-12-16 14:37:18
|
On Sun, Dec 16, 2001 at 02:15:25PM +0000, James wrote: > [2001-12-15 22:44 +0100] Guenter Bartsch wrote: > > | The only thing I noticed is that the current metronom seems to get the > | framerate wrong some times and then slowly adjusts to the correct > | framerate, resulting in a jerky playback after a discontinuity. I can't > | say much about performance, I have a mid-range athlon (1.4 GHz) here which > | hardly ever drops frames. > | > | Anyone have details on slower systems? > > On my 'mere' Celeron 525, 512MB ram with a DXR3 and the nav plugin I > get the odd bout of '200 frames delivered, 20 dropped" (and sometimes 0 > dropped). I also get a few warnings about discontinuities. Sometimes > it'll go through half the film spewing timer corrections up the screen, > but the playback appears unaffected. > If you're talking about playback with dxr3 hardware decoding, it's probably not relevant to this discussion. The dxr3 "decoder" plugin contains a weird hack to make metronom happy, which will account for most of the '200 frames delivered, 20 dropped' messages. Glad to hear it works for you though. By the way, yesterday I checked in a patch that links the dxr3 decoder to the dxr3 video out plugin. That means dxr3 users can now use xine -V dxr3 dvdnav:// (use dxr3 hardware decoding and output) xine -V Xv dvdnav:// (use libmpeg2 decoding and Xv output) Regards, Harm |