switch Posted July 17, 2018 Posted July 17, 2018 @JMCC I'm not sure I understand the issue you're experiencing but I had an instance when I was unable to write (to /boot/ iirc), despite using sudo. Solved it by using the root account instead. Also, I am experiencing some speed hiccups (temporary freezing) but I cannot recreate it at will. I do suspect things run snappier on my Raspberry Pi (e.g. during apt install) and I find myself a bit disappointed with the speed of the Renegade. Also in xfce. I do not know if this is due to the card itself (slow r/w which causes temporary freezing), or bugs in the Armbian image, or whatever else. 0 Quote
tkaiser Posted July 17, 2018 Posted July 17, 2018 13 minutes ago, switch said: I do suspect things run snappier on my Raspberry Pi (e.g. during apt install) Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back. 0 Quote
switch Posted July 17, 2018 Posted July 17, 2018 1 hour ago, tkaiser said: Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back. I ran 'iostat 5' in a separate ssh sesh but I don't know how to identify anomalies. I also don't know how to interpret if there are any issues with the iozone results but here's the output: SanDisk Ultra 8gb Spoiler Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 2132 2224 7632 7648 6723 803 102400 16 7335 6989 15353 15359 14942 98 102400 512 10399 8716 23070 23060 20331 2336 102400 1024 11002 11727 23244 23237 23062 4767 102400 16384 11045 10120 23407 23405 21016 9174 iozone test complete. SanDisk Extreme 32gb Spoiler Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3232 3316 10065 9965 9276 4512 102400 16 8299 8482 17180 17186 17069 10857 102400 512 21183 21135 23120 23130 23141 20726 102400 1024 22535 22556 23286 23298 23292 21853 102400 16384 22243 22289 23462 23451 23451 22479 iozone test complete. 0 Quote
tkaiser Posted July 18, 2018 Posted July 18, 2018 12 hours ago, switch said: I also don't know how to interpret if there are any issues with the iozone results but here's the output Yesterday you only showed numbers and picture of a 'normal' SanDisk 8GB card. Those are horribly slow when it's about random IO especially at 16K block size (the SanDisk Extreme you tested later is over 100 times faster here). Usually just this makes the difference when comparing 'apt install' or 'apt update/upgrade' performance since apt does a lot of random reads and writes (and issues sync calls with the latter to ensure changes are committed to storage in the appropriate order so a crash while installing or updating won't screw up the whole package management). See here for another nice report about 'random IO storage performance making the real difference'. 1 Quote
switch Posted July 18, 2018 Posted July 18, 2018 Thanks for the explanation, @tkaiser. I'm assuming manufacturers do not provide data about the random IO performance of their cards, hence why we're left to test them ourselves.. It looks like the Extreme card that I tested even outperforms the Extreme Pro in your tests. but I suppose it also depends on the device used for testing. Perhaps a positive data point if we're trying to determine the Renegade's sd card read/write capabilities? 0 Quote
tkaiser Posted July 18, 2018 Posted July 18, 2018 24 minutes ago, switch said: I'm assuming manufacturers do not provide data about the random IO performance of their cards, hence why we're left to test them ourselves.. Not relevant any more since it's 2018 (and we can buy A1 or even A2 rated cards). I added a dynamic link to the thread and adjusted first post accordingly: Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato). Please keep in mind that my SanDisk Extreme Pro from almost 4 years ago can not be compared to something called 'SanDisk Extreme' from 2018 (since all this stuff improves) 1 Quote
EndtheFED Posted August 5, 2018 Posted August 5, 2018 Just an observation. The SD card performance is not part of why I bought this board. I have a cheap old 8 gig card (years old 10 rating?) and it works well enough to install Armbian and boot Armbian from my USB3.0 thumb drive. A 32gig USB memory stick cost $10. Even tough you need an SD card also, it seems the faster, cheaper way to go. I'm impressed with the speed of the memory stick . 15 second boot and lightning fast upgrade Unless SD cards can match eMMC or USB3.0 it seems like a waste IMHO. All you need it for is booting USB3.0 Tomorrow my USB 3.0 SSD dock+built in USB 3.0 Hub will arrive. Hope it will boot from that too. I'll let you know if anyone cares. 0 Quote
tkaiser Posted August 6, 2018 Posted August 6, 2018 6 hours ago, EndtheFED said: I'm impressed with the speed of the memory stick Care to provide numbers from a quick iozone benchmark as described here: https://forum.armbian.com/topic/954-sd-card-performance/? I tested some 'quality' pendrives last year and was highly disappointed about the performance after some time or usage. Nice performance when starting to use them but after some time or amounts of write performance really started to suck. The only 'pendrive' working flawlessly so far looks like this for me: A real M.2 SATA SSD with heatsinks to prevent overheating/throttling on a JMS578 adapter. Without heatsink and with enclosure closed also unusable since the SSD overheats too much (sequential transfers then drop from 400 MB/s to ~30 MB/s) 6 hours ago, EndtheFED said: All you need it for is booting USB3.0 Why should everybody have the same needs? Users might want to attach a HDD to the USB3 port then 'booting from USB3' is not an option any more as long as you want the HDD to spin down. Putting an USB hub between host and disk is always a great idea to introduce problems. 1 Quote
EndtheFED Posted August 7, 2018 Posted August 7, 2018 I see your point. My hope was always for booting SSD. Both worked without new problems so far. The memory stick was a test, before I spent $30 on a dock. I'd be glad to test the SanDisk Ultra 32Gig USB 3.0 stick (It has no heatsink so, looks like a problem). Should the test be run headless? Also should I run iozone in auto? I'm a noob, who can follow directions well. I only have 2 no name and 2 PNY SD cards. The no name are over 3 years old and, second hand. The 1 PNY is at least a year old . The other is 2 years old. So I'm sure you don't want any those. 0 Quote
tkaiser Posted August 7, 2018 Posted August 7, 2018 1 hour ago, EndtheFED said: I'd be glad to test the SanDisk Ultra 32Gig USB 3.0 stick (It has no heatsink so, looks like a problem). Should the test be run headless? If you boot off the stick already then it's as easy as cd $HOME cpufreq-set -g performance iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 I bought 3 different SanDisk pendrives last year (all USB3) and they showed nice sequential performance that dropped after few minutes of use since the things started to throttle down. And with random IO (which is the important metrics on SBC or computers in general) they all sucked horribly after some time. I then tested on macOS putting some virtual machines on the fastest stick and attached it to an USB3 port of a MacBook Pro. Unusable since all my 3 sticks are simply overwhelmed by increased random IO workloads. 0 Quote
EndtheFED Posted August 7, 2018 Posted August 7, 2018 You are right! Performance dropped quick. It's taking a couple of min to do a line now. I killed the test, as it was going way too slow. I don't want to burn anything up. SSD had no problems with iozone testing. I also notice instability in all installs. SSD seems constant but not right.eg. desktop is off until enabled in config or startx command. Sound works on start of desktop unlike SD and USB stick installs Sorry I bothered you lol. You taught me a lot. Keep up the good work! Being a noob I will just observe from now on, unless I see a way to help. 0 Quote
EndtheFED Posted August 8, 2018 Posted August 8, 2018 18 hours ago, tkaiser said: 19 hours ago, EndtheFED said: I'd be glad to test the SanDisk Ultra 32Gig USB 3.0 stick (It has no heatsink so, looks like a problem). Should the test be run headless? If you boot off the stick already then it's as easy as cd $HOME cpufreq-set -g performance iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Running correctly now. I ran iozone -a only lol. I'll post on the right thread when it's done. 0 Quote
switch Posted August 14, 2018 Posted August 14, 2018 On 7/18/2018 at 10:22 AM, tkaiser said: Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato). Is there anything I can do to assist in this, e.g. reach out to Firefly and ask them for certain settings? I would need to know exactly what to ask them. To everyone: besides the SD issues, do all other functions seem to be running smoothly on the Renegade with this image, in your testing? or is there anything else I should ask Firefly when I contact them. Thx guys 0 Quote
JMCC Posted August 15, 2018 Posted August 15, 2018 On 8/14/2018 at 10:45 AM, switch said: reach out to Firefly and ask them for certain settings Precisely the lines in the dtb that disable fast SD card modes are taken from recent Firefly's kernel patches (see here and here). As a matter of fact, I am using the official Firefly image, that was compiled before they pushed those patches, and SD card works perfectly with it. I'm not sure why they did it, but it seems like in Armbian it makes the image bootable, though some people (like me) are unable to use the system more than a few seconds before SD card starts failing. My findings point in the direction that, for some reason, voltage selection is not working in our images. Could be a u-boot problem, or some patch from Ayufan that is not in the original Rockchip image that Firefly uses. I tried to troubleshoot it in the past, with no luck. Right now, I am a bit absent from Armbian due to personal reasons, but it seems like @Da Xue is also working on the issue. 0 Quote
Da Xue Posted August 15, 2018 Posted August 15, 2018 1 hour ago, JMCC said: Precisely the lines in the dtb that disable fast SD card modes are taken from recent Firefly's kernel patches (see here and here). As a matter of fact, I am using the official Firefly image, that was compiled before they pushed those patches, and SD card works perfectly with it. I'm not sure why they did it, but it seems like in Armbian it makes the image bootable, though some people (like me) are unable to use the system more than a few seconds before SD card starts failing. My findings point in the direction that, for some reason, voltage selection is not working in our images. Could be a u-boot problem, or some patch from Ayufan that is not in the original Rockchip image that Firefly uses. I tried to troubleshoot it in the past, with no luck. Right now, I am a bit absent from Armbian due to personal reasons, but it seems like @Da Xue is also working on the issue. S905X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough. You see degradation of the signal and some cards are more accommodating to this than others. S905X does not have reset lines for power cycling MicroSD cards which becomes an issue when you reboot and the board tries to go back to UHS mode from non-UHS. Samsung cards that I've tested will plain drop dead while Sandisk will not re-enter UHS mode. A board power cycle becomes necessary. The SoC was designed for SD cards to be pushed in and out and did not really consider using them as boot devices. eMMC is the way to go for these SoCs. 0 Quote
TonyMac32 Posted August 15, 2018 Posted August 15, 2018 9 hours ago, Da Xue said: S905X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough. On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue. Is that possible with the RK3328 at least? I think the mmc IP is the same, but don't quote me on that. [edit] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432 This part of the dtsi shows the default 4 mA drive levels for the pins. Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429 It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979 2 Quote
sswd Posted August 22, 2018 Posted August 22, 2018 Second SD card failed with this SoC. As mentioned, eMMC is really the only way to go. 0 Quote
JMCC Posted August 22, 2018 Posted August 22, 2018 On 8/15/2018 at 11:37 PM, TonyMac32 said: It would stand to reason you could do the same with RK3328 Worth giving a try, but RK3328's DT seems more complex when it comes down to sdmmc: https://github.com/torvalds/linux/blob/df2def49c57b4146520a1f4ca37bc3f494e2cd67/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1371 Would you change all the entries? I'm not sure whether the SoC supports multiple SD cards, or it is just that the DT needs to have different entries for the one card reader. 0 Quote
TonyMac32 Posted August 22, 2018 Posted August 22, 2018 It's applied per pin associated with the peripheral, so unless there's some drive strength multiplexing you should only define it for the desired SD pins. I haven't had an issue with mine, but I also haven't stressed it so I'll give it a look some time. (Next couple days I am a slave to my company, it will be 14 hours/day).Sent from my Pixel using Tapatalk 0 Quote
magic0whi Posted September 23, 2018 Posted September 23, 2018 In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by a special output only gpio pin labeled "gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10. https://patchwork.kernel.org/patch/10550013/ original kernel also changed the file drivers/regulator/gpio-regulator.c in commet https://github.com/rockchip-linux/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380 1 Quote
JMCC Posted September 23, 2018 Posted September 23, 2018 6 hours ago, arkua233 said: In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by a special output only gpio pin labeled "gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10. https://patchwork.kernel.org/patch/10550013/ original kernel also changed the file drivers/regulator/gpio-regulator.c in commet https://github.com/rockchip-linux/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380 Well, there are some kernel configs in the first commit referenced here, that we are not enabling. They may very likely be the cause for the board not booting when you enable vcc_sdio. I think it is worth giving a try. But someone else will have to test it in a Rock64 to make sure these configs don't affect it, since I only have the Renegade. 0 Quote
jpegxguy Posted October 29, 2018 Posted October 29, 2018 Have any of you guys tried mainline kernel? Anything after 4.4.y-rockchip64 and the Ethernet doesn't work. More here 0 Quote
Dante4 Posted December 15, 2018 Posted December 15, 2018 I'm trying to build working player for this board via mpv or gstreamer. (spoiler - i failed). Here is total list of command (ubuntu commads.txt) i have tried to make this work. First i load all the library that ever may be needed (is that error?), then i has downloaded github master version of libmali+mpp+rockchip-gstreamer+rockchip-gstreamer-extra+ffmpeg+mpv+mpv-build. Then i did for libmali cd libmali && cmake CMakeLists.txt && make && make install && ldconfig for mpp cd mpp && cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make -j4 && make install && ldconfig for gstreamer there was a bit of change, since rkximage seems to be main idea behind all players commands i found around, so instead of ./autogen.sh --disable-rkximage && make i did nano gst/rkximage/rkx_kmsutils.c and changed DEF_FMT(NV12_10, P010_10LE) to DEF_FMT(NV12, P010_10LE) Yes, i have only roughly idea that this line was for 10 bits (maybe?), but my knowledge limited to googling and i failed to google how to actually fix it, so i did that. At least it complied. Then i did ./autogen.sh && make -j4 && make install && ldconfig and same thing for gstreamer-rockchip-extra nano gst/rkximage/rkx_kmsutils.c and changed DEF_FMT(NV12_10, P010_10LE) to //DEF_FMT(NV12_10, P010_10LE) nano gst/kms/gstkmsutils.c DEF_FMT(NV12_10, P010_10LE) to //DEF_FMT(NV12_10, P010_10LE) This video Spoiler Format : AVC Bit rate : 40.8 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 29.970 (30000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits goes fine This video Spoiler Format : VP9 Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 60.000 FPS Color space : YUV slideshow. This video Spoiler Format : AVC Bit rate : 18.7 Mb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 30.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits results in ** (gst-play-1.0:24108): CRITICAL **: 15:20:22.782: gst_dmabuf_memory_get_fd: assertion 'gst_is_dmabuf_memory (mem)' failed Using gstreamer-rockchip from here doesn't solve anything. mpv...Just building it with correct flags and libmali doesn't do any good and results and errors like Spoiler [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. gbm: failed to open any driver (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri) gbm: Last dlopen error: /usr/lib/dri/rockchip_dri.so: cannot open shared object file: No such file or directory failed to load driver: rockchip This https://github.com/ayufan-rock64/linux-build/blob/master/recipes/video-playback.md allow me to start 4k60fps as..30 fps video, but it's still fails on 10 bits refusing to show anything with this Spoiler [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Could not choose EGLConfig! [vo/gpu/drmprime-drm] Failed to create framebuffer on layer 0. But maybe someone already walked this path and know how to make 10 bits video work on any kind of image of Linux with gstreamer or mpv? 8 bits can be player up to 4k60fps..but 10 bits? just black screen on any image except Libreelec from firefly site 0 Quote
JMCC Posted December 15, 2018 Posted December 15, 2018 Libreelec has some patches to libdrm for 10-bit formats: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/libdrm 1 Quote
Dante4 Posted December 16, 2018 Posted December 16, 2018 (edited) 1 hour ago, JMCC said: Libreelec has some patches to libdrm for 10-bit formats: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/libdrm Should have asked here before (or actually look at libreelec building process, since i have problem with alpha images of this too), thank you, i will look how i can apply this to mpv or gstreamer..and can i Edited December 16, 2018 by Dante4 0 Quote
Dante4 Posted December 16, 2018 Posted December 16, 2018 2 hours ago, JMCC said: Libreelec has some patches to libdrm for 10-bit formats: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/libdrm @JMCC THANK YOU SO MUCH. Now i can finally watch 1080p30fps10bits! Perfectly fine!... So.. This is so "obviously" that you need to type this lines in libdrm and i'm just didn't knew it because i'm actually newbie and it's common knowledge? But why it's nowhere to be found by error link or actually somewhere in any clones of gstreamer-rockchip? 0 Quote
JMCC Posted December 16, 2018 Posted December 16, 2018 12 hours ago, Dante4 said: @JMCC THANK YOU SO MUCH. Now i can finally watch 1080p30fps10bits! Perfectly fine!... So.. This is so "obviously" that you need to type this lines in libdrm and i'm just didn't knew it because i'm actually newbie and it's common knowledge? But why it's nowhere to be found by error link or actually somewhere in any clones of gstreamer-rockchip? No, it is not obvious. I knew it because I had to deal with the LibreElec source tree when I was preparing the RK-enabled Kodi for the Tinker Board . RK used to have their own version of libdrm, but for some reason they discontinued the project. ASUS TinkerOS still included the library as of version 2.0.5, not sure if it is present in last release. 2 Quote
TonyMac32 Posted December 16, 2018 Posted December 16, 2018 On 8/22/2018 at 2:13 PM, sswd said: Second SD card failed with this SoC. As mentioned, eMMC is really the only way to go. On 8/15/2018 at 8:22 AM, Da Xue said: 05X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough. I forgot this came up in this topic, I have modified the rk3328.dtsi to use 8mA drive strength on all rk3328 boards, that will fix the issues for most users as far as the electrical interface is concerned (it is default 4 mA). 12 mA is available, if someone spends enough time rigorously testing to determine it's needed (probably edge cases with crappier than normal cards or poorly routed designs with too much capacitance) Rock64 was having the same complaints. https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519 For S905X, I'm afraid I haven't found a way to change the output drive level. 1 Quote
Dante4 Posted December 16, 2018 Posted December 16, 2018 3 hours ago, JMCC said: No, it is not obvious. I knew it because I had to deal with the LibreElec source tree when I was preparing the RK-enabled Kodi for the Tinker Board . RK used to have their own version of libdrm, but for some reason they discontinued the project. ASUS TinkerOS still included the library as of version 2.0.5, not sure if it is present in last release. Just in case, maybe you know how to make gstreamer full-screen? As far as i understood i need actually gstreamer-player to do this, but ./ayamero-player not really helpful with error text and if i hardcode path to file and videosink it just says "Segmentation fault" when i try to start it ./player from /usr/lib/aarch64-linux-gnu/qt5/examples/multimediawidgets/player/ refuse to decode any video saying that he don't see any decoder for video any advice there? P.S. https://github.com/rockchip-linux/rk-rootfs-build/tree/f788d8eb06b1aab5d8c3207d901afb500f2e01ba/packages/arm64/libdrm it was there just 5 month ago, and now they deleted it and their gstreamer don't work properly...just why? 0 Quote
JMCC Posted December 16, 2018 Posted December 16, 2018 On 12/16/2018 at 6:50 PM, Dante4 said: Just in case, maybe you know how to make gstreamer full-screen? As far as i understood i need actually gstreamer-player to do this You can copy-paste this code into a root console, and it will give you a Qt5 player using the RK GStreamer plugin: apt-get -y install qtgstreamer-plugins-qt5 gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good gstreamer1.0-plugins-base libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html echo '#!/usr/bin/env xdg-open [Desktop Entry] Type=Application Name=Rockchip Gst Player GenericName=Media Player Comment=A gstreamer base player Exec=env QT_GSTREAMER_WIDGET_VIDEOSINK=rkximagesink /usr/lib/aarch64-linux-gnu/qt5/examples/multimediawidgets/player/player --geometry 960x640+0+0 Icon=/usr/share/icons/gnome/48x48/categories/applications-multimedia.png Terminal=false Categories=Qt;AudioVideo;Player;Video; MimeType=application/ogg;application/x-ogg;application/mxf;application/sdp;application/smil;application/x-smil;application/streamingmedia;application/x-streamingmedia;application/vnd.rn-realmedia;application/vnd.rn-realmedia-vbr;audio/aac;audio/x-aac;audio/vnd.dolby.heaac.1;audio/vnd.dolby.heaac.2;audio/aiff;audio/x-aiff;audio/m4a;audio/x-m4a;application/x-extension-m4a;audio/mp1;audio/x-mp1;audio/mp2;audio/x-mp2;audio/mp3;audio/x-mp3;audio/mpeg;audio/mpeg2;audio/mpeg3;audio/mpegurl;audio/x-mpegurl;audio/mpg;audio/x-mpg;audio/rn-mpeg;audio/musepack;audio/x-musepack;audio/ogg;audio/scpls;audio/x-scpls;audio/vnd.rn-realaudio;audio/wav;audio/x-pn-wav;audio/x-pn-windows-pcm;audio/x-realaudio;audio/x-pn-realaudio;audio/x-ms-wma;audio/x-pls;audio/x-wav;video/mpeg;video/x-mpeg2;video/x-mpeg3;video/mp4v-es;video/x-m4v;video/mp4;application/x-extension-mp4;video/divx;video/vnd.divx;video/msvideo;video/x-msvideo;video/ogg;video/quicktime;video/vnd.rn-realvideo;video/x-ms-afs;video/x-ms-asf;audio/x-ms-asf;application/vnd.ms-asf;video/x-ms-wmv;video/x-ms-wmx;video/x-ms-wvxvideo;video/x-avi;video/avi;video/x-flic;video/fli;video/x-flc;video/flv;video/x-flv;video/x-theora;video/x-theora+ogg;video/x-matroska;video/mkv;audio/x-matroska;application/x-matroska;video/webm;audio/webm;audio/vorbis;audio/x-vorbis;audio/x-vorbis+ogg;video/x-ogm;video/x-ogm+ogg;application/x-ogm;application/x-ogm-audio;application/x-ogm-video;application/x-shorten;audio/x-shorten;audio/x-ape;audio/x-wavpack;audio/x-tta;audio/AMR;audio/ac3;audio/eac3;audio/amr-wb;video/mp2t;audio/flac;audio/mp4;application/x-mpegurl;video/vnd.mpegurl;application/vnd.apple.mpegurl;audio/x-pn-au;video/3gp;video/3gpp;video/3gpp2;audio/3gpp;audio/3gpp2;video/dv;audio/dv;audio/opus;audio/vnd.dts;audio/vnd.dts.hd;audio/x-adpcm;application/x-cue;audio/m3u; ' > /usr/share/applications/demo-player.desktop 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.