[Elphel-support] Recording fullHD JP4 being limited to 7 seconds
Sebastian Pichelhofer
sebastian.pichelhofer at gmail.com
Thu Apr 26 00:55:03 PDT 2012
On Thu, Apr 26, 2012 at 09:32, flavio soares <qazav3.0 at gmail.com> wrote:
> Hi, Andrey,
>
> Sorry, I was rebooting, that's what kept me. Here is the result for
> both cards (even though I can't really understand what it means):
>
> [root at Elphel353 /root]3882# hdparm -I /dev/hdb
>
> /dev/hdb:
>
> ATA device, with non-removable media
> Model Number: CF CARD 4GB
> Serial Number: 00003C2E
> Firmware Revision:
> Standards:
> Likely used: 5
> Configuration:
> Logical max current
> cylinders 8060 8060
> heads 16 16
> sectors/track 63 63
> --
> CHS current addressable sectors: 8124480
> LBA user addressable sectors: 8124480
> device size with M = 1024*1024: 3967 MBytes
> device size with M = 1000*1000: 4159 MBytes (4 GB)
> Capabilities:
> LBA, IORDY(may be)(cannot be disabled)
> bytes avail on r/w long: 4
> Queue depth: 1
> Standby timer values: spec'd by Vendor
> R/W multiple sector transfer: Max = 1 Current = 0
> DMA: mdma0 mdma1 *mdma2
> Cycle time: min=120ns recommended=120ns
> PIO: pio0 pio1 pio2 pio3 pio4
> Cycle time: no flow control=120ns IORDY flow control=120ns
> HW reset results:
> CBLID- below Vih
> Device num = 1
> [root at Elphel353 /root]3882# hdparm -I /dev/hda
>
> /dev/hda:
>
> ATA device, with non-removable media
> Model Number: CF CARD 4GB
> Serial Number: 00003C48
> Firmware Revision:
> Standards:
> Likely used: 5
> Configuration:
> Logical max current
> cylinders 8060 8060
> heads 16 16
> sectors/track 63 63
> --
> CHS current addressable sectors: 8124480
> LBA user addressable sectors: 8124480
> device size with M = 1024*1024: 3967 MBytes
> device size with M = 1000*1000: 4159 MBytes (4 GB)
> Capabilities:
> LBA, IORDY(may be)(cannot be disabled)
> bytes avail on r/w long: 4
> Queue depth: 1
> Standby timer values: spec'd by Vendor
> R/W multiple sector transfer: Max = 1 Current = 0
> DMA: mdma0 mdma1 *mdma2
> Cycle time: min=120ns recommended=120ns
> PIO: pio0 pio1 pio2 pio3 pio4
> Cycle time: no flow control=120ns IORDY flow control=120ns
> HW reset results:
> CBLID- below Vih
> Device num = 0
>
>
> Thanks for the link, I'll check on it soon. I have a really good
> graphic card here, but my Iceweasel is not up to the task =) I'll
> reboot and check it with chrome!
>
> ps.: Do you think it's too dangerous to test the Sata the way I
> mentioned? My computer is actually open at the moment with a Sata
> literally hanging on it (backuping). =)
It should work fine that way!
With the right cards or an external HDD you should get up to 12-15
MByte/s writespeed
There are 2 issues with datarate:
-) When using streamer at the same time as camogm the streamer takes
up CPU resources and reduces the maximum datarate camogm can record
before it will overflow
-) PHP calls can also take up CPU resources and reduce camogm datarate
before it overflows, camogmgui itself polls the camera to get updates
and therefore reduces datarate. Its a balance of staying informed and
keeping resources free ;) I lowered the poll frequency in camogmgui to
2 per second (if I remember correctly) to help with PHP resources. If
you want the best possible conditions you can try sshing to the camera
and killing both str (streamer) and all php instances. Then you need
to start recording from the command-line though -> more infos on the
well documented camogm wiki page:
http://wiki.elphel.com/index.php?title=Camogm#start
Regards Sebastian
>
> 2012/4/26, Andrey Filippov <support-list at support.elphel.com>:
>>>
>>> Hello, Andrey, thanks for the quick response!
>>>
>> You are welcome , Flavio
>>
>>>
>>> I'm also online (here it is 3:40am) =)
>>>
>>
>> Not that late he - less than 1AM :-)
>>
>>>
>>> My Kingston cards are not listed in the blacklist. Let's get them to
>>> work and see how far they go. Here are the results of the tests, I'm
>>> ssh-ed into the cam:
>>>
>>> [root at Elphel353 /mnt/0]944# time dd if=/dev/circbuf of=/dev/null
>>> 38656+0 records in
>>> 38656+0 records out
>>> real 0m 0.42s
>>> user 0m 0.03s
>>> sys 0m 0.39s
>>> [root at Elphel353 /mnt/0]944# time dd if=/dev/circbuf of=/dev/hdb1
>>> 38656+0 records in
>>> 38656+0 records out
>>> real 0m 6.75s
>>> user 0m 0.19s
>>> sys 0m 2.46s
>>> [root at Elphel353 /mnt/0]944#
>>>
>>> If I understood correctly, my card takes 6.75 seconds to write the
>>> 19MB and 19 MB / 6.75 = 2.8MB/s should be the maximum data rate my
>>> cards can handle, is that it?
>>>
>>
>> Yes, the cards are in PIO mode so seem to be disabled. And as I wrote - it
>> is not only that they are ~16/2.8 ~= 5.5 times slower than those in DMA
>> mode, they use CPU much more during recording, so no resources fro other
>> CPU tasks.
>>
>> Can you try them with hdparm -I and send the reply? The CPU-limited
>> recording rate in DMA mode should be ~16MB/s
>>
>>
>>>
>>> Meanwhile, I've tested normal HD JP4, at 720p and observed that
>>> compression 100% is a killer, but at about 90%, the recording
>>> proceeded without cutting the video, even tough the gui refresh rate
>>> suffered.
>>>
>>
>> Yes that is so - 90% is really good quality. It may also make sense to
>> fine-tune coring value () in addition to JPEG quality to find the best
>> overall quality/image size ratio.
>> With Eyesis we use 97-98%, but that is only because we use aberration
>> correction by de-convolution that amplifies the noise and artifacts. BTW -
>> here are our last panoramas made with the new camera (viewing requires good
>> videocard and WebGL-capable browser)
>> http://community.elphel.com/files/eyesis/pano-db-3/webgl_panorama_editor.html?kml=mainstreet_ro.kml&proto=mainstreet_ro.kml&ntxt=2&as_camera=95&start=result_1334548264_780764_1.jpeg&range=95&labels=false&keepzoom=false&closest2d=false&seethrough=0.4&transition=5&mask=&azimuth=23.2&elevation=-70.5&zoom=0.386&follow=false&mv3d=false
>>
>>
>>>
>>> ps.: I considered buying the Sundisk Extreme III, but I saw they were
>>> not being sold at B&H at the moment. =/ If there is any other you
>>> would recommend...
>>>
>>
>> I'll ask here tomorrow, but I think recently we only used that card
>> (different capacities)
>>
>> Andrey
>>
>>
>>>
>>> 2012/4/26, Andrey Filippov <support-list at support.elphel.com>:
>>> > Hello Flavio,
>>> >
>>> > Most likely the problem is related to the CF - as I wrote in that old
>>> > article, most CF cards in IDE mode lie about support of the DMA mode.
>>> They
>>> > do support UDMA so most people never notice that small lie. But Axis
>>> > CPU
>>> > used in the camera has a bug of it's own - and this bug is related to
>>> > the
>>> > UDMA. If the card would hostly report that it does not support DMA
>>> > camera
>>> > driver would just go to PIO mode (ABSOLUTELY NOT SUITABLE for the video
>>> > recording - both slow and using to much of the camera CPU resources),
>>> > but
>>> > it does not, so camera may hang up and never come out of the boot
>>> scripts.
>>> > So what we did was to add some known "bad" cards to the driver black
>>> list:
>>> >
>>> >
>>> >
>>> http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/os/linux-2.6-tag--devboard-R2_10-4/drivers/ide/ide-dma.c?view=markup(lines
>>> > 130..136).
>>> >
>>> > At some point we black-listed all no-name cards (we did not find any
>>> among
>>> > them that did support DMA) You may use hdparm -I (from
>>> > http://192.168.0.9/phpshell.php, telnet or serial console that you
>>> should
>>> > have cable for) and the only way to re-enable (if you card matches the
>>> > black-listed one) the card is to modify that file and recompile the
>>> camera
>>> > firmware. The only type of CF cards we use ourselves is "Sandisk
>>> > Extreme
>>> > III".
>>> >
>>> > When the card is blacklisted, camera bots correctly and is able to
>>> > mount
>>> > (and use) the card - it can be used to save images or very slow video
>>> > (still useful for timelapse), but not the normal video.
>>> >
>>> > You may test the speed of the CF card (that test will destroy data on
>>> it!)
>>> > with the following command (again - phpshell, telnet, serial console):
>>> >
>>> > time dd if=/dev/circbuf of=/dev/hda #(or hdb - depending how is the
>>> > card
>>> > inserted/configured)
>>> >
>>> > /dev/circbuf is the circular buffer ~19MB in size that is very fast to
>>> read
>>> > for the camera, so the speed will be related to the CF itself
>>> >
>>> > You may try it on /dev/null first:
>>> >
>>> > [root at Goniometer /dev]16713# time dd if=/dev/circbuf of=/dev/null
>>> > 38656+0 records in
>>> > 38656+0 records out
>>> > real 0m 0.43s
>>> > user 0m 0.11s
>>> > sys 0m 0.32s
>>> >
>>> > With phpshell you may just open the following link (provided you have
>>> > the
>>> > default IP) - just replace all spaces in the command line with "+"
>>> > signs
>>> >
>>> http://192.168.0.9/phpshell.php?command=time+dd+if=/dev/circbuf+of=/dev/null
>>> >
>>> > Then divide 19MB by the time measured.
>>> >
>>> > Andrey
>>> >
>>>
>>> _______________________________________________
>>> Support-list mailing list
>>> Support-list at support.elphel.com
>>> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>>>
>>
>
> _______________________________________________
> Support-list mailing list
> Support-list at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
More information about the Support-list
mailing list