[pvrusb2] Re: xawtv recording?
bill at crowellsystems.com
Wed Nov 9 07:58:37 CST 2005
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
>> 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 :-)
>pvrusb2 mailing list
>pvrusb2 at isely.net
William G. Crowell, VP & CTO
4235 South Stream Blvd Suite 100
Charlotte NC 28217
704.665.2000 fax 704.665.2180
More information about the pvrusb2