Jump to content

JMCC

Members
  • Posts

    941
  • Joined

  • Last visited

Reputation Activity

  1. Like
    JMCC got a reaction from chwe in RK3288 Media Script (TinkerBoard)   
    Finally, the version 2.0 for Armbian Bionic is out! Check the OP for documentation and download link.
     
    CHANGELOG:
    Updated all necessary packages to work with Ubuntu Bionic Updated versions of MPV and Kodi Added the GL4ES wrapper, to provide OpenGL support (thanks @jock for the tips). In order to use it, you must launch your app from command line using the wrapper "glrun" RELEASE NOTES:
    I'm not sure whether the Widevine library is still working with newer versions of Chrome, and I don't have access to Netflix anymore to test it. Some feedback on this point is welcome. I'm still including the old cgminer as OpenCL example. If you want to try more recent algorithms and experiment with GPU mining just for fun, I recommend you to have a look to this sgminer for from the ODROID community (it works also with RK3288): https://github.com/hominoids/sgminer-arm As I said, just for learning, curiosity or fun. Trying to get money with a Tinkerboard is a waste of time. Plus, I think the whole crypto-mining idea is absurd, basing the value of a currency on wasting as much electricity as possible  Remember you need a default (4.4.y) kernel for HW video acceleration to work. It is not yet implemented in mainline (4.14.y).  
     
  2. Like
    JMCC got a reaction from TRS-80 in Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
    Hold the ffmpeg packages, so they don't get upgraded:  
    $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  3. Like
    JMCC got a reaction from jock in RK3288 Media Script (TinkerBoard)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  4. Like
    JMCC got a reaction from Tido in RK3288 Media Script (TinkerBoard)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  5. Like
    JMCC got a reaction from x86demon in RK3288 Media Script (TinkerBoard)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  6. Like
    JMCC got a reaction from TonyMac32 in RK3288 Media Script (TinkerBoard)   
    Nope, mali binaries take care of everything.
     
    BTW, Bionic version of the script is done, I'm just brushing up the documentation.
  7. Like
    JMCC got a reaction from manuti in Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
    Hold the ffmpeg packages, so they don't get upgraded:  
    $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  8. Like
    JMCC reacted to chwe in Daily (tech related) news diet   
    After all those bad news.. It's time again to show a nice one.  
    https://solar.lowtechmagazine.com
    They host their blog now on an olimex lime2 with Armbian and a solar cell. Besides switching to a static website they also used dithering to reduce the image size (and a nice retro look for those who like it).  I really appreciate that they provide a detailed article with the technical details as well:
    https://homebrewserver.club/low-tech-website-howto.html
    with how to's and a bunch (or everything?) of scripts open-sourced. For me it looks like a well crafted setup. But I'm neither a EE nor @tkaiser (for the OS related reduction of power consumption) to give a proper statement. But they're open for improvements, so let them know if you spot something.  
     
  9. Like
    JMCC got a reaction from r3dl4nce in Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
    Hold the ffmpeg packages, so they don't get upgraded:  
    $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  10. Like
    JMCC got a reaction from Nerten in Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
    Hold the ffmpeg packages, so they don't get upgraded:  
    $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  11. Like
    JMCC reacted to Igor in board support - general discussion / project aims   
    There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough. People perception on this is very colorful and even among inner circle, we have different views. No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable.
     
    Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility.
     
    If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from?

    On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... 
     
    We can talk about how to reshape the project, but first, you need someone that will execute what we brained out. 
     
    Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have. 
  12. Like
    JMCC got a reaction from Adoby in Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
    Hold the ffmpeg packages, so they don't get upgraded:  
    $ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  13. Like
    JMCC got a reaction from usuario74 in VPN Server Questions   
    You should also consider processor speed and whether the kernel supports HW crypto acceleration. I have tried openvpn both in an OrangePi+ 2e (Allwinner H3), and an Odroid XU4, and performance is an order of magnitude faster in the XU4.
     
    H5 has ARMv8 crypto extensions, so just make sure you choose a kernel that supports them.
  14. Like
    JMCC reacted to TonyMac32 in RK3288 Media Script (TinkerBoard)   
    The armbianmonitor -m output demonstrated this wasn't a proper Armbian image, his cpufreq was dropping down to 200-ish MHz.  We are set to minimum 600, as otherwise there is too much latency for no power savings
  15. Like
    JMCC got a reaction from Tido in RK3288 Media Script (TinkerBoard)   
    That output seems incomplete, something went wrong. In any case, make sure the output of 'uname -r' shows that you are using the Default (4.4.y) version of the kernel. Or maybe it is better to just wait two or three weeks, and I'll try to release the Bionic version by then.
  16. Like
    JMCC reacted to magic0whi in Librecomputer Renegade RK3328   
    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
     
  17. Like
    JMCC got a reaction from tkaiser in NanoPI M4   
    Well, FFmpeg's RKMPP support includes only decoding so far, so not many chances that Plex/Emby will support accelerated encoding for RK3399 anytime soon. Gstreamer should be pretty well supported, in theory just as RK3288, but I haven't tested it. Now I'm returning to SBC's after some weeks, so I'll make sure to test video encoding when I do the RK3399 media script, God willing.
  18. Like
    JMCC reacted to TonyMac32 in Librecomputer Renegade RK3328   
    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
     
     
  19. Like
    JMCC got a reaction from switch in Librecomputer Renegade RK3328   
    It seems like a normal number to me.
  20. Like
    JMCC reacted to switch in Librecomputer Renegade RK3328   
    Here you go: 
    For reference the card is a SanDisk Ultra 8gb HC I class 10 (at least that's what's printed on it).
     
    PS I previously stated that my board shows 4GB but I'd just like to confirm.. 'free -m' shows 3924, which is normal for 4GB right?
  21. Like
    JMCC reacted to Igor in Librecomputer Renegade RK3328   
    Edit /etc/default/armbian-zram and disable it.
  22. Like
    JMCC reacted to TonyMac32 in Next major upgrade v5.60   
    That's fine, I'm not too worried about the work needed, I've made the board work with 2 different kernel sources at this point, and mainline, and almost (at least in between commit-tastrophe's) the current Rockchip one.  As long as the thingy is stable and behaves itself we're good. 
  23. Like
    JMCC reacted to chwe in Next major upgrade v5.60   
    Fork it now and then stabilize it..  
     
    Actually I would prefer to get all RK SoCs under one hood. So, when we're able to get RK3399/RK3328 and RK3288 properly working with Ayufans kernel. Well then there's simply no reason to stay with the RK kernel. Okay there's no ISP1 driver  but this thingie doesn't work properly anyway (as soon as we think about DTBOs , I keep my rk default branch 'as is' in case we try it once again to get the ISP working without break everything else). 
     
    Reducing 'supported kernels' without dropping boards sounds good.  Might make sense to move this discussion to here? 
     
    Let me know when you want things from here moved to it.  
  24. Like
    JMCC reacted to Myy in Next major upgrade v5.60   
    I'm currently watching a conversation between Tomasz Figa (Member of the Chromium team) and a developer named Baruch Siach about how to port the V4L2 driver to the mainline kernel.
    Meanwhile, now that I got a roughly good idea on how DMA and IOMMU interoperate, and a documentation of the VPU registers (that was not easy due to the split of the drivers informations between the Rockchip VPU driver and their MPP codebase),
    I'm currently :
    trying to get a patched version of MPP working on 4.4 kernel working on a spare MiQi, using @JMCC scripts; get a snapshot of a H264 frame sent to the VPU, with all the VPU registers parameters, with that patched MPP; reproduce this in my last driver and see how it fares.  
    Now, I had to a few troubles, between the fact that my current job takes (too much) time, a few bugs had to be dealt with, I had to buy a second screen because using my main screen and unplugging the HDMI output of my Radeon Vega is a NO-NO due to some vega driver bug (I have to report this bug...)... And I still need to get a few things setup to make the whole Tinkerboard/MiQi/RK3399 juggling painless.
     
    The reason I have to peek MPP memory buffers instead of producing a H264 naked frame by myself is that : I currently don't know how to produce a H264 by myself (there's a few tutorials here and there...), and there's a lot of parameters in this standard that require a very good understanding of how video work in general, and some extensive knowledge of the norm. I mean, just computing the dimensions of a frame requires some special math that is not intuitive.
     
    Still, if I can send a frame to VPU and have it decoded, than I will be able to focus on trying to get with working with the V4L2 API, which seems to be setup for GPU<->VPU communication, reusing the code Tomasz Figa wrote for the Chromium team.
  25. Like
    JMCC reacted to Igor in Librecomputer Renegade RK3328   
    Restored.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines