Le samedi 20 mars 2010 11:47:36, David Baelde a écrit :
> Yo,

        Yep !

Well, I have been looking around, and, you know me, I find the quick and dirty 
solution the most appealing..

In the code of a protocol, you may always create a request and resolve it.
Hence, you can take the remaining part of the URI, create a request from it 
and resolve it.

Once you have done that, you may process the resulting file, creating a new 
temporary file, and return this new URI as a temporary file.

The good thing is that we do not have to change the resolution code, only the 
protocols that need a reverse resolution may do this. Additionally, the 
problem of the temporary file is resolved as well: if the file from the 
previous 
resolution is temporary, it will be remove when the intermediate request is 
destroyed.

The bad thing is that we loose track of the intermediate request resolution 
log. A possible solution is to add an extra parameter for the protocol 
registration, which allows to pass a log along with the new indicators..

Attached is a patch that implement the cut_file protocol along these lines..

Romain

> On Sat, Mar 20, 2010 at 10:47 AM, Romain Beauxis <[email protected]> 
wrote:
> >  * I do not think there is any way to know whether a file is temporary or
> > not when handling it in the resolution process. This is a problem because
> > the cut protocol may cut a temporary track, and in this case need to
> > remove the old file, or cut a static file, and in this case should not
> > touch it.
> 
> You're right, and it's even worse than that: the design originally
> relied on the assumption that only the last protocol allocates a file
> (the "temporary" cleanup system doesn't treat a stack but at most one
> file). What you're trying to do, like replaygain, is hackish in the
> current design -- in fact I just looked at the code of annotate and it
> is hackish too, since it relies on the ad-hoc possibility to attach
> metadata to an URI.
> 
> >  * Also, I wonder if it would be possible to reverse the protocol
> > resolution. So far, protocol resolution is done from left to right.
> > Hence, requests like: replaygain:ftp://path/to/bla.mp3
> > do not work.
> > Could it be possible to reverse the resolution and start with resolving
> > ftp: first and then pass it to replaygain ?
> 
> The only protocols that take another URI as parameter are replaygain,
> annotate and your planned cut, so the order is only relevant for them,
> and the order you propose is the right one for them. So your
> proposition seems relevant. However, the real problem is to know if
> the argument of an indicator is supposed to be another indicator. If I
> write "http://foo:8000/...";, there is a risk of seeing a nested
> indicator "foo:8000/..." (the // prevents it but it's just luck). The
> point is that only the protocol knows if its argument is an indicator.
> 
> Hence a different proposal: let such protocols perform the resolution
> of their argument indicator. This would currently require to create a
> new request and resolve it, which is a bit unsatisfying. That might
> call for more power to the protocols, e.g. direct access to the
> request being resolved, as you proposed in your first point. This
> first solution has the disadvantage of breaking modularity, allowing
> all kind of stuff to the protocol resolvers, and might not even be so
> convenient. Another way to go is that such protocols don't reply with
> a new indicator, but also with a continuation that should be applied
> to the request once it's resolved. This is more appealing, although it
> still allows all sort of wild behavior.
> 
> HTH
> 
> David
> 
> ---------------------------------------------------------------------------
> --- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Savonet-devl mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/savonet-devl
> 
Index: scripts/utils.liq
===================================================================
--- scripts/utils.liq	(révision 7225)
+++ scripts/utils.liq	(copie de travail)
@@ -494,6 +494,50 @@
 end
 add_protocol("replay_gain", replaygain_protocol)
 
+# Register the cut protocol
+def cut_protocol(arg,delay)
+ # The extraction program
+ cut_file = "#{configure.libdir}/cut-file"
+ # Parse args 
+ ret = string.extract(pattern="cut_start=(\d+)",arg)
+ start = 
+   if list.length(ret) == 0 then 
+     "0"
+   else
+     ret["1"]
+   end
+ ret = string.extract(pattern="cut_stop=(\d+)",arg)
+ stop =
+   if list.length(ret) == 0 then
+     "0"
+   else
+     ret["1"]
+   end
+ ret = string.extract(pattern=":(.*)$",arg)
+ uri = 
+   if list.length(ret) == 0 then
+     ""
+   else
+     ret["1"]
+   end
+ # Create a request and resolve it
+ r = request.create(uri)
+ if request.resolve(r) then
+   file = request.filename(r)
+   x = get_process_lines("#{cut_file} #{quote(file)} #{start} #{stop}")
+   request.destroy(r)
+   if list.hd(x) != "" then
+    [list.hd(x)] 
+   else
+    [arg]
+   end
+ else
+  request.destroy(r)
+  [arg]
+ end
+end
+add_protocol("cut_file", temporary=true, cut_protocol)
+
 # Enable replay gain metadata resolver. This resolver will
 # process any file decoded by liquidsoap and add a @replay_gain@
 # metadata when this value could be computed. For a finer-grained
Index: scripts/cut-file
===================================================================
--- scripts/cut-file	(révision 0)
+++ scripts/cut-file	(révision 0)
@@ -0,0 +1,90 @@
+#!/usr/bin/perl -w
+
+use strict ;
+
+my $file = $ARGV[0] || die ;
+
+my $start = $ARGV[1] || "0" ;
+
+my $stop = $ARGV[2] || "0" ;
+
+sub mktemp {
+  my $file = `mktemp --tmpdir --suffix=".osb" "liqXXXX"`;
+  $file =~ s/\n//;
+  $file;
+}
+
+my $out_file = mktemp(); 
+
+sub test_mime {
+  my $file = shift ;
+  if (`which file`) {
+    return `file -b --mime-type "$file"`;
+  }
+}
+
+if (($file =~ /\.mp3$/i) || (test_mime($file) =~ /audio\/mpeg/))  {
+
+  if (`which cutmp3`) {
+
+    my $start_option = "00:00";
+    my $stop_option = "99999:0";
+
+    if ($start ne "0") {
+       $start_option = "00:$start"
+    } 
+  
+    if ($stop ne "0") {
+       $stop_option = "00:$stop"
+    }
+ 
+    system("nice -n 20 cutmp3 -c -q -a $start_option -b $stop_option -O \"$out_file\" -i \"$file\" >/dev/null 2>\&1");
+    print "$out_file\n" ;
+
+  } else {
+
+    print STDERR "Cannot find cutmp3 binary!\n";
+    system("cp \"$file\" \"$out_file\"");
+    print "$out_file\n";
+
+  }
+
+} elsif (($file =~ /\.ogg$/i) || (test_mime($file) =~ /application\/ogg/)) {
+
+  if (`which vcut`) {
+
+    my $start_file = $file;
+
+    # Cut beginning
+    if ($start ne "0") {
+       my $handle;
+       $start_file = mktemp();
+       system("nice -n 20 vcut \"$file\" /dev/null \"$start_file\" +$start  >/dev/null 2>\&1"); 
+    }
+
+    # Cut end
+    if ($stop ne "0") {
+       system("nice -n 20 vcut \"$start_file\" \"$out_file\" /dev/null +$stop >/dev/null 2>\&1"); 
+    } else {
+      if ("$start_file" ne "$file") {
+        system("mv $start_file $out_file");
+      }
+    }
+
+    print "$out_file\n" ;
+
+  } else {
+
+    print STDERR "Cannot find vcut binary!\n";
+    system("cp \"$file\" \"$out_file\"");
+    print "$out_file\n";
+
+  }
+
+} else {
+
+  print STDERR "File format not supported...\n";
+  system("cp \"$file\" \"$out_file\"");
+  print "$out_file\n";
+
+}

Modification de propriétés sur scripts/cut-file
___________________________________________________________________
Ajouté : svn:executable
   + *

Index: scripts/Makefile
===================================================================
--- scripts/Makefile	(révision 7221)
+++ scripts/Makefile	(copie de travail)
@@ -1,6 +1,6 @@
 
 DISTFILES = $(wildcard *.in) Makefile ask-liquidsoap.rb ask-liquidsoap.pl \
-	    $(wildcard *.liq) extract-replaygain
+	    $(wildcard *.liq) extract-replaygain cut-file
 
 top_srcdir = ..
 include $(top_srcdir)/Makefile.rules
Index: Makefile
===================================================================
--- Makefile	(révision 7221)
+++ Makefile	(copie de travail)
@@ -76,6 +76,7 @@
 	$(INSTALL_DIRECTORY) $(libdir)/liquidsoap/$(libs_dir_version)
 	$(INSTALL_PROGRAM) scripts/liquidtts $(libdir)/liquidsoap/$(libs_dir_version)
 	$(INSTALL_PROGRAM) scripts/extract-replaygain $(libdir)/liquidsoap/$(libs_dir_version)
+	$(INSTALL_PROGRAM) scripts/cut-file $(libdir)/liquidsoap/$(libs_dir_version)
 	$(INSTALL_DATA) scripts/utils.liq $(libdir)/liquidsoap/$(libs_dir_version)
 	$(INSTALL_DIRECTORY) ${sysconfdir}/liquidsoap
 	$(INSTALL_DATA) examples/radio.liq \
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl

Répondre à