Device Reset and "app: init failed" - firmware issue?

[GoogleCodeExporter]

What steps will reproduce the problem?
Build recent crusher264 lib from SVN on ARM system (Seagate Dockstar)
Run crusher264 or ffmpeg on a test file.

When doing so, in both cases the device gets a reset (dmesg output)

[ 6779.231900] usb 1-1.4: reset high speed USB device using orion-ehci and 
address 7

and an error (see bottom).

I'm not all through the code but I guess it is an issue when uploading the 
firmware to the device.

crusher264 Output:

# crusher264 -i /root/test.mp4 -o /root/text.flv -d
[DEBUG] app: Picture size: 640x480
[DEBUG] app: IN: /root/test.mp4, OUT: /root/text.flv dev=0 fmt=es
[INFO] app: You have encoder device
[INFO] app: Optimisations:
[DEBUG] app: YFrame=640x480 (640x480), iUVFrame=640x256 (10x8).
[DEBUG]: firmware version=3221357203
[DEBUG] app: init failed

Emptying the firmware directory leads into crusher264 complaining about missing 
fw:

root@debian:/usr/src# crusher264 -i /root/test.mp4 -o /root/text.flv -dd
[DEBUG] app: Picture size: 640x480
[DEBUG] app: IN: /root/test.mp4, OUT: /root/text.flv dev=0 fmt=es
[INFO] app: You have encoder device
[INFO] app: Optimisations:
[DEBUG] app: YFrame=640x480 (640x480), iUVFrame=640x256 (10x8).
[ERROR]: Open file 
/usr/local/share/crusher264/firmware/qmmapp.seve1-eb-16mb.bin failed.
[DEBUG] app: init failed

Copying back only the requested fw file brings up the first crusher264 output 
shown above. FX2Firmware.hex seems not to be touched.
So I guess there is an issue.

ffmpeg output:

# ffmpeg -i /root/test.mp4 -f flv -vcodec libcrusher264 -deinterlace -g 25 -r 
25 -sc_threshold 1 -b 500k -s 320x240 -acodec aac -ab 64k -ac 1 -ar 22050 -y 
/root/test.flv

FFmpeg version UNKNOWN, Copyright (c) 2000-2010 the FFmpeg developers
  built on Dec 14 2010 19:40:06 with gcc 4.4.5
  configuration: --enable-gpl --enable-libcrusher264 --enable-version3 --enable-nonfree --enable-postproc --enable-pthreads --enable-shared
  libavutil     50.14. 0 / 50.14. 0
  libavcodec    52.66. 0 / 52.66. 0
  libavformat   52.61. 0 / 52.61. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale     0.10. 0 /  0.10. 0
  libpostproc   51. 2. 0 / 51. 2. 0
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/root/test.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 0
    compatible_brands: mp41isom3gp5
  Duration: 00:00:53.63, start: 0.000000, bitrate: 4490 kb/s
    Stream #0.0(eng): Video: mpeg4, yuv420p, 640x480 [PAR 1:1 DAR 4:3], 4450 kb/s, 27.30 fps, 60 tbr, 1k tbn, 60 tbc
    Stream #0.1(eng): Audio: aac, 48000 Hz, mono, s16, 48 kb/s
[DEBUG]: firmware version=3221357203
[libcrusher264 @ 0x46a10]init failedOutput #0, flv, to '/root/test.flv':
    Stream #0.0(eng): Video: libcrusher264, nv12, 320x240 [PAR 1:1 DAR 4:3], q=2-31, 500 kb/s, 90k tbn, 25 tbc
    Stream #0.1(eng): Audio: aac, 22050 Hz, mono, s16, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Error while opening encoder for output stream #0.0 - maybe incorrect parameters 
such as bit_rate, rate, width or height

When -vcodec libcrusher264 Option is removed, software encoding works without 
flaws.

My kernel version:
# uname -a
Linux debian 2.6.32-5-kirkwood #1 Wed Oct 20 12:58:44 UTC 2010 armv5tel 
GNU/Linux

Original issue reported on code.google.com by rockd...@hotmail.com on 14 Dec 2010 at 10:15

[GoogleCodeExporter]

fx2firmware.hex used only once, when device in "cold state", after first start 
of patched ffmpeg or crusher264 app.

are You sure, that You using uncompressed yuv file as input for crusher264 
application? also keep in mind, that it produces raw h264 video (so-calles 
elementary stream) as output.

Original comment by piratfm@gmail.com on 24 Dec 2010 at 12:40

[GoogleCodeExporter]

I have the same issue rockd.
@piratfm do you have a example "uncompressed yuv file" that should work?
Thanks

Original comment by p.hafne...@gmail.com on 24 Dec 2010 at 11:45

[GoogleCodeExporter]

here is example of ffmpeg command-line, that creates uncompressed yuv file:

$ ffmpeg -i test.mpg -f rawvideo -an -deinterlace -s 640x480 -pix_fmt yuv420p 
-y test640x480.yuv

Original comment by piratfm@gmail.com on 25 Dec 2010 at 4:29