ffmpeg is an audio/video converter. The basic use is to convert an input file/stream to a different output file/stream. Sounds simple? Yeah, but it's also far more complicated.
Multimedia libs in linux is not unique. You have probably (even if not noticed it) been in touch with gstreamer, sox and libav. Diversity is a good thing, but for a minimalistic distro like Puppy, it means we have to take the hard decisions what to support and what to leave.
These days, ffmpeg matures into something more than just one of the other libs. Simply because some major projects make it their preferred multimedia lib.
- Ubuntu and Debian used ffmpeg some years ago, but switched to libav when it forked from ffmpeg. Now they have switched back to ffmpeg. Puppy based on ie. Ubuntu Tahr had major issues with Puppy-tools built upon ffmpeg, like FFconvert and pBurn. pMusic was never included into Puppy Tahr. Slackware on the other side kept ffmpeg, so Puppy Slacko never had these issues.
- Firefox has from version 44 switched from gstreamer to ffmpeg for multimedia support. In a standard Puppy, gstreamer is only used by Firefox. So in a future release, including Firefox will require less dependencies. Gstreamer is not lightweight, so the iso-shrink will be noticeable.
As mentioned, Puppy already includes apps using ffmpeg, but it could also give us more interesting ffmpeg-based apps. Here follows some load thoughts of different ways to use ffmpeg for new projects. That means new apps/features that not require any new backends/dependencies. But let's start to see how it already is in use:
- The original target for ffmpeg was to convert input file to another output file. This is what we see in FFconvert.
ffmpeg -i /path/input_file.mp3 [options] /path/output_file.ogg
This is also what is used by pBurn to make your audio files compatible before burning an audio-CD and any video file for your Video-DVD.
- Depending on the ffmpeg-package, it may or may not contain the ffmpeg media player - ffplay. This is a simple but very useful mediaplayer for video and audio files and streams. It could for sure have been the default media player Puppy, but atm it does not has any control-gui, or a signal-system for building an external gui. Interesting to see how this evolves in the future.
ffplay -i /path/input_file.mp3
- Instead of sending the converted output audio/video stream to an output file, it is possible to send it further to another command. Technically that means sending the stream to stdout and pipe it to next command. This way of using ffmpeg is what pMusic is based upon: Take whatever audio-file format and convert it to raw audio before sending it to the simple audioplayer (aplay) shipped with the audio driver system - alsa.
ffmpeg -i /path/input_file.mp3" -f au - | aplay
This is another solution than using ffplay, and it is likely to think that this has to be hard on the resources on your system. It is not. And there are 3 main benefits: 1.) ffplay is not always bound to the ffmpeg pack. 2.) We can control the soundcard more accurate through aplay than ffplay. 3.) Only very recent versions of ffplay allows sound-filtering of the input stream.
- The input or output can also be a server (a livestream). This webcam recorder is an example of such use. But in the following example I send the output to a local server.
ffmpeg -i /path/input_file.mp3 -f rtp rtp://127.0.0.1:1234
This ffmpeg stream can not be heard until you connect to the server. So, you can (dis)connect to your stream without restarting the audio-file. I have set up this structure for the next pMusic release (5.1.0) to support visualization. ffmpeg has filters to convert audio into a generated video like waves or similar, but managing visualization should not interfere with the main audio stream. Solved by sending the output both the the server and to stdout.
ffmpeg -i /path/input_file.mp3 -f rtp rtp://127.0.0.1:1234 -f au - | aplay
Realize than ffmpeg can mix and split inputs and outputs. It's getting complicated, and I stop here...
- ffmpeg supports more inputs than files and streams. It is capable to grab the output of the X-server (What you see on your screen). That means it is simple to build a screen recorder for ie. youtube howtos. I have wondered why no one have found this to be a fun project for their coding. It's all based on one single command like:
ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 output.mp4
including the sound from your mic.
ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+100,200 -f alsa -ac 2 -i hw:0 output.mkv
- The last example is interesting because it also grabs the sound from the soundcard. Combine this with a local audio server as shown above and you can tweak (soundfilters like /eq/pitch/vibrato/..) the sound in realtime without interfering with the input soundcard stream. Are we seeing a pRack...
- And I have not mentioned that ffmpeg supports basic video editing like croping, scaling, fading, effects, etc.
These are only a few examples of the usage of this awesome tool. And personally, I find it pleasing to see that it most likely will be included into future Puppies. Here are much unused potential. So, girls and guys - go coding.
1 Comment - Edit - Delete
Fido has been a poor neglected pup.
For many years people have wondered why we use the root account for just about everything. After several complaints, Barry eventually created the fido account that served as the default non-root 'user' to appease those not comfortable with running as root. Much of this was based on Pizzasgood's work in Puppy 4.2.1. Unfortunately, fido hasn't received much love since then and has deteriorated in to an emaciated wreck.
I have decided to do some work on the fido account (rather than put him down) and the first thing I did was create a 'home' dir for fido in /home/fido so there will be no more conflicts with /root. Of course it didn't work too well. I got to a desktop fine, everything on the hardware side working, browsing, text editing worked but no terminal! urxvt, our default virtual terminal application just would not run, so out came the google foo. Turns out that permissions in /dev/ were scewed up, a lot of them; some ownerships too. Of course there will be a lot of other bugs that I didn't investigate but this one was huge, and probably the worst.
Anyway, I think I now have it sorted and will offer a package for testing in a pfix=ram environment soon.
You can follow development in this thread on the forum.
NB: The last poster there before my post of today was by Nooby, our lovable perpetual 'noob'. RIP Nooby.
No comments - Edit - Delete
So why did I decide to go with a trusty old pplog derivative for this blog?
At first I had considered Jekyll, which runs nicely at Github (see puppylinux.com) but the problem with that is that each post is subject to a "pull request". Nothing wrong with that except I want to trust the posters here and don't want to have to bother with moderating everything. (And there hasn't been great enthusiasm to post a page, edit some content or even proofread over at puppylinux.com). As it is I have to approve every poster and commenter but that is all. Once registered here you have free rein.
I also considered a couple of other options, including FlatPress, a php based platform which stores its database in flat files, similar to pplog and derivatives. However, I thought why not go with this? It's clean, simple yet elegant and with sc0ttman's enhancements quite modern. It was quite a bit of work though to add the multi-user functionality and make sure it was locked down.
Of course there are other big platforms like WordPress, Drupal and friends but they are big and cumbersome, require an sql database and more often than not are an enormous amount of work to customise and maintain. With WordPress, yes there are tons of themes and add ons but this creates more headaches. Whose code do you trust? Why can't I get such and such theme looking right? Drupal is the opposite in that there aren't all that many themes available and they are big work to customise.
I have forked the code for this blog as sjpplog_ng on GitHub. As many will know it is written in the perl scripting language which has a large presence in the open source community. Most web servers have perl already installed. If you are a perl coder, or even a dabbler (like me) then feel free to fork the project and offer your code. The original licence is GPLv3 so we have to stick with that.
It has been a long month of web developing getting the main puppy site transferred over to me and developing a nice site (many thanks of course to jamesb, mavrothal and BarryK) and now this blog which is the place for the latest in Puppy Linux news. Now back to real development!
Is there anything more Puppy than pplog?
No comments - Edit - Delete
pMusic has become a grown up program. Version 0.1 was released back in 2008. It quickly arose both glorifying and criticism. - And that was fair depending on the viewpoint. pMusic 1 was extremely hungry on CPU-power, but it also showed some fresh capabilities of Gtkdialog. The pushing of limits has continued, and it has become a showcase of features I didn't realize was possible using Bash/Gtkdialog.
While pMusic 2 basically put more flesh to the bone, the 3. generation shipped the homemade internal dynamic db. That was very ambitious - maybe too ambitious. So the arguing flamed up again. Cpu-usage was now reduced to the half, but the db had become active and working on its own grabbing music information while playing. New valid arguments had come to the battle...
pMusic 4 focused on all the goodies Thunor gave us with his outstanding work on Gtkdialog. With all kinds of new features the dynamic db became even more active, and it showed its bottlenecks and weaknesses. - The criticism to it was still fair. The last year of pMusic 4, most effort went to stabilize the db-usage. It has become clearer to me why Amarok, Clementine and friend use an external db like Mysql or Mariadb. But when focus is on size and dependencies, that was never an option.
pMusic 4 became stable, but of course for a price. Introducing routines for queuing db pulls and continuously checking db status slowed down the general usage of the audioplayer. If it should fit the mantra of Puppy, it should work snappy also on older pc's. As mentioned, pMusic-code has been written since 2008, and I have learned some bits and pieces since then. There had to be a potential benefit of rewriting the code. The result is seen in pMusic 5, and the benefit is above my expectations. It seems that much of the stability from version 4.7.4 has survived, and it has become noticeable faster. - That means a lot faster. The cpu-usage has decreased, but more important, many functions are much more responsive. An overall snappier user-experience.
No comments - Edit - Delete
01micko has invited me to join the new blog.
Yes, it looks great.
This will be the place to come and get the latest news about what is happening in Puppy-land, and releases.
1 Comment - Edit - Delete
Somebody that has followed Puppy from the days when Barry was still holding the torch may wonder - what happens with the Puppy releases these days? During its heyday, Puppy can get a new release every 2-3 weeks, or at least one can expect a new release in 2-3 months.
Nowadays, releases seem to be few and far between. Is this slowing down caused by lack of resources, lack of developers interest, or simply, lack of developers?
Actually, the answer is "none of the above". When Barry was at helm, Puppy was in its growing phase. A lot of ideas were tried and dropped, new tools were added (and later dropped), etc. It was also in flux. Nowadays, Puppy is more mature and less tinkering is needed, so you don't see releases that often.
Another reason is, there were complaints when releases were made too often. A personal Puppy installation took time and effort to customise, and to start over again after just 3 or 4 weeks was too much for many.
To balance all this, the implicit agreement is that Puppy releases are now made once every 6 months, give or take.
And lastly - there are actually point releases (or bug fix releases). You probably are not aware of them because they are not announced in Barry's blog; or they are not announced as a separate thread in the forum - they are posted in the same thread that announced the original release, but those posts quickly get drowned by other forum traffic.
And that's what this blog is supposed to do - the author of the Puppy can announce his or her own release here, with links back to the forum for discussion. In a way, this blog is to play the same role that Barry's blog played in the past (now that his blog covers a wider range of topics).
1 Comment - Edit - Delete