[pvrusb2] Re: xawtv recording?

[Bill Crowell]

Mike Isely wrote:

> On Wed, 9 Nov 2005, Simon Lachinger wrote:
>
>>> --- Ursprüngliche Nachricht ---
>>> Von: Frans Meulenbroeks <fransmeulenbroeks at yahoo.com>
>>> An: pvrusb2 at isely.net
>>> Betreff: [pvrusb2] Re: xawtv recording?
>>> Datum: Tue, 8 Nov 2005 23:12:15 -0800 (PST)
>>>
>>>
>>>> For recording, all you really have to do is:
>>>>
>>>> $ cat /dev/v4l/video0 > recorded.mpg
>>>
>>>
>>> Note that this only works to a certain size.
>>> On my 2.6.14 kernel this stopped after scribbling 2 GB
>>> (which is in the default settting of 6 Mbit/s less
>>> than 1 hr of video). So this is ok for a short show,
>>> but not for a movie (unless you want to give up
>>> quality).
>>>
>>> Frans
>>>
>>
>> That way I've recorded whole films each with a file size way beyond 2GB.
>> What file system did you use? The 2GB boundary sounds strangely 
>> familiar to
>> me (VFAT?)..
>>
This holds true for ext3 and is a generic limit as Mike has explained 
below. We've found this limit with growisofs doing backups. I've also 
noticed this on DVD media - multiple mpg files that are read 
sequentially. Mike's command is a great start to simplifying output to a 
file; however, the data should be piped to a buffering program to create 
multiple files that are <= 2GB.

$ cat /dev/v4l/video0 > | mpegsplitterthingy -f recorded.mpg

Where the output would be: recorded.mpg, recorded1.mpg, recorded2.mpg, 
etc. Each at the boundary. The splitter would hold the data in a fifo 
buffer during the write(), goto next file.

> 2GB is the single file size limit you will encounter for ANY file 
> system when using 32 bit file access semantics.  If, for example, your 
> app depends on using lseek(), that function uses a 32 bit pointer 
> which limits you to 2GB (well, 4GB, but file offsets have 
> traditionally been signed ints, which gives you only 31 bits or 2GB of 
> addressing range).  There is another call (llseek()?  not sure..) 
> which uses a 64 bit pointer and thus avoids the limit.  So it may not 
> matter at all what the underlying file system is, if the app is using 
> system calls which can't get past 32 bits of addressing.  I wouldn't 
> be surprised if the apparent conflicting answers here might be due to 
> xawtv being configured differently in each case.  Check your config 
> step results - there may be something there which enables the use of 
> 64 bit addressed file I/O.  Note: This is wild speculation; I have no 
> special experience about xawtv which would tell me that this is the 
> root cause, and under NO circumstance am I volunteering here to start 
> trying to support big sticky ball of mud otherwise known as xawtv :-)
>
>   -Mike
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>pvrusb2 mailing list
>pvrusb2 at isely.net
>http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>  
>

-- 
William G. Crowell, VP & CTO
Crowell Systems
4235 South Stream Blvd Suite 100
Charlotte  NC 28217
704.665.2000 fax 704.665.2180