Preparing for a Prototype


One of the points in etcher's favor,, it checks what has been written
If you have older or crapier cards ....
It is a bit slow with usb2
 
Etcher has been around for quite a while long before baleno took over. i have been using it for years and several Linux youtube channels have recomended it .
 
Or:
Code:
dd if=input.img of=/dev/carddevice bs=n
diff input.img /dev/carddevice
I would suggest to add "status=progress && sync" to dd line
Code:
dd if=input.img of=/dev/carddevice bs=n status=progress && sync
diff input.img /dev/carddevice
 
  • Like
Reactions: rSl
I would suggest to add "status=progress && sync" to dd line
Code:
dd if=input.img of=/dev/carddevice bs=n status=progress && sync
diff input.img /dev/carddevice
I'd suggest using a semicolon rather than a double and. You don't really care whether dd thinks it's succeeded or not, you want to flush the buffers anyway. But thanks for the hint about status=progress, I've not tried that yet, even though these days when copying files over network shares or USB 2 links I'm more likely to use rsync with --progress rather than cp, which technically would suffice, just doesn't give me anything much until a transfer completes.
 
  • Like
Reactions: rSl
And how many people ACTUALLY do this?
>diff input.img /dev/carddevice

In the SBC community, lots of newbies don't realize how crappy most flash is,
wonder why it doesn't work so well (or not at all) Over 90% of flash is crap (for SBC),,
It IS OK for camera use or general storage
 
I'd suggest using a semicolon rather than a double and. You don't really care whether dd thinks it's succeeded or not, you want to flush the buffers anyway. But thanks for the hint about status=progress, I've not tried that yet, even though these days when copying files over network shares or USB 2 links I'm more likely to use rsync with --progress rather than cp, which technically would suffice, just doesn't give me anything much until a transfer completes.
There is also progress command which checks the progress for most file transfers (dd/cp/rsync etc.) so if you miss --progress you can run below in separate terminal
Code:
progress -M
 
Over 90% of flash is crap (for SBC),,
It IS OK for camera use or general storage
Depends on exactly how crap it is. I have a card that decided spontaneously to blank it's first 8K one day. And there certainly used to be large SD cards sold that were actually small SD card with a hacked header, and if you used those in a camera, you'd keep losing pictures.
 
Well, etcher will certainly detect fake flash, even amazon has sold fake flash,
you should ALWAYS run f3probe on a new card (or h2testw, is that name right?)
But so will the diff command, if the card is more than 25% full
The problem is when it wraps, fills up the real size rather than the lying size
But, to explain, when writing 4k or 16k, all uSD are slow, 10% speed or less
Crap cards are 1% speed, so apt-get upgrade,, well, come back tomorrow
 
Just my 2cent onthe risky dd of=/dev/sdX:
Take a look into /dev/disk/by-id/ on my systems usb and sdcards are pretty often easy to spot there. USB-xyz....
Years ago I did the dmesg trick, too. But fingers are to fast and sometimes I dd‘ed the wrong disk;-). Never happened again after I learned about by-id
 
Regarding the idea I had above for limiting CPU usage on games/applications to save battery - it looks like I'm not the only one who has had that revelation.

Nvidia is now allowing laptop mobile gamers to set an upper threshold at the GPU for 'maximum framerate'.

No, I haven't found time to try to unwind the suggestions above regarding using additional Linux apps to apportion CPU to individual applications - it looks promising though - thank you!
 
On an odd whim I tried something odd but interesting. I opened up one of my .mp4 files under FireFox. Video playback worked, but no sound. I'll have to play with that some more. Maybe I should try the same thing in Chromium.

Synaptic - Chromium - mark - apply - 12 seconds to download - ~40 seconds to install. About a minute and a quarter end to end.

Works. With sound. Not smooth. Audio and video pauses out frequently. Both cores of the CPU peg out to 100%. But, considering that it is resolving video and audio all in software - pretty cool that it works at all. I wonder what it will take to get H.264 decode working properly?

Does this help anyone with ideas for getting H.264 decode running?
https://e2e.ti.com/support/legacy_f...=e2e-sitesearch&keymatch=h.264%252520omap5432
 
Last edited:
I think the installed FireFox is missing some codecs, as some Youtube-Videos have sound, others not.
 
If you have ffprobe installed (it's part of package ffmpeg in arch at least) then you can figure out what format the audio stream actually is in.
#apt install ffmpeg
ffprobe Stargate_SG1_S1_DVD01_1_1-25_RF20_.mp4
Switching to Pyra to load the pages of output in copy/paste...

root@Marble:/media/grench/PanMedia/Videos/TV/Stargate# ffprobe Stargate_SG1_S1_DVD01_1_1-25_RF20_.mp4
ffprobe version 4.1.4-1~deb10u1 Copyright (c) 2007-2019 the FFmpeg developers
built with gcc 8 (Debian 8.3.0-6)
configuration: --prefix=/usr --extra-version='1~deb10u1' --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --arch=arm --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Stargate_SG1_S1_DVD01_1_1-25_RF20_.mp4':
Metadata:
major_brand : mp42
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 2017-05-13T04:16:39.000000Z
encoder : HandBrake 0.10.5 2017031700
Duration: 01:36:57.27, start: 0.000000, bitrate: 1172 kb/s
Chapter #0:0: start 0.000000, end 337.837000
Metadata:
title : Chapter 1
Chapter #0:1: start 337.837000, end 555.513000
Metadata:
title : Chapter 2
Chapter #0:2: start 555.513000, end 697.739000
Metadata:
title : Chapter 3
Chapter #0:3: start 697.739000, end 983.608000
Metadata:
title : Chapter 4
Chapter #0:4: start 983.608000, end 1343.717000
Metadata:
title : Chapter 5
Chapter #0:5: start 1343.717000, end 1592.174000
Metadata:
title : Chapter 6
Chapter #0:6: start 1592.174000, end 1704.536000
Metadata:
title : Chapter 7
Chapter #0:7: start 1704.536000, end 2075.073000
Metadata:
title : Chapter 8
Chapter #0:8: start 2075.073000, end 2300.840000
Metadata:
title : Chapter 9
Chapter #0:9: start 2300.840000, end 2484.440000
Metadata:
title : Chapter 10
Chapter #0:10: start 2484.440000, end 2690.396000
Metadata:
title : Chapter 11
Chapter #0:11: start 2690.396000, end 2915.746000
Metadata:
title : Chapter 12
Chapter #0:12: start 2915.746000, end 3058.389000
Metadata:
title : Chapter 13
Chapter #0:13: start 3058.389000, end 3262.926000
Metadata:
title : Chapter 14
Chapter #0:14: start 3262.926000, end 3595.759000
Metadata:
title : Chapter 15
Chapter #0:15: start 3595.759000, end 3871.367000
Metadata:
title : Chapter 16
Chapter #0:16: start 3871.367000, end 4067.689000
Metadata:
title : Chapter 17
Chapter #0:17: start 4067.689000, end 4205.660000
Metadata:
title : Chapter 18
Chapter #0:18: start 4205.660000, end 4417.371000
Metadata:
title : Chapter 19
Chapter #0:19: start 4417.371000, end 4813.434000
Metadata:
title : Chapter 20
Chapter #0:20: start 4813.434000, end 5205.534000
Metadata:
title : Chapter 21
Chapter #0:21: start 5205.534000, end 5575.111000
Metadata:
title : Chapter 22
Chapter #0:22: start 5575.111000, end 5743.529000
Metadata:
title : Chapter 23
Chapter #0:23: start 5743.529000, end 5817.145000
Metadata:
title : Chapter 24
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 720x362 [SAR 32:27 DAR 1280:543], 653 kb/s, 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc (default)
Metadata:
creation_time : 2017-05-13T04:16:39.000000Z
handler_name : VideoHandler
Stream #0:1(eng): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, stereo, fltp, 256 kb/s (default)
Metadata:
creation_time : 2017-05-13T04:16:39.000000Z
handler_name : Stereo
Side data:
audio service type: main
Stream #0:2(eng): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s
Metadata:
creation_time : 2017-05-13T04:16:39.000000Z
handler_name : Stereo
Stream #0:3(eng): Data: bin_data (text / 0x74786574)
Metadata:
creation_time : 2017-05-13T04:16:39.000000Z
handler_name : SubtitleHandler
Unsupported codec with id 100359 for input stream 3
 
Youtube videos are being encoded for both h.264+AAC and VP9+Opus, the website simply favors choosing VP9+Opus. Which is a PITA if you only have a h.264 hardware decoder, there are Firefox plugins like h264ify that will fix this.

The difference between videos that work and those that don't work might be related to whether they exist in DASH variants on the server, which basically splits the audio and video stream into separate files. It is mandatory for 60 FPS videos but probably unavailable for many older videos, especially for lower resolutions.
 
I'm not at all sure about that. I usually predownload my videos using a dash algorithm, h264+HC_AAC ends up in a combined mkv file and VP9+Opus is more likely to end up in a webm file at my end. Both work in mplayer and vlc so I've not worried too much about it to be honest.
 
There's no hardware accelerated decoding on Linux in web browsers anyways. At least not in official builds.
You'll be better off passing those videos to mpv or something. Still needs one of the GPU decoding APIs to be implemented for OMAP5, though.
 
Back
Top