From: Miguel F. <mfr...@gm...> - 2005-10-30 01:47:48
|
hi, ok, here is one thing that has been bugging me for a long time: gapless playback. i guess i have finally thought of a nice way of implementing it with minimum effort from ui. the magic involves two new stream parameters: XINE_PARAM_EARLY_FINISHED_EVENT XINE_PARAM_GAPLESS_SWITCH if UI supports/wants gapless playback it should then set XINE_PARAM_EARLY_FINISHED_EVENT. setting it causes libxine to deliver the XINE_EVENT_UI_PLAYBACK_FINISHED as soon as it can, that is, it will disable internal code that waits for the output audio and video fifos to empty. set it once and forget. when UI receives XINE_EVENT_UI_PLAYBACK_FINISHED, it should set XINE_PARAM_GAPLESS_SWITCH and then perform usual xine_open(), xine_play() sequence. the gapless parameter will cause libxine to disable a couple of code so it won't stop current playback, it won't close audio driver and the new stream should play seamless. but here is the catch: XINE_PARAM_GAPLESS_SWITCH must _only_ be set just before the desired gapless switch. it will be reset automatically as soon as the xine_play() returns. setting it during playback will cause bad seek behaviour. take care to reset the gapless switch if xine_open() fails. btw, frontends should check for version >=3D 1.1.1 before using this featur= e. comments? Miguel |
From: Christoffer G. <or...@0x...> - 2007-11-25 18:36:29
|
Hi! I am looking into creating a media player based on xine and after looking a bit at the library I am wondering if it is possible to achieve true gapless playback of mp3's with xine? / Christoffer Gurell |
From: Brian J. T. <bj...@co...> - 2005-10-30 02:21:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Freitas wrote: > hi, > > ok, here is one thing that has been bugging me for a long time: > gapless playback. i guess i have finally thought of a nice way of > implementing it with minimum effort from ui. > > the magic involves two new stream parameters: > > XINE_PARAM_EARLY_FINISHED_EVENT > XINE_PARAM_GAPLESS_SWITCH > > if UI supports/wants gapless playback it should then set > XINE_PARAM_EARLY_FINISHED_EVENT. setting it causes libxine to deliver > the XINE_EVENT_UI_PLAYBACK_FINISHED as soon as it can, that is, it > will disable internal code that waits for the output audio and video > fifos to empty. set it once and forget. > > when UI receives XINE_EVENT_UI_PLAYBACK_FINISHED, it should set > XINE_PARAM_GAPLESS_SWITCH and then perform usual xine_open(), > xine_play() sequence. the gapless parameter will cause libxine to > disable a couple of code so it won't stop current playback, it won't > close audio driver and the new stream should play seamless. > > but here is the catch: XINE_PARAM_GAPLESS_SWITCH must _only_ be set > just before the desired gapless switch. it will be reset automatically > as soon as the xine_play() returns. setting it during playback will > cause bad seek behaviour. > > take care to reset the gapless switch if xine_open() fails. > > btw, frontends should check for version >= 1.1.1 before using this feature. > > comments? I feel like this isn't quite the right approach. If XINE_EVENT_UI_PLAYBACK_FINISHED now tells me when I can start loading up a new file, how do I know when playback actually *has* finished? I'd like to know so I can change, e.g., the selected playlist item, title of the song in the display, etc. I want to change that when the first song ends and the second song begins, not some decoder/audio-out dependant time before the first song ends. Frankly I'm not sure what the best approach would be... Perhaps a XINE_EVENT_UI_PLAYBACK_ALMOST_FINISHED event (feel free to name it better)? It seems less confusing to me to just add a new event rather than changing the meaning of an existing event based on a param setting. That way I can do this: xine_open(song_1); xine_play(); ... [song #1 is playing] ... [song #1 is still playing] - --> XINE_EVENT_UI_PLAYBACK_ALMOST_FINISHED: xine_set_param(stream, XINE_PARAM_GAPLESS_SWITCH, 1); xine_open(song_2); xine_play(); ... [song #1 is just getting to the end] - --> XINE_EVENT_UI_PLAYBACK_FINISHED: set_playlist_selection(); set_display_title(); ... [now song #2 is playing] Another benefit here is that you also don't need XINE_PARAM_EARLY_FINISHED_EVENT, so we only have one new event type (without a change to existing events) and one new param type that's only used if you want to make use of gapless playback. This makes for even less effort in the UI than your method, and doesn't make us lose information that we had before. What do you think? -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZC4g6XyW6VEeAnsRAt/UAJ9O+5mlOkAv56CmWbnu+n4f/HtFdACeMgf0 AQqgw70oLSzulpvHVHe67UY= =2X1d -----END PGP SIGNATURE----- |
From: Miguel F. <mfr...@gm...> - 2005-10-30 02:49:21
|
hi Brian, On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > I feel like this isn't quite the right approach. If > XINE_EVENT_UI_PLAYBACK_FINISHED now tells me when I can start loading up > a new file, how do I know when playback actually *has* finished? hmm, just don't set XINE_PARAM_EARLY_FINISHED_EVENT? ;-) (i'm kidding - i suppose you want gapless playback) > I'd > like to know so I can change, e.g., the selected playlist item, title of > the song in the display, etc. I want to change that when the first song > ends and the second song begins, not some decoder/audio-out dependant > time before the first song ends. well, this is normally quite short time... i mean, frames in video out queue would hardly keep 1/2 seconds ahead. it is usually less. admittedly, with a carefully crafted low quality stream (1 frame per second?) one may get a larger difference. i don't know if we should care that much about this case though. > Frankly I'm not sure what the best approach would be... Perhaps a > XINE_EVENT_UI_PLAYBACK_ALMOST_FINISHED event (feel free to name it > better)? It seems less confusing to me to just add a new event rather > than changing the meaning of an existing event based on a param setting. ok, we might do something like that. just a remind that we already changed the meaning of this event, exactly from "almost finished" to "finished" in 1-RC6. i'm just adding an 'if' around that change. > Another benefit here is that you also don't need > XINE_PARAM_EARLY_FINISHED_EVENT, so we only have one new event type > (without a change to existing events) and one new param type that's only > used if you want to make use of gapless playback. This makes for even > less effort in the UI than your method, and doesn't make us lose > information that we had before. ok, i agree we don't lose information but i think it is actually more effort to UI. since xine-ui is going to support both xine-lib >=3D 1.1.1 and older versions, it will need an additional logic to ignore some events. ok, no big deal, but more code. > What do you think? you've got a point. ;-) perhaps we should have both? obs: adding this other event will require somewhat bigger changes to libxine, because we must synchronize audio and video threads detection of end of stream in different times to generate a single event (audio_decoder.c and video_decoder.c). but of course it must be doable. Miguel |
From: Brian J. T. <bj...@co...> - 2005-10-30 04:11:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Miguel, Miguel Freitas wrote: > hi Brian, > > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > >>I'd >>like to know so I can change, e.g., the selected playlist item, title of >>the song in the display, etc. I want to change that when the first song >>ends and the second song begins, not some decoder/audio-out dependant >>time before the first song ends. > > well, this is normally quite short time... i mean, frames in video out > queue would hardly keep 1/2 seconds ahead. it is usually less. > > admittedly, with a carefully crafted low quality stream (1 frame per > second?) one may get a larger difference. i don't know if we should > care that much about this case though. Ok, if it's really just a fraction of a second, I guess I wouldn't mind all that much. The perfectionist in me, though, still cringes a bit that it's not *really* the end of playback ^_~. >>Another benefit here is that you also don't need >>XINE_PARAM_EARLY_FINISHED_EVENT, so we only have one new event type >>(without a change to existing events) and one new param type that's only >>used if you want to make use of gapless playback. This makes for even >>less effort in the UI than your method, and doesn't make us lose >>information that we had before. > > ok, i agree we don't lose information but i think it is actually more > effort to UI. since xine-ui is going to support both xine-lib >= 1.1.1 > and older versions, it will need an additional logic to ignore some > events. ok, no big deal, but more code. Really? In my frontend, I'm ignoring some events I don't care about by... just ignoring them - i.e., just not having 'case' statements in the big 'switch' block for those events. AFAICT, you shouldn't need to modify a frontend at all (using my suggested gapless playback method) if the frontend doesn't care about gapless playback. Unless they're doing something complicated with unhandled events, that is... >>What do you think? > > you've got a point. ;-) > > perhaps we should have both? Hehe... won't that get confusing? > obs: adding this other event will require somewhat bigger changes to > libxine, because we must synchronize audio and video threads detection > of end of stream in different times to generate a single event > (audio_decoder.c and video_decoder.c). but of course it must be > doable. Here's the point I wasn't sure about: the effort to actually make it happen. Obviously someone like you would have a much better idea about this. If it's prohibitively difficult/annoying to add another event, by all means feel free do it whichever way makes for the least work while still making you happy ^_^. -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZEfR6XyW6VEeAnsRAl5dAKCEaTLfwqC6QNT1mqPqMpx1bfRP9gCgr/51 U2r4s52WxUgN+PYI9RADhpw= =2T1O -----END PGP SIGNATURE----- |
From: Alien <ali...@us...> - 2005-10-30 08:32:23
|
what about crossfading? this algorithm probably allow for it as well, with the extra crossfader=20 parameter, audio can crossfade, and video with a post plugin or something... Op zondag 30 oktober 2005 05:10, schreef Brian J. Tarricone: > Hey Miguel, > > Miguel Freitas wrote: > > hi Brian, > > > > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > >>I'd > >>like to know so I can change, e.g., the selected playlist item, title of > >>the song in the display, etc. I want to change that when the first song > >>ends and the second song begins, not some decoder/audio-out dependant > >>time before the first song ends. > > > > well, this is normally quite short time... i mean, frames in video out > > queue would hardly keep 1/2 seconds ahead. it is usually less. > > > > admittedly, with a carefully crafted low quality stream (1 frame per > > second?) one may get a larger difference. i don't know if we should > > care that much about this case though. > > Ok, if it's really just a fraction of a second, I guess I wouldn't mind > all that much. The perfectionist in me, though, still cringes a bit > that it's not *really* the end of playback ^_~. > > >>Another benefit here is that you also don't need > >>XINE_PARAM_EARLY_FINISHED_EVENT, so we only have one new event type > >>(without a change to existing events) and one new param type that's only > >>used if you want to make use of gapless playback. This makes for even > >>less effort in the UI than your method, and doesn't make us lose > >>information that we had before. > > > > ok, i agree we don't lose information but i think it is actually more > > effort to UI. since xine-ui is going to support both xine-lib >=3D 1.1.1 > > and older versions, it will need an additional logic to ignore some > > events. ok, no big deal, but more code. > > Really? In my frontend, I'm ignoring some events I don't care about > by... just ignoring them - i.e., just not having 'case' statements in > the big 'switch' block for those events. AFAICT, you shouldn't need to > modify a frontend at all (using my suggested gapless playback method) if > the frontend doesn't care about gapless playback. Unless they're doing > something complicated with unhandled events, that is... > > >>What do you think? > > > > you've got a point. ;-) > > > > perhaps we should have both? > > Hehe... won't that get confusing? > > > obs: adding this other event will require somewhat bigger changes to > > libxine, because we must synchronize audio and video threads detection > > of end of stream in different times to generate a single event > > (audio_decoder.c and video_decoder.c). but of course it must be > > doable. > > Here's the point I wasn't sure about: the effort to actually make it > happen. Obviously someone like you would have a much better idea about > this. If it's prohibitively difficult/annoying to add another event, by > all means feel free do it whichever way makes for the least work while > still making you happy ^_^. > > -brian > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Miguel F. <mfr...@gm...> - 2005-10-30 10:23:37
|
On 10/30/05, Alien <ali...@us...> wrote: > what about crossfading? of course i thought about it, but it still pretty much an open problem for = me. Miguel |
From: Michael R. <mr...@us...> - 2005-10-30 17:40:42
|
Hi Miguel, >> what about crossfading? > > of course i thought about it, but it still pretty much an open > problem for me. I agree. Let's go one step at a time. Just a comment about the interface: Wouldn't it be clearer, if we had a function like xine_play_gapless() instead of this one-shot parameter? Michael |
From: Miguel F. <mfr...@gm...> - 2005-10-30 21:24:05
|
On 10/30/05, Michael Roitzsch <mr...@us...> wrote: > Just a comment about the interface: Wouldn't it be clearer, if we had > a function like xine_play_gapless() instead of this one-shot parameter? no objections from me. however, a small note: the new parameter does affect both xine_open() and xine_play() behaviour. so, in order to create a new function, it would have to be something like xine_gapless_open_and_play() ;-) btw, when a frontend is compiled using this function it would fail to run with older xine-lib. while current xine-ui cvs should work fine with both old and new xine-lib (runtime detection). Miguel |
From: Michael R. <mr...@us...> - 2005-10-31 12:17:39
|
Hi Miguel, > no objections from me. > > however, a small note: the new parameter does affect both xine_open() > and xine_play() behaviour. so, in order to create a new function, it > would have to be something like xine_gapless_open_and_play() ;-) > > btw, when a frontend is compiled using this function it would fail to > run with older xine-lib. while current xine-ui cvs should work fine > with both old and new xine-lib (runtime detection). Ok, that's two very convincing arguments for your solution. Let's keep it your way. Michael |
From: Miguel F. <mfr...@gm...> - 2005-10-30 10:22:06
|
hi Brian, On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > Ok, if it's really just a fraction of a second, I guess I wouldn't mind > all that much. The perfectionist in me, though, still cringes a bit > that it's not *really* the end of playback ^_~. ;-) well, give it a try if you can (xine-lib and xine-ui cvs) and let me know. that kind of synchronizations issues is a recurring problem in xine due our pipeline. synchronizing frontend with events from dvd input plugin, for example, is even harder (since the end-to-end delay is bigger). > Really? In my frontend, I'm ignoring some events I don't care about > by... just ignoring them - i.e., just not having 'case' statements in > the big 'switch' block for those events. AFAICT, you shouldn't need to > modify a frontend at all (using my suggested gapless playback method) if > the frontend doesn't care about gapless playback. Unless they're doing > something complicated with unhandled events, that is... ok, it is easy to ignore events. i just meant that frontend needs a bit more code to support older xine-lib versions: xine_open(song_1); xine_play(); ... [song #1 is playing] ... [song #1 is still playing] - --> XINE_EVENT_UI_PLAYBACK_ALMOST_FINISHED: xine_set_param(stream, XINE_PARAM_GAPLESS_SWITCH, 1); xine_open(song_2); xine_play(); almost_finished_received =3D 1; ... [song #1 is just getting to the end] - --> XINE_EVENT_UI_PLAYBACK_FINISHED: if( !almost_finished_received ) { xine_open(song_2); xine_play(); } set_playlist_selection(); set_display_title(); ... [now song #2 is playing] > > perhaps we should have both? > > Hehe... won't that get confusing? at least it let us work incrementaly... > Here's the point I wasn't sure about: the effort to actually make it > happen. Obviously someone like you would have a much better idea about > this. If it's prohibitively difficult/annoying to add another event, by > all means feel free do it whichever way makes for the least work while > still making you happy ^_^. thanks ;-) and, of course, patches will always be considered! ;-) Miguel |
From: Brian J. T. <bj...@co...> - 2005-10-30 12:04:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Freitas wrote: > hi Brian, > > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > >>Ok, if it's really just a fraction of a second, I guess I wouldn't mind >>all that much. The perfectionist in me, though, still cringes a bit >>that it's not *really* the end of playback ^_~. > > > ;-) > well, give it a try if you can (xine-lib and xine-ui cvs) and let me know. Unfortunately, as I found earlier tonight when trying to add OggFLAC support to the ogg demuxer, it seems I can't build xine-lib CVS at present... That old asm error in ffmpeg that apparently Gentoo somehow fixes with patches but I don't know enough to fix manually =p. I'll see about messing with it when I have a bit more energy... -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZLa/6XyW6VEeAnsRAqk7AJ9RyfZS8CzBHS7DLE1WaPfdBTXXkACfaBOR ILEFZxbwPhBuH59Kntd3RM4= =BVqy -----END PGP SIGNATURE----- |
From: Miguel F. <mfr...@gm...> - 2005-10-30 14:16:25
|
On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > Unfortunately, as I found earlier tonight when trying to add OggFLAC > support to the ogg demuxer, it seems I can't build xine-lib CVS at > present... That old asm error in ffmpeg that apparently Gentoo somehow > fixes with patches but I don't know enough to fix manually =3Dp. i have already merged the gentoo patch to fix ffmpeg build with gcc 4.0.1. Miguel |
From: Brian J. T. <bj...@co...> - 2005-10-30 22:41:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Freitas wrote: > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > >>Unfortunately, as I found earlier tonight when trying to add OggFLAC >>support to the ogg demuxer, it seems I can't build xine-lib CVS at >>present... That old asm error in ffmpeg that apparently Gentoo somehow >>fixes with patches but I don't know enough to fix manually =p. > > i have already merged the gentoo patch to fix ffmpeg build with gcc 4.0.1. Sorry I wasn't more specific. I'm still using gcc 3.4.4. The error I get while doing 'make debug' is: source='mpegvideo_mmx.c' object='mpegvideo_mmx.lo' libtool=yes \ depfile='.deps/mpegvideo_mmx.Plo' tmpdepfile='.deps/mpegvideo_mmx.TPlo' \ depmode=gcc3 /bin/sh ../../../../depcomp \ /bin/sh ../../../../libtool-nofpic --mode=compile gcc -DHAVE_CONFIG_H - -I. -I. -I../../../.. -I../../../.. -I../../../../include - -I../../../../include -I../../../../src -I../../../../src/xine-engine - -I../../../../src/xine-engine -I../../../../src/xine-utils - -I../../../../src/input -I../../../../src/input -I../../../../lib - -DSIMPLE_IDCT -DHAVE_AV_CONFIG_H -DRUNTIME_CPUDETECT -DUSE_FASTMEMCPY - -DCONFIG_RISKY -DCONFIG_DECODERS -DXINE_MPEG_ENCODER -DCONFIG_ZLIB - -DCONFIG_GPL -I../../libavutil -mtune=athlon -O -Wall -D_REENTRANT - -DXINE_COMPILE -g -DDEBUG -UHAVE_MMX -c -o mpegvideo_mmx.lo `test -f 'mpegvideo_mmx.c' || echo './'`mpegvideo_mmx.c gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I../../../.. - -I../../../../include -I../../../../include -I../../../../src - -I../../../../src/xine-engine -I../../../../src/xine-engine - -I../../../../src/xine-utils -I../../../../src/input - -I../../../../src/input -I../../../../lib -DSIMPLE_IDCT - -DHAVE_AV_CONFIG_H -DRUNTIME_CPUDETECT -DUSE_FASTMEMCPY -DCONFIG_RISKY - -DCONFIG_DECODERS -DXINE_MPEG_ENCODER -DCONFIG_ZLIB -DCONFIG_GPL - -I../../libavutil -mtune=athlon -O -Wall -D_REENTRANT -DXINE_COMPILE -g - -DDEBUG -UHAVE_MMX -c mpegvideo_mmx.c -MT mpegvideo_mmx.lo -MD -MP -MF .deps/mpegvideo_mmx.TPlo -fPIC -DPIC -o .libs/mpegvideo_mmx.o In file included from mpegvideo_mmx.c:678: mpegvideo_mmx_template.c: In function `dct_quantize_MMX': mpegvideo_mmx_template.c:105: error: can't find a register in class `GENERAL_REGS' while reloading `asm' In file included from mpegvideo_mmx.c:685: mpegvideo_mmx_template.c:25:1: warning: "PMAX" redefined In file included from mpegvideo_mmx.c:678: mpegvideo_mmx_template.c:37:1: warning: this is the location of the previous definition mpegvideo_mmx.c: At top level: ../../libavutil/rational.h:41: warning: 'av_cmp_q' defined but not used ../../libavutil/rational.h:51: warning: 'av_q2d' defined but not used make[5]: *** [mpegvideo_mmx.lo] Error 1 make[5]: Leaving directory `/foxtrot/src/cvs/xine/xine-lib/src/libffmpeg/libavcodec/i386' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/foxtrot/src/cvs/xine/xine-lib/src/libffmpeg/libavcodec' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/foxtrot/src/cvs/xine/xine-lib/src/libffmpeg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/foxtrot/src/cvs/xine/xine-lib/src' make[1]: *** [debug] Error 2 make[1]: Leaving directory `/foxtrot/src/cvs/xine/xine-lib/src' make: *** [debug] Error 2 -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZUwb6XyW6VEeAnsRAnizAKCC+8G48bcEd5gOIL4R5ro+Hm6rnwCfYoxm LO7cRy/UGO32LlynYH1NW/M= =DOMo -----END PGP SIGNATURE----- |
From: Miguel F. <mfr...@gm...> - 2005-10-30 23:10:16
|
On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > Sorry I wasn't more specific. I'm still using gcc 3.4.4. The error I > get while doing 'make debug' is: > > (...) > mpegvideo_mmx_template.c:105: error: can't find a register in class > `GENERAL_REGS' while reloading `asm' try very last cvs - 5 minutes ago ;-) Miguel |
From: Brian J. T. <bj...@co...> - 2005-11-01 12:12:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Freitas wrote: > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > >>Sorry I wasn't more specific. I'm still using gcc 3.4.4. The error I >>get while doing 'make debug' is: >> >>(...) >>mpegvideo_mmx_template.c:105: error: can't find a register in class >>`GENERAL_REGS' while reloading `asm' > > try very last cvs - 5 minutes ago ;-) Nice, works like a charm ^_^. -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ1uY6XyW6VEeAnsRAmH1AJ4zJNmi4distc9GhUzzLMnMGAovGACeL35Q ID0l7lwNCABt+l46GjpUP5U= =1DyE -----END PGP SIGNATURE----- |
From: Miguel F. <mfr...@gm...> - 2005-10-31 20:15:04
|
On 10/31/05, Darren Salt <li...@yo...> wrote: > xine_play_queue adds an item to an internal queue. mrl_id is a non-null > pointer which the front end can use to identify the item. > > (... description about xine_queue_remove, xine_queue_modify, xine_queue_= flush, ...) Darren, i wouldn't go so fast designing an api like that. imho, chances are this will cripple functionality in the future. for example, the new stream may require setting viz plugins, or setting a slave stream for subtitles... we may well decide in the future that such queue entity needs to store/carry xyz additional information, i don't know. i prefer having small functions that do simple things. open, play, stop, close... all playlist handling, mediamarks, subtitles selection or per stream special attributes is ui's job. just my 2c ;-) Miguel |
From: Bastien N. <ha...@ha...> - 2005-10-30 12:26:44
|
On Sun, 2005-10-30 at 04:04 -0800, Brian J. Tarricone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Miguel Freitas wrote: > > hi Brian, > > > > On 10/30/05, Brian J. Tarricone <bj...@co...> wrote: > > > >>Ok, if it's really just a fraction of a second, I guess I wouldn't mind > >>all that much. The perfectionist in me, though, still cringes a bit > >>that it's not *really* the end of playback ^_~. > > > > > > ;-) > > well, give it a try if you can (xine-lib and xine-ui cvs) and let me know. > > Unfortunately, as I found earlier tonight when trying to add OggFLAC > support to the ogg demuxer, it seems I can't build xine-lib CVS at > present... That old asm error in ffmpeg that apparently Gentoo somehow > fixes with patches but I don't know enough to fix manually =p. > > I'll see about messing with it when I have a bit more energy... Same problem on a RHEL4 and an FC4 machine, both with gcc 3.2 and gcc 4.0. The debug build is even worse, and breaks in ffmpeg as well. I haven't been able to disable MMX acceleration in ffmpeg either, using --disable-optimizations. --- Bastien Nocera <ha...@ha...> |
From: Miguel F. <mfr...@gm...> - 2005-10-30 14:16:48
|
On 10/30/05, Bastien Nocera <ha...@ha...> wrote: > Same problem on a RHEL4 and an FC4 machine, both with gcc 3.2 and gcc > 4.0. The debug build is even worse, and breaks in ffmpeg as well. I > haven't been able to disable MMX acceleration in ffmpeg either, using > --disable-optimizations. everything is compiling fine in my FC4. make debug fails for a few files though. i wished gcc folks stopped breaking asm compilation on every release.... Miguel |
From: Miguel F. <mfr...@gm...> - 2005-10-30 14:47:06
|
On 10/30/05, Miguel Freitas <mfr...@gm...> wrote: > On 10/30/05, Bastien Nocera <ha...@ha...> wrote: > > Same problem on a RHEL4 and an FC4 machine, both with gcc 3.2 and gcc > > 4.0. The debug build is even worse, and breaks in ffmpeg as well. I > > haven't been able to disable MMX acceleration in ffmpeg either, using > > --disable-optimizations. > > everything is compiling fine in my FC4. > make debug fails for a few files though. > > i wished gcc folks stopped breaking asm compilation on every release.... another note: compiles in gcc 3.4.4 too (FC3) make debug fails testsuite log reports: postprocess_template.c: In function `postProcess_MMX': postprocess_template.c:3310: Invalid `asm' statement: postprocess_template.c:3310: fixed or forbidden register 0 (ax) was spilled for class GENERAL_REGS. In file included from postprocess.c:655: but it seems to be a debug compilation. perhaps we should force non-debug in directories that are known to fail? Miguel |
From: Alien <ali...@us...> - 2005-10-30 19:02:36
|
Op zondag 30 oktober 2005 18:40, schreef Michael Roitzsch: > Hi Miguel, > > >> what about crossfading? > > > > of course i thought about it, but it still pretty much an open > > problem for me. > > I agree. Let's go one step at a time. It's just that i thought if the parameter of crossfading is 0, you have=20 effective gapless playing. so, if you're implementing gapless playback, i wonder if it wouldn't=20 automatically work if you account for the crossfading time... (you could al= so=20 supply negative crossfading time to have a gap while playing...) if it needs too much work, we'll do it later, but as long as we're doing=20 gapless, we can think about crossfading while we implement it... > Just a comment about the interface: Wouldn't it be clearer, if we had > a function like xine_play_gapless() instead of this one-shot parameter? > > Michael > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Miguel F. <mfr...@gm...> - 2005-10-30 21:35:58
|
On 10/30/05, Alien <ali...@us...> wrote: > It's just that i thought if the parameter of crossfading is 0, you have > effective gapless playing. Alien, it is not a matter of having a crossfading parameter or not. the problem is that i don't know how the crossfading would be implemented. it might sound like a simple extension of my patch but it is not. the gapless support is basically just disabling a couple of things at the engine to avoid buffers being dropped, audio port being closed and metronom being reset. so output layers will see as if a continuos stream of bytes were provided, no matter it came from different files. crossfading would require some sort of buffering that knows how to mix two sources and a metronom mapping that goes to the past when the new stream is started. conceptually it sounds simple, but i don't know how to implement it cleanly. so it is still an open problem, unless i'm missing something obvious (this is how it worked with the gapless idea ;-) Miguel |
From: Alien <ali...@us...> - 2005-10-31 07:32:00
|
Op zondag 30 oktober 2005 22:35, schreef Miguel Freitas: > On 10/30/05, Alien <ali...@us...> wrote: > > It's just that i thought if the parameter of crossfading is 0, you have > > effective gapless playing. > > Alien, it is not a matter of having a crossfading parameter or not. > the problem is that i don't know how the crossfading would be > implemented. > > it might sound like a simple extension of my patch but it is not. the > gapless support is basically just disabling a couple of things at the > engine to avoid buffers being dropped, audio port being closed and > metronom being reset. so output layers will see as if a continuos > stream of bytes were provided, no matter it came from different files. > > crossfading would require some sort of buffering that knows how to mix > two sources and a metronom mapping that goes to the past when the new > stream is started. > > conceptually it sounds simple, but i don't know how to implement it > cleanly. so it is still an open problem, unless i'm missing something > obvious (this is how it worked with the gapless idea ;-) I understand a small not however, doesn't gapless require audio port not closing and=20 similar things? I just hope it isn't so that when later, the crossfading is implemented, th= at=20 we have a new gapless method on our hands... (crossfading being 0). |
From: Michael R. <mr...@us...> - 2005-10-31 12:20:43
|
Hi, >> Alien, it is not a matter of having a crossfading parameter or not. >> the problem is that i don't know how the crossfading would be >> implemented. >> >> it might sound like a simple extension of my patch but it is not. the >> gapless support is basically just disabling a couple of things at the >> engine to avoid buffers being dropped, audio port being closed and >> metronom being reset. so output layers will see as if a continuos >> stream of bytes were provided, no matter it came from different >> files. >> >> crossfading would require some sort of buffering that knows how to >> mix >> two sources and a metronom mapping that goes to the past when the new >> stream is started. >> >> conceptually it sounds simple, but i don't know how to implement it >> cleanly. so it is still an open problem, unless i'm missing something >> obvious (this is how it worked with the gapless idea ;-) > > I understand > > a small not however, doesn't gapless require audio port not closing > and similar things? > > I just hope it isn't so that when later, the crossfading is > implemented, that we have a new gapless method on our hands... > (crossfading being 0). The gapless stuff is definitely a requirement for crossfading. I think for small crossfade intervals, we could use a post plugin, which simply buffers up enough of the audio stream to calculate the fade in the buffer before sending the data on to the output. Since crossfading is typically used for audio-only playback and audio decoding should be fast enough to fill such a buffer in an acceptable time, I think this should work. Michael |
From: Darren S. <li...@yo...> - 2005-10-31 18:26:56
|
I demand that Miguel Freitas may or may not have written... [snip] > ok, it is easy to ignore events. i just meant that frontend needs a bit > more code to support older xine-lib versions: > xine_open(song_1); > xine_play(); > ... [song #1 is playing] > ... [song #1 is still playing] > - --> XINE_EVENT_UI_PLAYBACK_ALMOST_FINISHED: > xine_set_param(stream, XINE_PARAM_GAPLESS_SWITCH, 1); > xine_open(song_2); > xine_play(); > almost_finished_received = 1; > ... [song #1 is just getting to the end] > - --> XINE_EVENT_UI_PLAYBACK_FINISHED: > if( !almost_finished_received ) { > xine_open(song_2); > xine_play(); > } > set_playlist_selection(); > set_display_title(); > ... [now song #2 is playing] [snip] Or something like this? case XINE_EVENT_UI_STREAM_FINISHED: /* queue an MRL for playback */ xine_queue_play (xine, mrl_id, next_mrl, start_pos, start_time); break; case XINE_EVENT_UI_PLAYBACK_FINISHED: xine_open (xine, next_mrl); xine_play (xine, start_pos, start_time); /* fall through */ case XINE_EVENT_UI_PLAYBACK_NEXT: /* update display here */ xine_play_queue adds an item to an internal queue. mrl_id is a non-null pointer which the front end can use to identify the item. If there is a queued item when playback is finished, you get XINE_EVENT_UI_PLAYBACK_NEXT with mrl_id being passed back as event data; otherwise, you get XINE_EVENT_UI_PLAYBACK_FINISHED with NULL being passed back as event data. (This is so that the display update code can easily determine what is to be displayed regardless of which event is received.) It should be possible to remove an item from the queue at any time by using its mrl_id, e.g. xine_queue_remove (xine, mrl_id); It must not be an error if no matching queued item exists (which should make it possible to unconditionally call the removal function without the front end having to worry about locking). Situations in which this will be used include deleting a playlist entry. Similarly, it should be possible to modify a queued item: something like xine_queue_modify (xine, old_id, new_id, next_mrl, start_pos, start_time); where old_id identifies an already-queued item. Again, no error if there's no matching item. (new_id may be required in case of memory reallocation in the front end, although I would expect that normally, old_id == new_id.) A function will be needed to flush the queue, and another so that the front end can determine whether the queue is empty (which may be useful for things like setting button sensitivity or what should happen when the front end's "playlist next" function is activated); xine_queue_remove could conveniently return this information. -- | Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington, | Debian, | s zap,tartarus,org | Northumberland | RISC OS | @ | Toon Army | <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Don't stop now, we might just as well lock the door and throw away the key. |