Jump to content

Librecomputer Renegade RK3328


Igor

Recommended Posts

@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.

Link to comment
Share on other sites

Armbian & Khadas are rewarding contributors

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.
 

image.png.436300b8e0c92e7709422c6a1db8ba24.png

 

 

 

 

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.
 

image.png.5cbdc529c87047eb7c98e4648b6108f5.png

 

Link to comment
Share on other sites

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'.

Link to comment
Share on other sites

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.. :angry:  

 

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?

Link to comment
Share on other sites

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.. :angry:  

 

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

TS120GMTS420_JMS578.jpg

 

JMS578_M2.jpg

 

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Dante4
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines