pagenotfound
Posts: 124
Joined: Mon Mar 14, 2016 12:44 pm

Re: Future of raspberry pi - software related

Sat Jan 25, 2020 3:43 pm

W. H. Heydt wrote:
Sat Jan 25, 2020 4:32 am
pagenotfound wrote:
Sat Jan 25, 2020 4:21 am
My wishlist:

1. Anything that reduces card wear. The Overlay File System is great. Please keep and maintain it.

However, sometimes that's a little too radical. Currently on one of my Pi4s I have various tmp, var, log and cache directories on tmpfs. It kind of works but it's still not an optimal solution. So I'd be grateful for any ideas you come up with.
Hardware fix for that...don't use an SD card. Here's an example of how not to add a lot of bulk...https://www.newegg.com/p/0RM-003B-005J2 ... lsrc=aw.ds
Huh? There's not even an obvious way to connect that to a Pi. Except getting an adapter (mess) or an enclosure with adapter (bulk). All added up it costs more than the Pi.

I do have an SSD, but unlike some other people, I don't even want to boot from it or put the system on it. The method with exchangeable cards that can be copied is great. The SSD is only for data that need to be read and written fast.

crossbar
Posts: 39
Joined: Mon May 19, 2014 9:45 am

Re: Future of raspberry pi - software related

Sat Jan 25, 2020 3:45 pm

“pagenotfound“ wrote:Anything that can use the VC4/VC6 graphics for something other than games and watching videos
Nice to hear you are working on this.
If you like to get first experience with the vector-processing units in your Pi4-VC6 :

Here is an assembler (embedded in Python) for the „new“ Broadcom Videocore 6 QPUs in your new Pi4:
https://github.com/Idein/py-videocore6
(and links therein)

and here is Broadcoms Videocore 6 QPU Disassembler usage
https://github.com/Terminus-IMRC/vc6qpudisas
(and links therein)

You like c++ ? There is the very old QPULib (basicaly it is a c-like programming language and compiler), currently not for Videocore 6, but for Videocore 4. It dosn't scale well with the number of QPUs. Looks like QPULib needs some love.

mic_s
.

brianstormi
Posts: 8
Joined: Tue Feb 10, 2015 11:33 am

Re: Future of raspberry pi

Sat Jan 25, 2020 10:15 pm

6by9 wrote:
Tue Jan 14, 2020 9:18 am
dickon wrote:
Mon Jan 13, 2020 9:57 pm
For me, software: 4k 10b H.265 playback reliability from console. I'm still having trouble with it. I have no doubt you'll get around to getting things as stable as they should be soon.
Nearly there via V4L2 stateless API and FFmpeg. I'd hope it'll be merged within a month or so, although there may then be performance tweaks to follow. (There are two phases to the decode that can be run in parallel for the current and next frame to improve throughput. Currently they're run sequentially).
Taking in account that V4L2 seems to be the future for Raspberry and Linux. Do you plan to include hw accelerated support for deinterlacing and scaling?. Taking in account costs, support and capabilities, Raspberry could be a great personal transcoding server. Unfortunately current implementation of those modules in ffmpeg are too CPU intensive for arm CPU boards, included the one in Pi 4b, which makes impossible to transcode a single 1080i stream or maximize cpu usage for 1 1080p.

User avatar
Imperf3kt
Posts: 3858
Joined: Tue Jun 20, 2017 12:16 am
Location: Australia

Re: Future of raspberry pi - software related

Sun Jan 26, 2020 2:28 am

pagenotfound wrote:
Sat Jan 25, 2020 3:43 pm
The SSD is only for data that need to be read and written fast.
You mean like the files the operating system needs in order to run?
55:55:44:44:4C
52:4C:52:42:41

Heater
Posts: 16544
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Sun Jan 26, 2020 3:55 am

Imperf3kt wrote:
Sun Jan 26, 2020 2:28 am
pagenotfound wrote:
Sat Jan 25, 2020 3:43 pm
The SSD is only for data that need to be read and written fast.
You mean like the files the operating system needs in order to run?
And what do you mean by that?

I think the key here is that little word 'and' in '...read and written...'.

Whist it is nice to have a faster reads for the media the OS boots from to reduce start up time, the OS can run fine without doing any writes.

Any way I think that if reliability is important it's a good idea to have your OS on a read-only partition so as to avoid any issues of file system corruption during a random power down and the like. That ensures the thing will at least boot up.

Meanwhile data can be kept on a separate media.
Memory in C++ is a leaky abstraction .

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9560
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Future of raspberry pi

Sun Jan 26, 2020 8:57 am

brianstormi wrote:
Sat Jan 25, 2020 10:15 pm
Taking in account that V4L2 seems to be the future for Raspberry and Linux. Do you plan to include hw accelerated support for deinterlacing and scaling?. Taking in account costs, support and capabilities, Raspberry could be a great personal transcoding server. Unfortunately current implementation of those modules in ffmpeg are too CPU intensive for arm CPU boards, included the one in Pi 4b, which makes impossible to transcode a single 1080i stream or maximize cpu usage for 1 1080p.
Scaling is already there - /dev/video12 (by default) is a V4L2 M2M wrapper around the ISP hardware block.

Deinterlacing, and interlace handling as a whole, is a pain in the neck within V4L2, so currently I've ignored it on the decoder as well as not wrapping the MMAL (GPU) component. The existing MMAL / IL approach passes the field information via a metadata blob attached to each buffer, and there's no external signalling exposed.
There is no hardware block that can do deinterlacing anyway. The existing implementations run on either the VPU (generic SIMD processor within VideoCore), or the QPUs (the 3D processor units). The QPUs are updated on the Pi4, and controlled by the ARM rather than the VPU, so it would require a fair amount of juggling to get it to work. It's probably easier to do it as a FFmpeg plugin that issues the relevant jobs to via Mesa rather than via the VPU, but that still needs a fair amount of work to do.
What CPU load does FFmpeg create for deinterlacing 1080i? Is it spread over multiple cores, or is the deinterlace solely on one core/thread? Splitting it over multiple cores might be the quicker win.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

brianstormi
Posts: 8
Joined: Tue Feb 10, 2015 11:33 am

Re: Future of raspberry pi

Sun Jan 26, 2020 3:53 pm

6by9 wrote:
Sun Jan 26, 2020 8:57 am
Scaling is already there - /dev/video12 (by default) is a V4L2 M2M wrapper around the ISP hardware block.
It's there, but unfortunately not implemented in any of the main tools so far that make it accesible for the end-users like could be with h264_omx , h264_mmal or h624_v4l2m2m coders/decorders in FFmpeg. There was a recent try from one the v4l2 maintainers in ffmpeg, Aman Gupta, to implement it as a filter inside FFmpeg, maybe not the most efficient implementation but a lot better than the software decoders available in FFmpeg, unfortunately didn't reach FFmeg mainline:

https://github.com/FFmpeg/FFmpeg/commit ... a2a6723976
https://github.com/FFmpeg/FFmpeg/commit ... 38595a3f5f
https://github.com/FFmpeg/FFmpeg/commit ... 0d0c70b192
6by9 wrote:
Sun Jan 26, 2020 8:57 am
Deinterlacing, and interlace handling as a whole, is a pain in the neck within V4L2, so currently I've ignored it on the decoder as well as not wrapping the MMAL (GPU) component. The existing MMAL / IL approach passes the field information via a metadata blob attached to each buffer, and there's no external signalling exposed.
There is no hardware block that can do deinterlacing anyway. The existing implementations run on either the VPU (generic SIMD processor within VideoCore), or the QPUs (the 3D processor units). The QPUs are updated on the Pi4, and controlled by the ARM rather than the VPU, so it would require a fair amount of juggling to get it to work. It's probably easier to do it as a FFmpeg plugin that issues the relevant jobs to via Mesa rather than via the VPU, but that still needs a fair amount of work to do.
What CPU load does FFmpeg create for deinterlacing 1080i? Is it spread over multiple cores, or is the deinterlace solely on one core/thread? Splitting it over multiple cores might be the quicker win.
I have tried with all "light" deinterlaced filters available in FFmpeg, from yadif, to kerndeint or pp linear without luck. Meanwhile pi4b is able to transcode 1080i (250% CPU for a 10mbps stream) if you don't try deinterlace or scale the video. It's difficult to know if the issue itself is related to these algorithms could be single or multithread, because in the same moment you try to deinterlace it with them, CPU/GPU is not able to cope with the current transcoding workload (running between 17 - 20 fps), pausing and resuming the encoder continuously because it's missing reference video frames due to this and CPU doesn't go up above 200% - 240% without maxing 100% any of the cores.

Again the same previous guy tried to submit to FFmpeg mainline a CPU lighter software deinterlacer, easy to manage for ARM boards like the ones available in VLC, with the same outcome than his hw v4l2 scaler:
https://www.mail-archive.com/ffmpeg-dev ... 89443.html

Following the forums the union of these two pieces made possible to do live transcoding (1080i) in pi4b, unfortunately never landed FFmpeg mainline.

In case of 1080P, transcoding with output scaling is possible in Pi4B thanks to its more powerful CPU , but not in Pi 2/3 for this same performance penalties associated to sw implementation availble in FFmpeg/VLC... .

This seems to be a big lack since raspberry p2/p3 days, Raspberry has the needed capabilities for doing it but never has been accesible to end-users because never has reached any of the principal tools like FFmpeg for whatever reason.

ejolson
Posts: 5799
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi

Sun Jan 26, 2020 4:40 pm

brianstormi wrote:
Sun Jan 26, 2020 3:53 pm
6by9 wrote:
Sun Jan 26, 2020 8:57 am
Scaling is already there - /dev/video12 (by default) is a V4L2 M2M wrapper around the ISP hardware block.
It's there, but unfortunately not implemented in any of the main tools so far that make it accesible for the end-users like could be with h264_omx , h264_mmal or h624_v4l2m2m coders/decorders in FFmpeg. There was a recent try from one the v4l2 maintainers in ffmpeg, Aman Gupta, to implement it as a filter inside FFmpeg, maybe not the most efficient implementation but a lot better than the software decoders available in FFmpeg, unfortunately didn't reach FFmeg mainline:

https://github.com/FFmpeg/FFmpeg/commit ... a2a6723976
https://github.com/FFmpeg/FFmpeg/commit ... 38595a3f5f
https://github.com/FFmpeg/FFmpeg/commit ... 0d0c70b192
6by9 wrote:
Sun Jan 26, 2020 8:57 am
Deinterlacing, and interlace handling as a whole, is a pain in the neck within V4L2, so currently I've ignored it on the decoder as well as not wrapping the MMAL (GPU) component. The existing MMAL / IL approach passes the field information via a metadata blob attached to each buffer, and there's no external signalling exposed.
There is no hardware block that can do deinterlacing anyway. The existing implementations run on either the VPU (generic SIMD processor within VideoCore), or the QPUs (the 3D processor units). The QPUs are updated on the Pi4, and controlled by the ARM rather than the VPU, so it would require a fair amount of juggling to get it to work. It's probably easier to do it as a FFmpeg plugin that issues the relevant jobs to via Mesa rather than via the VPU, but that still needs a fair amount of work to do.
What CPU load does FFmpeg create for deinterlacing 1080i? Is it spread over multiple cores, or is the deinterlace solely on one core/thread? Splitting it over multiple cores might be the quicker win.
I have tried with all "light" deinterlaced filters available in FFmpeg, from yadif, to kerndeint or pp linear without luck. Meanwhile pi4b is able to transcode 1080i (250% CPU for a 10mbps stream) if you don't try deinterlace or scale the video. It's difficult to know if the issue itself is related to these algorithms could be single or multithread, because in the same moment you try to deinterlace it with them, CPU/GPU is not able to cope with the current transcoding workload (running between 17 - 20 fps), pausing and resuming the encoder continuously because it's missing reference video frames due to this and CPU doesn't go up above 200% - 240% without maxing 100% any of the cores.

Again the same previous guy tried to submit to FFmpeg mainline a CPU lighter software deinterlacer, easy to manage for ARM boards like the ones available in VLC, with the same outcome than his hw v4l2 scaler:
https://www.mail-archive.com/ffmpeg-dev ... 89443.html

Following the forums the union of these two pieces made possible to do live transcoding (1080i) in pi4b, unfortunately never landed FFmpeg mainline.

In case of 1080P, transcoding with output scaling is possible in Pi4B thanks to its more powerful CPU , but not in Pi 2/3 for this same performance penalties associated to sw implementation availble in FFmpeg/VLC... .

This seems to be a big lack since raspberry p2/p3 days, Raspberry has the needed capabilities for doing it but never has been accesible to end-users because never has reached any of the principal tools like FFmpeg for whatever reason.
Out of curiosity how are you getting a live 1080i video stream into the Pi? Is this through a USB adapter? Which one?

brianstormi
Posts: 8
Joined: Tue Feb 10, 2015 11:33 am

Re: Future of raspberry pi - software related

Sun Jan 26, 2020 4:46 pm

In this case through IP, mpeg-ts stream from tvheadend connected to a sat-ip decoder (H264 1080i), but the same results when trying with USB ones like PS3 Play TV TDT, SkyStar 2 HD DVB-S2... or using other DVRs servers like VDR in linux.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9560
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Future of raspberry pi

Sun Jan 26, 2020 5:12 pm

brianstormi wrote:
Sun Jan 26, 2020 3:53 pm
6by9 wrote:
Sun Jan 26, 2020 8:57 am
Scaling is already there - /dev/video12 (by default) is a V4L2 M2M wrapper around the ISP hardware block.
It's there, but unfortunately not implemented in any of the main tools so far that make it accesible for the end-users like could be with h264_omx , h264_mmal or h624_v4l2m2m coders/decorders in FFmpeg. There was a recent try from one the v4l2 maintainers in ffmpeg, Aman Gupta, to implement it as a filter inside FFmpeg, maybe not the most efficient implementation but a lot better than the software decoders available in FFmpeg, unfortunately didn't reach FFmeg mainline:
..
https://github.com/FFmpeg/FFmpeg/commit ... a2a6723976
https://github.com/FFmpeg/FFmpeg/commit ... 38595a3f5f
https://github.com/FFmpeg/FFmpeg/commit ... 0d0c70b192
I'm aware of Aman's efforts as he actually actioned a couple of OMX fixes from yonks back that all the other FFmpeg devs were ignoring, and he asked some questions when he was implementing things. Slightly annoying the other devs are pushing back and blocking merging.

Gstreamer uses it with the v4l2convert component. You may need to bump up the version or add the module parameter "bcm2835_codec.disable_bayer=1" - for some reason GST excluded Bayer formats as being raw video, so didn't create the component should the scaler support them
brianstormi wrote:I have tried with all "light" deinterlaced filters available in FFmpeg, from yadif, to kerndeint or pp linear without luck. Meanwhile pi4b is able to transcode 1080i (250% CPU for a 10mbps stream) if you don't try deinterlace or scale the video. It's difficult to know if the issue itself is related to these algorithms could be single or multithread, because in the same moment you try to deinterlace it with them, CPU/GPU is not able to cope with the current transcoding workload (running between 17 - 20 fps), pausing and resuming the encoder continuously because it's missing reference video frames due to this and CPU doesn't go up above 200% - 240% without maxing 100% any of the cores.

Again the same previous guy tried to submit to FFmpeg mainline a CPU lighter software deinterlacer, easy to manage for ARM boards like the ones available in VLC, with the same outcome than his hw v4l2 scaler:
https://www.mail-archive.com/ffmpeg-dev ... 89443.html

Following the forums the union of these two pieces made possible to do live transcoding (1080i) in pi4b, unfortunately never landed FFmpeg mainline.

In case of 1080P, transcoding with output scaling is possible in Pi4B thanks to its more powerful CPU , but not in Pi 2/3 for this same performance penalties associated to sw implementation availble in FFmpeg/VLC... .

This seems to be a big lack since raspberry p2/p3 days, Raspberry has the needed capabilities for doing it but never has been accesible to end-users because never has reached any of the principal tools like FFmpeg for whatever reason.
It should be possible to do hardware video decode and encode, with the ARM doing the deinterlace in the middle, and hardware resize should you wish for it.

And don't ignore GStreamer. At the moment you'll need to software decode to get the field information, and software deinterlace, but hardware resize and encode should work.
I'll see if it's possible to signal the field arrangement from the hardware in a way that can make V4L2 happy, as then GStreamer should be able to do all except the deinterlace in hardware.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ejolson
Posts: 5799
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Sun Jan 26, 2020 5:32 pm

brianstormi wrote:
Sun Jan 26, 2020 4:46 pm
In this case through IP, mpeg-ts stream from tvheadend connected to a sat-ip decoder, but the same results when trying with USB ones like PS3 Play TV TDT or SkyStar 2 HD DVB-S2.
To reduce interline twitter, the vertical resolution of interlaced video is typically much less than 1080p. For example, one way to create 1080i from a 1080p source is to average the 2n-1 and 2n lines of the odd frames to create the top field and then the 2n and 2n+1 lines of the even frames to create the bottom field--the other way around if you want to create bottom-field-first 1080i video.

At any rate, whether the averaging is done as indicated above or using a low-pass optical filter in the camera itself, the result is that there is not much to lose by deinterlacing to 720p60. A typical way to do this is to extract each 540 line field and then interpolate it to 720 lines. Note the way the top fields should be interpolated is slightly different than the bottom fields because the scan lines that are involved correspond to slightly different positions on the screen.

The point is that directly converting to 720p60 and never touching 1080p60 anywhere in the rendering pipeline is likely to result in enough computational savings that the video can be transcoded in real time. Moreover, since 1080i video doesn't have the same vertical resolution as 1080p in the first place, not much is lost.

On the other hand, even though the vertical resolution of 720p60 is quite similar to that of 1080i video, the loss of horizontal resolution can sometimes be perceived, especially if the original source was in a high-quality format. Still, for video captured from a broadcast, I would either record the exact transport-stream and avoid any live transcoding, or convert to 720p60 instead of 1080p.
Last edited by ejolson on Sun Jan 26, 2020 7:53 pm, edited 1 time in total.

weberjn
Posts: 12
Joined: Sat Jan 13, 2018 9:55 pm
Location: Hohenlohe, Germany
Contact: Website

Re: Future of raspberry pi - software related

Sun Jan 26, 2020 7:17 pm

pagenotfound wrote:
Sat Jan 25, 2020 4:21 am
1. Anything that reduces card wear.
This is called SSD. Costs 23 Euros for 120G. (+ 7 for an adapter).

brianstormi
Posts: 8
Joined: Tue Feb 10, 2015 11:33 am

Re: Future of raspberry pi

Sun Jan 26, 2020 8:45 pm

6by9 wrote:
Sun Jan 26, 2020 5:12 pm
And don't ignore GStreamer. At the moment you'll need to software decode to get the field information, and software deinterlace, but hardware resize and encode should work.
I'll see if it's possible to signal the field arrangement from the hardware in a way that can make V4L2 happy, as then GStreamer should be able to do all except the deinterlace in hardware.
Thank you for your support. I'll revisit GStreamer, in the past I used some GST pipelines from rtranscode4 app created by one user of this forum, gkreidl.
I just see in this forum (viewtopic.phpf=38&t=123876&sid=548240f4 ... 5#p1537107) he is facing similar and new issues trying to adopt V4L2 framework for RPi 4. I'll continue digging.

brianstormi
Posts: 8
Joined: Tue Feb 10, 2015 11:33 am

Re: Future of raspberry pi

Sun Jan 26, 2020 8:59 pm

6by9 wrote:
Sun Jan 26, 2020 5:12 pm
I'm aware of Aman's efforts as he actually actioned a couple of OMX fixes from yonks back that all the other FFmpeg devs were ignoring, and he asked some questions when he was implementing things. Slightly annoying the other devs are pushing back and blocking merging.

Unlike his implementation for faster deinterlacer, I don't think his implementation for doing V4L2 hw scaler was never submitted for merging it, at least I can't find any reference in FFmpeg-dev mailing list.

User avatar
Gavinmc42
Posts: 4654
Joined: Wed Aug 28, 2013 3:31 am

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 1:08 am

Could de-interlacing/scaling be done on the Compute Shaders now that OpenGLES3.1 is out for the VC6?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

pagenotfound
Posts: 124
Joined: Mon Mar 14, 2016 12:44 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 5:32 am

Imperf3kt wrote:
Sun Jan 26, 2020 2:28 am
pagenotfound wrote:
Sat Jan 25, 2020 3:43 pm
The SSD is only for data that need to be read and written fast.
You mean like the files the operating system needs in order to run?
What makes you think that? As explained, with 4GB (and ZRAM, if necessary), I effectively don't need to use swap and all caches are in RAM. Most other OS stuff is reading executables and configs during system startup. Happens in less than a minute while I fetch something from the kitchen. Logs don't need to be written fast.

The data I'm talking about are in, you know, databases. Compiling also tends to read and write a lot, much more than the OS. For me, the data I/O needs to be fast, the small stuff from the OS just needs to be reliable. And as even the small stuff sums up over months and years, it shouldn't damage the card.

pagenotfound
Posts: 124
Joined: Mon Mar 14, 2016 12:44 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 5:36 am

weberjn wrote:
Sun Jan 26, 2020 7:17 pm
pagenotfound wrote:
Sat Jan 25, 2020 4:21 am
1. Anything that reduces card wear.
This is called SSD. Costs 23 Euros for 120G. (+ 7 for an adapter).
As I said, I DO have SSDs but I also have my reasons to prefer the OS to reside on the card.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9560
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 7:34 am

Gavinmc42 wrote:
Mon Jan 27, 2020 1:08 am
Could de-interlacing/scaling be done on the Compute Shaders now that OpenGLES3.1 is out for the VC6?
There is no hardware block that can do deinterlacing anyway. The existing implementations run on either the VPU (generic SIMD processor within VideoCore), or the QPUs (the 3D processor units). The QPUs are updated on the Pi4, and controlled by the ARM rather than the VPU, so it would require a fair amount of juggling to get it to work. It's probably easier to do it as a FFmpeg plugin that issues the relevant jobs to via Mesa rather than via the VPU, but that still needs a fair amount of work to do.
And the isp is far the more suitable block for scaling than the 3d is.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

gkreidl
Posts: 6355
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Future of raspberry pi

Mon Jan 27, 2020 7:42 am

brianstormi wrote:
Sun Jan 26, 2020 8:45 pm
6by9 wrote:
Sun Jan 26, 2020 5:12 pm
And don't ignore GStreamer. At the moment you'll need to software decode to get the field information, and software deinterlace, but hardware resize and encode should work.
I'll see if it's possible to signal the field arrangement from the hardware in a way that can make V4L2 happy, as then GStreamer should be able to do all except the deinterlace in hardware.
Thank you for your support. I'll revisit GStreamer, in the past I used some GST pipelines from rtranscode4 app created by one user of this forum, gkreidl.
I just see in this forum (viewtopic.phpf=38&t=123876&sid=548240f4 ... 5#p1537107) he is facing similar and new issues trying to adopt V4L2 framework for RPi 4. I'll continue digging.
The link doesn't work. I suppose you mean this one: https://www.raspberrypi.org/forums/view ... e#p1537107

It neatly explains, why transcoding real time TV stream using gstreamer modules currently doesn't work on a RPi 4. For the time being I have stopped developping transcoding for Buster/RPi 4.
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

User avatar
Imperf3kt
Posts: 3858
Joined: Tue Jun 20, 2017 12:16 am
Location: Australia

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 8:34 am

pagenotfound wrote:
Mon Jan 27, 2020 5:32 am
Imperf3kt wrote:
Sun Jan 26, 2020 2:28 am
pagenotfound wrote:
Sat Jan 25, 2020 3:43 pm
The SSD is only for data that need to be read and written fast.
You mean like the files the operating system needs in order to run?
What makes you think that?
real world data makes me think that.
https://en.wikipedia.org/wiki/Von_Neuma ... bottleneck
55:55:44:44:4C
52:4C:52:42:41

pagenotfound
Posts: 124
Joined: Mon Mar 14, 2016 12:44 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 3:49 pm

Imperf3kt wrote:
Mon Jan 27, 2020 8:34 am
pagenotfound wrote:
Mon Jan 27, 2020 5:32 am
Imperf3kt wrote:
Sun Jan 26, 2020 2:28 am

You mean like the files the operating system needs in order to run?
What makes you think that?
real world data makes me think that.
https://en.wikipedia.org/wiki/Von_Neuma ... bottleneck
Imperf3kt wrote:
Mon Jan 27, 2020 8:34 am
pagenotfound wrote:
Mon Jan 27, 2020 5:32 am
Imperf3kt wrote:
Sun Jan 26, 2020 2:28 am

You mean like the files the operating system needs in order to run?
What makes you think that?
real world data makes me think that.
https://en.wikipedia.org/wiki/Von_Neuma ... bottleneck
Sigh. What makes you think that replacing RAM with an SSD will alleviate the problem? The memory bus may be too slow for the CPU but it's still faster than an SSD. CPU independent transfers don't save the day either.

Don't worry, I'm not stupid. I learned about the Von Neumann bottleneck before some people around here were born.. In this case I even have "real world data" to back up my position. I have tried a lot of things just to be sure (and because the SSDs were the shiny new toys). And no surprise, SSDs aren't the best solution for everything.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27061
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 4:04 pm

Rather than sniping at each other, please just answer the question.

Just a note - I hate the word Sigh when used at the start of a sentence. Imagine someone standing in front of you did that in your face - would you find that rather rude? If you wouldn't dare do it to someones face (and I recommend not doing it to me to my face, or virtually, because that won't end well), don't do it here.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Daniel Gessel
Posts: 121
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 7:15 pm

What was the question?

Oh, right, the value of SW features that reduce SD card wear: consider the Pi Zero. Often used in applications where most other storage devices are impractical (even a thumb drive would stick out like a sore... well, thumb). Little robots and music players and the like.

So I’d say conserving SD cards is a good thing - it sounds like the overlay file system will suit for projects I have in mind, but I’m sure there are use cases where a pocket of persistence would be quite useful.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27061
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 7:41 pm

Daniel Gessel wrote:
Mon Jan 27, 2020 7:15 pm
What was the question?

Oh, right, the value of SW features that reduce SD card wear: consider the Pi Zero. Often used in applications where most other storage devices are impractical (even a thumb drive would stick out like a sore... well, thumb). Little robots and music players and the like.

So I’d say conserving SD cards is a good thing - it sounds like the overlay file system will suit for projects I have in mind, but I’m sure there are use cases where a pocket of persistence would be quite useful.
Not sure what more could be do be here, except maybe scripts or similar to set low write systems up.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Heater
Posts: 16544
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Mon Jan 27, 2020 7:46 pm

Daniel Gessel,
I’m sure there are use cases where a pocket of persistence would be quite useful.
This sounds quite reasonable.

Until you realize that when you write to a block on an SD card you are not writing to any particular block of physical storage.

Rather you are asking the micro-controller on the SD card to save your block of data somewhere, such that you can read it back with the same block number later.

That micro-controller is free to write your data anywhere it likes. Quite possibly mixed up with other blocks that your file system thinks are read-only.

That micro-controller can move blocks of data around it's blocks of physical storage. To minimize wear.

In short, I see no way of creating a "pocket of persistence" separate from everything else on the SD card.

Worse still I have never found a specification of any such media, SD card, SSD, etc that tells you what that micro-controller actually does.

Better not to write to the thing at all.
Memory in C++ is a leaky abstraction .

Return to “General discussion”