[xiph-cvs] cvs commit: snatch README snatchconvert.c

[Monty]

xiphmont    02/02/18 18:03:57

  Modified:    .        README snatchconvert.c
  Log:
  Eliminated soem over-cleverness that prevented piping into the
  conversion routines from working.

Revision  Changes    Path
1.7       +18 -11    snatch/README

Index: README
===================================================================
RCS file: /usr/local/cvsroot/snatch/README,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- README	2001/11/15 08:37:48	1.6
+++ README	2002/02/19 02:03:57	1.7
@@ -1,4 +1,4 @@
-Snatch 20011114
+Snatch 20011125
 
 "The only intuitive interface is the nipple. After that, it's all 
  learned."
@@ -17,11 +17,10 @@
 This technique has the advantages of a) always working, with audio,
 video and live streams and b) being undetectable at the Real Server.
 
-But grabbing the sound and video is relatively trivial (four hours
-begin to end).  Putting it into an easy to use application is what
-took about two weeks.  Snatch also includes a Robot that can issue
-commands to RealPlayer via synthetic X events, allowing a user to set
-up preprogrammed timed recording.
+Grabbing the sound and video is relatively trivial.  Putting it into
+an easy to use application is what took about two weeks.  Snatch also
+includes a Robot that can issue commands to RealPlayer via synthetic X
+events, allowing a user to set up preprogrammed timed recording.
 
 Snatch does not modify, patch or 'crack' RealPlayer in any way and
 [should] work with any RealPlayer8 on any architecture for Linux.
@@ -30,12 +29,20 @@
 they get to the OS, saving the data in a raw format capture file.
 It's important to note that this capture output is *uncompressed* and
 a considerable amount of both disk space and I/O bandwidth is
-necessary for useful capturing.  Five minutes of 240x180 video at
-15fps will eat about a gigabyte of disk space.
-
+necessary for useful capturing.  A half hour of 240x180 video at 15fps
+will eat about two gigabytes of disk space (of course, it's then easy
+to convert to something much smaller.  Snatch doesn't do this during
+capture because a) few machines could keep up and b) it gives the user
+flexibility about encoding in whatever format they prefer later).
 Once saved to disk, the output can be transcoded into any other
-format.  MPEG video is a popular choice, and a convenient filter set
-for the 'mjpeg' tools suite is available.  
+format.  
+
+MPEG-2 video is a popular choice, and a convenient filter set for the
+'mjpeg' tools suite is available.  Although it's true that MPEG-2
+video is not as space efficient as Real, the above mentioned 240x180
+15 fps stream, encoded in Real at 220kbps, will encode into 240x180
+30fps VBR MPEG-2 at 350kbps quite nicely using the mjpeg MPEG-2
+encoder.
 
 <<<****>>> See README-MJPEG for easy directions and pre-patched
 software for encoding Snatch directly to MPEG1/2.

<p><p>1.6       +10 -10    snatch/snatchconvert.c

Index: snatchconvert.c
===================================================================
RCS file: /usr/local/cvsroot/snatch/snatchconvert.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- snatchconvert.c	2001/11/16 04:19:14	1.5
+++ snatchconvert.c	2002/02/19 02:03:57	1.6
@@ -423,13 +423,13 @@
     buftempsize=length;
   }
 
-  if(track_or_process){
+  //if(track_or_process){
     ret=fread(buftemp,1,length,f);
     if(ret<length)return(0);
-  }else{
-    ret=fseek(f,length,SEEK_CUR);
-    if(ret)return(0);
-  }
+    //}else{
+    //ret=fseek(f,length,SEEK_CUR);
+    //if(ret)return(0);
+    //}
 
   if(global_zerotime==0){
     global_zerotime=t;
@@ -733,13 +733,13 @@
       buftemp=malloc(length*sizeof(*buftemp));
     buftempsize=length;
   }
-  if(notfakep){
+  //if(notfakep){
     ret=fread(buftemp,1,length,f);
     if(ret<length)return(0);
-  }else{
-    ret=fseek(f,length,SEEK_CUR);
-    if(ret)return(0);
-  }
+    //}else{
+    //ret=fseek(f,length,SEEK_CUR);
+    //if(ret)return(0);
+    //}
 
   if(global_zerotime==0){
     global_zerotime=t;

<p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'cvs-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.