Hi! Ralph Glasstetter wrote:
>>.... And it will be >>confusing for users if the player sometimes works and sometimes doesn't. > > > And because of that you prefer a solution that works just for the first file? > That's also confusing, when playback stops working after a certain position... Au contraire - I prefer a solution that works everywhere, while preserving all functionality we had before, including navigation. Unfortunately, that's something I currently can't offer. Nor can anybody else. >>But I guess I have a solution that allows either mode: Change dvbcut to >>call "dvbcut-player" instead of "mplayer". dvbcut-player could be a >>symlink to mplayer or a wrapper for an arbitrary player, written in >>whatever language seems appropriate. That way you can a) massage the >>arguments as you see fit and b) use any player you want. Other players >>may not display inside the dvbcut window, but I do not consider that a >>big problem - if you want an inline display, use mplayer. > > > OK, this will give the user more flexibility (and is easy to implement), > but does not help if you provide just the first file to dvbcut-player... :-| Of course we will pass all filenames. Even the ones at the beginning that end before the current position - in case the user wants to navigate backwards. > Also the user would have to write a wrapper, which has to disentangle > the mplayer specific options and build the correct ones accepted by his > player. Another option would be to pass them in environment variables (e.g. WINDOWID, WIDTH and HEIGHT). But then you'll need a wrapper for mplayer as well, a simple symlink will no longer work. > It would be more convenient (in future) to have a configuration > dialog where one could specify the called player with options and variables, > .i.e. > something like "mplayer -sb %relativebyteposition% %currentfile%". That's it. But I would prefer to handle the variables in a wrapper. We can even provide different wrappers for different players, and .bat and .sh versions for Windows and Unix. What we can't do, however, is use variable substitutions on the command line. QProcess doesn't call a shell, so we will have to expand them either inside dvbcut or inside the wrapper. The latter is the more generic solution. > That way one also could define %absolutebyteposition% and %filelist% > or even additionally %timestamp%, %firstfile%,... > > > >>>>>Only the mplayer playback stops at the end of the file but that's no big >>>>>problem... just start it again a few frames later... :-) >>>> >>>>That's not really a solution. Not even a workaround, in my opinion. >>> >>> >>>Not a 100% solution, but better than playing just the first file... ;-) >> >>Oh well... I guess we best solve this problem "by declaration" for now: >>You can concatenate several files, you can play arbitrary scenes, but >>you can't do both at the same time. > > > "Declaration" stops any discussion... but ok... if other users don't bother. It's not that they may bother, but that they need to know what they can expect and what they can't. And if they need to play arbitrary scenes, there currently is only one solution: use a single input file. > Maybe in future someone will find a perfect solution and as long as we > don't have it I can apply my 'play99%'-patch by myself... it don't has to go > to > the repository, of course. Don't worry, the patch will go in ASAP. It may not be a perfect solution, but it's a good base for further development. > That's why we like open source software, don't we... ;) Absolutely. >>>>>BTW, ... you could now, as we have multi file support, put "*.tts*" and >>>>>"*.rec*" to the recognized file list, since TFtool (Windows) is naming >>>>>the topfield files movietitle.tts, movietitle.tts1, movietitle.tts2 ... >>>>>:-) >>>> >>>>And the file after xy.tts9 is xy.tts10? Next can of worms. :-( >>> >>> >>>Don't know,.... never had more than 3 files... but does it matter? >>>*.tts* will also show xy.tts10 and the file order is anyhow in the users own >>>responsibility, as you already wrote. >>>I can't see any worm... :) >> >>dvbcut *.tts* -> instant disaster. > > > Of course, but that has nothing to do with the "recognized files" in > settings.h...!?! No, not at all. But it is another possible cause for errors. > Anyway,.. the users can also include that by themself in dvbcut.sf.netrc (or > the code) and > since it's just a very special case which only occures with Topfield > Receivers & TFtool > under Windows it's probably the better way. Nah... it's not a problem at all to change *.tts to *.tts* and so on. And since we know that topfield receivers (and also VDR, as far as I know) split the files, we should provide appropriate defaults. > PS: I hope you are not too upset by my... "annoying comments"... > Please don't understand me wrong... > I very much appreciate and honor the work you've done!!! NP. I appreciate a good discussion. Michael. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
