This page is quite haphazard--I'll start working on a particular issue and then add it to the page, forgetting that I've covered something similar in another section. Then, it stays haphazard till I get the time and inclination to fix it. User Oko on daemonforums has a very nice and concise guide to several common multimedia tasks, and there's an ArchLinux wiki ffmpeg article that covers many typical situations. Thi page is being put up for my own personal use, so that I don't have to look things up each time and covers the tools that I use.
I am NOT any sort of video editing expert. There are many articles, (some of them are linked here) that cover the finer points of video editing. The ffmpeg program has all sorts of options that I don't begin to cover. (Even their man page doesn't cover all of them. For example, there is a -vol option, to raise the volume, that isn't mentioned in the man page.)
I'm not always consistent. In giving ffmpeg examples,, I may use the format -vcodec, -acodec and -scodec for video, audio, and subtitle codecs, but may also use -c:v -c:a and -c:s. The -c is for codec and the letter after the colon is for video, audio, or subtitle. The two variations do the same thing, I believe that the -c:s (-codec:s also works) is newer and I don't remember when I started using it. At some point, I'll make it consistent, but by then, they may have changed the options again.
There's a saying that in Unix there are many ways to do things with a corollary that someone will think your way is stupid. There are times when I give several methods and other times where I leave out one if another works well for me.
A couple of distro (and O/S) specific ffmpeg notes:
Apparently Ubuntu and Debian developers have decided to not use ffmpeg
anymore.
If you install ffmpeg, when you try to run it, there's a message that
you should use avconv. A brief test conversion on Fedora with ffmpeg and
Ubuntu with avconv gave pretty similar results. It understands most, if not
all of the ffmpeg flags. I don't really know the reasons behind the
decision, but ffmpeg has a fork, libav, and Debian went with
that. According to a
Stackoverflow article it sounds like someone got insulted. Aside from
the inconvenience to users, it's almost amusing. The launchpad bug referenced is a complaint about the wording. Apparently at least
some Debian developers feel that if they're not using it, it's dead.
Most of what I say about ffmpeg should work with avconv, but almost all of what I do is done with RH based or FreeBSD systems. To use the -vcodec libx264 that I mention below, in the reducing size section one does need, at least in Ubuntu, to install libavcodec-extra-53. The man pages seem to be identical for the two programs.
Most of this has been done on CentOS-6.x and 7.x, Fedora 22 and up, and FreeBSD-10.x and up. How it's done, package names and the like, will differ between distributions, but hopefully, the reader can adapt it to their own needs. The commands, once the various programs are installed, are usually similar, though from time to time, one will find that a distribution doesn't have a particular library.
With CentOS, there are several non-official repositories. The nux-desktop repo has been everyone's go to repo for RHEL rpms for multimedia. There is a summary of third party repos on the CentOS wiki page, One has to be careful with using these as package A might require library B which breaks package C that also needs library B. The nux repo is considered pretty safe though.
The last time I used the nux version of ffmpeg in CentOS-6.x it was pretty old, 0.10, whereas the latest stable is at 2.7.2, at time of writing. The fffmpeg site has a compilation guide. A more current guide is at gisthub.github.com. As of December, 2015, the first one's command to fetch ffmpeg doesn't work--CentOS-6.x git won't work with the depth option and the address included. Instead of the http address they give, use the URL
git clone --depth 1 git://source.ffmpeg.org/ffmpeg |
given on the gisthub page. Otherwise, either guide should work.
The current CentOS-6.x nux version of mplayer (as of later 2015) is 1.0, which is also somewhat old. It won't, for example, play H265 (HEVC) videos. I've been able to build the svn version from source without any problem.
Depending upon the reader's needs, the nux versions may be quite adequate. They work in most cases. These days, I use CentOS-7.x, so I haven't kept up with what is now happening with 6.x
If one installs mplayer and/or vlc, many of the libraries will be provided as dependencies. One will usually also want dvdauthor, dvd+rw-tools, and ffmpeg. If making DVDs from files, I recommend the tovid program, which makes many things much simpler.
These are various tips I've gotten from various places, such as the howto-pages.org article. I give other links when I have them throughout this article.
These days, with Linux becoming more and more Windows like, many people prefer the GUI tools to do these things. Judging from various forums, however, sometimes the GUI tools don't work, and just like Windows, it can be difficult to figure out why. CLI (Command Line Interface) tools also use fewer resources, can be run in screen or tmux, and quite possibly provide greater flexibility.
Lastly, note that much of this requires several gigs of disk space.
With all that out of the way, these are methods that work for me.
If you find some glaring error, feel free to drop me a note at scottro11 [at] gmail.com, and also feel free to send your own tips, but don't be offended if they don't appear here. Note that many of the commands will require being run as root or with root privilege using sudo.
cat /dev/scd0 > datadisk.iso |
This will take awhile, but at the end of it, you'll have an ISO file than can be burned to a backup DVD. People also use dd if=/dev/scd0 of=datadisk.iso, but I haven't found any difference. However Malome Khomo was kind enough to write and say trying with a larger blocksize can make a difference, e.g., bs=64k, and even bs=128M.
The iso can now be burned to a DVD with the growisofs command, part of the dvd+rw-tools. I like to check it first, to make sure that it did get what I wanted, so I usually do
mount -o loop datadisk.iso /mnt ls /mnt |
Hopefully, this will show me the various files that are on the original DVD. Once that's done, unmount. Note that the command is umount, NOT unmount, something often missed by newcomers.
umount /mnt |
Remove the source DVD and replace it with a blank DVD-R (or DVD+R, if that's what you use.)
growisofs -dvd-compat -Z /dev/scd0=datadisk.iso |
One can, as is covered all over the place, also make a large collection of files into an iso, then burn that. For example, to make and burn an iso of a directory called myfiles, assuming you're in the directory that contains the myfiles directory
growisofs -Z /dev/scd0 -R -J ./myfiles |
I have sometimes run into problems with this when making isos larger than 4 GB on CentOS-5.x. I haven't had the problem with video files, only with directories containing other types of data. I don't know how many people reading this are still running CentOS-5.x, but I will leave this part in for them.
CentOS, as its users know, is binary compatible with RedHat, which, aimed at the enterprise, will use older, proven stable, versions of packages. The growisofs program relies upon mkisofs. The syntax for mkisofs, (to just create an iso of the myfiles directory) is
mkisofs -J -r -o myfiles.iso ./myfiles |
The ./ refers to the current directory and is probably not necessary, it's simply a habit. The -o is for the output.
If you run the command
mkisofs --version |
on Ubuntu, Fedora, and many other Debian or RH based distributions, you'll see a message like
mkisofs 2.01 is not what you see here. This line is only a fake for too clever GUIs and other frontend applications. In fact, this program is: genisoimage 1.1.10 (Linux) |
In practice, when I did run into problems, I just put the files on either another machine or a VirtualMachine, running something with more current versions of makeisofs.
These days, I use CentOS-7.x, so it is no longer an issue. From what I understand, (untested by me), the more current versions of mkisofs itself also have no issues. The chances are that CentOS 5.x uses an older version and that is why I had the issue.
If the file is larger than a DVD's 4.7 GB, one can use a double layer (DL) DVD in the same manner. I've noticed that if it's a DVD+R DL DVD there is a message, when growisofs starts to burn, about splitting layers. I don't see that with a DVD-R DL DVD, however the message seems harmless, and files burn correctly.
There are two common tools for this, dvdbackup and vobcopy. I think vobcopy is supposed to be faster, but I've never done any benchmarks.
With dvdbackup, insert a DVD into the DVD drive and run the command
dvdbackup -M -i /dev/scd0 -o backupdir |
That's assuming you've created a backup directory called backupdir. -M is mirror, -i is input and -o is output. Inside that directory, you'll find a directory containing the DVD files. There will be one parent directory with the VIDEO_TS and possibly AUDIO_TS inside. For our example, we'll assume that dvdbackup called it MYVIDEO
Both vobcopy and dvdbackup may require libdvdcss. Depending upon your country and distribution, this may be be easy or hard to get. As it keeps changing, I'm just going to say that if necessary, and legal--and once again, one assumes you're doing this to make legal copies of what you own--either google for your distribution and libdvdcss or ask on the distro's forums.
I haven't found a vobcopy rpm for CentOS-7.x, but it built quite easily from source, downloadable from the vobcopy downloads site. As you'll see, the latest is from 2008 but it still should build easily. The configure script looks for libdvdread, so make sure you have libdvdread-devel. They also include a specfile which I didn't try.
If using vobcopy, one first mounts the DVD.
mount /dev/scd0 /mnt |
Now run vobcopy. It seems necessary to put the -m (for mirror) before the -i (for input directory), but your mileage may vary.
vobcopy -m -i /mnt |
This will create a DVD directory in your current directory. Again, we'll assume it's called MYVIDEO. (It isn't necessary to specify an output directory for vobcopy, though you can give it a title if you choose--if you don't, vobcopy calls it by the existing title, in this case, MYVIDEO.) When done, unmount the mounted dvd.
|
Get to the directory containing MYVIDEO (your current directory if you used vobcopy, or backupdir if you used dvdbackup.)
At this point, you can use mkisofs to first create an ISO, then burn it with growisofs, or do it in one step. The two step method, again, assuming you are in the directory containing the MYVIDEO directory.
mkisofs -dvd-video -o video.iso ./MYVIDEO |
If you want to give it a title, you can do that here with
mkisofs -dvd-video -o video.iso -V "MY TITLE" ./MYVIDEO |
This will produce an iso called video.iso. (Obviously, you can call it whatever you want, such as myvideo.iso). You can now check the file if you wish, using mplayer, vlc or your media player of choice. For example, with mplayer
mplayer video.iso |
Now, put a blank DVD in your dvd burner and burn it with
growisofs -Z /dev/scd0=video.iso |
To do it in one step, burning directly to disk without using mkisofs to make an iso first
growisofs -Z /dev/scd0 -dvd-video ./MYVIDEO |
Again you can use the -V "MY TITLE" option if desired.
If you try to play the disk immediately after burning, you might find that mplayer and vlc are unable to play it. Before you say bad words and throw out what seems to be a coaster, eject the disk and replace it. A friend of mine's version of growisofs will do this automatically, (unless one uses the option use-the-force-luke=notray), but mine doesn't. It may depend upon your system, both software and hardware, but regardless, eject the disk once before trying to play it. Once ejected, it's fine. That is, you can eject it and put it directly into a tabletop player and it will play. The tovid suite's "tovid dvd -burn" may also automatically briefly open the tray after burning, depending upon tovid version. (They seem to have dropped this option in the latest subversion).
This works in the same way with DL DVDs for larger files. If one just wants to make a backup copy of a purchased movie, for example, you can use vobcopy or dvdbackup to copy the DVD, put in a DL DVD and run growisofs as usual.
In some cases, one might just want the file. I've seen relatively complex solutions for, as an example, taking a video with several tracks and playing it on a Macbook Air. One can just copy the directory that was made with dvdbackup or vobcopy, transfer it over network or with USB to a Macbook Air, then play it with VLC. I don't know if Apple's own dvdplayer will play it--it shows up, by default, as a directory in the OS X finder, but dragging the directory into VLC will play it as a normal video.
I discuss creating media files from ISO files in detail below but HandBrake and ffmpeg, can create a media file from an iso file.
HandBrakeCLI -i my.iso -o my.mp4 -Z "HighProfile" |
The -Z "HighProfile" is optional, it's one of several HandBrake presets which is also discussed below.
With ffmpeg it's almost the same.
ffmpeg -i myfile.iso myfile.mp4 |
I also used this article from idolinux.blogspot.com for the first step.
If moving from one country to another, or receiving a present from another country, it may be that your tabletop DVD player can't play PAL or NTSC dvds. As I live in the US, and have only run into being unable to play PAL, this section is geared towards converting a PAL DVD to NTSC format.
Step one is to dump the DVD to a big vob file. The idolinux article suggests using mplayer with
mplayer dvd://1 -v -dumpstream -dumpfile dump.vob |
This works, but I found that the following vobcopy command would also work. First mount the DVD, then use vobcopy as follows, with the -i and -m flags where I have them. (Otherwise, you get the usual video directory, that we used above).
mount /dev/scd0 /mnt vobcopy -i -m /mnt |
Note the order of the -i and -m flags. In this case, we want one big vob file, so the command is done differently than it was above.
This should create one large file called MYVIDEO.vob (with MYVIDEO being whatever title vobcopy was able to get from the disk.)
Next, it's always good to use mplayer or other media player, to make sure it's what you want.
mplayer MYVIDEO.vob |
Assuming it looks good, use the incredibly versatile ffmpeg.
ffmpeg -i MYVIDEO.vob -target ntsc-dvd -acodec copy mynewvid.mpg |
Note that skrud.net's article adds in framerate and aspect. His version is
ffmpeg -i /path/to/vobfile -target ntsc-dvd -r '30000/1001' -aspect 16:9 -acodec copy outputfile.mpg |
I didn't find that to be necessary, it seemed as if ffmpeg figured it out. The -acodec copy means to copy the audio from the source.
Now we have an mpg file. At this point, I use tovid, which segues nicely into the next section. (But see the section on mkv files, where I did find it necessary to include the aspect ratio.)
Many distributions have a package for it. CentOS doesn't, but it's fairly easy to install. The link above goes to the wiki's front page, which has a link for the necessary dependencies (some of which are available as CentOS rpms), as well as the program itself with installation instructions.
Installation will be left as an exercise for the reader. It's a popular program, so help should be available on your distribution's forums. Ubuntu has a package for it. If using a distribution such as CentOS or Fedora, you may be able to use Ubuntu's alien to make a working rpm.
I'm usually using the subversion. There's a note on the front page that it needs a new maintainer, but the subversion has continued to work well for me. Instructions are given on the wiki pages.
I'm not going to go too deeply into using tovid here. There are some good basic wiki articles here. (I'm only giving the general wiki page, as the urls of the articles are constantly changing).
IMPORTANT NOTE: As of tovid 0.32, (I think) the syntax changed. I've tried to update this page and hope I haven't missed anything. Assuming you have an avi file, first encode it into an mpg. (This will also work with an mkv or mp4 file.)
tovid mpg -in myfile.avi -out myfile |
It will examine the file and eventually produce a file called myfile.mpg. At this point, I like to test it with mplayer. On occasion, audio will be badly out of sync. The tovid docs say that if this happens, be sure to use ffmpeg rather than mencoder, either by using -ffmpeg as an option, or fixing it in your ~/.tovid/tovid.ini. (That is where it is in subversion, depending upon your version, the file location may differ.)
Even with ffmpeg, I've had some files where I could simply not sync the video and audio. In those cases, which were possibly due to the type of audio encoding on the file, in at least one instance, I wound up giving up and using the GUI devede program, which encoded it properly. As I use ffmpeg as my default encoder for tovid, and devede, at least in the version I was using, uses mencoder, it's possible that had I used mencoder instead of ffmpeg that the mpg created with tovid would have been properly synced.
At any rate, once you have the mpg file, make an xml file to use. (Unless using subversion, see the note below).
tovid xml myfile.mpg -out myfile |
This creates a file called myfile.xml.
It seems, though I'm not positive of this, that in the latest subversion, tovid no longer uses tovid xml. Instead, after creating the mpg, one goes directly to creating the disk structure. In subversion, which will become tovid-0.35, the command is, after having created the mpg
tovid disc -nomenu -files myfile.mpg -out myfile |
The reason for using the -nomenu option is that the default will be to create a menu. As mentioned above, on CentOS and ScientficLinux 6.x with repoforge's version of ffmpeg, this doesn't work.
After creating the mpg, tovid may give a message to use -no-menu and not mention the -files flag. Either -nomenu or -no-menu should work, but -files is necessary.
One minor oddity--I have no idea if it was because I was using subversion or some other reason. I recently, on CentOS 6.2 upgraded ffmpeg, mplayer, and a few other related media packages. The next time I ran tovid mpg on an avi file, it failed, saying it couldn't recognize the avi file. I then uninstalled tovid (which I'd installed from subversion) and installed the latest subversion. After that, it worked. I was in a hurry at the time, and didn't make any investigation as to what broke what, I just mention this in case the reader ever finds themselves in a similar situation.
I do find that tovid's dvd -burn will often, when it's all done, give me an error, saying something to the effect of input/output error, write failed, then a row of !'s and message that it encountered an error. However, in all cases, as long as the rest of the burning seems to have gone successfully, that is the usual whatever% done, estimate finish and so on, that there is no problem. I eject and replace the dvd, test it with mplayer, and all is good.
If one has a collection of files, the tovid wiki has articles about making them into something with a thumbnail menu. Here's the quick version.
You've already made your mpg files, file1.mpg file2.mpg file3.mpg. The tovid command needs the files and titles--I like to add the menu-title option as well, otherwise, it may have a name at the bottom that I don't like. The title does have to be 16 characters or less--otherwise, it will give you an error, and tell you to try playing with the font settings. The man page says you can use submenus, but I've never gotten that to work. However, I'm fine with short titles, so I haven't tried very hard. Anyway, one could use this example, right from the man page. (They tend to break lines with \ which is easier to read--one can also just put it all on one line--if your browser breaks the command below, it should be on one line (or separate lines with a backslash as shown in the tovid man page.)
tovid disk -files file1,mpg file2.mpg file3.mpg -menu-title "My files" -titles "My Video 1" "My Video 2" "My Video 3" -out myfiles |
Remember it will match the order of files with the title--if you left out one title, it will give an error that you have a different number of files and titles. If you leave -titles out, it will give them a title with the name of the file, minus the .mpg suffix, and give you a message to that effect. If you leave the -menu-title out it will use a default of My Video Collection or something similar.
Now it will start, giving you some information about what it's doing. It uses ImageMagick to display the thumbnail menu. It will then say if you're happy with the preview, type yes to continue. You can close the ImageMagick display by hitting escape (it gives you a message to that effect). If you don't specifically type yes at the prompt, it will exit, giving a message about possible configuration options to try. That is, hitting enter will cause it to close, you must type "yes" (without quotes).
When done, you'll have your file that you can preview with your player of choice, and then burn with tovid dvd -burn as explained above.
While on the subject of menus, if making something with menus, mplayer now supports dvdnav. This means that if I've made something with a menu, and want to check it, and the directory was called myvideo I can check with
mplayer -dvd-device ./myvideo dvdnav:// |
This can then be navigated with the number pad, using 1,3, 4, and 6. with 7, the home key on a standard US keyboard number pad, taking you back to the menu.
Depending upon your distribution, mplayer also has a default input.conf. In CentOS, with the atrpm version, this can be found in /usr/share/doc/mplayer-<version>/. On ArchLinux it seems to get installed in /etc/mplayer.
If you don't have the file in /etc/mplayer or your home/.mplayer directory, then the normal arrow keys won't work with dvd navigation. On a laptop, you might be able to select an item, but not get back to the menu. So, if your normal arrow keys (as opposed to number pad arrow keys) aren't working properly, make sure you have the input.conf file in /etc/mplayer or your home's .mplayer directory.
If you do have the file, then you should be able to navigate with the normal arrow keys, using the escape key to get back to the menu.
If using tovid 0.34 and later, one can can immediately burn the dvd, or first create the structure. To create the structure in a separate step
tovid dvd myfile.xml |
This will create a DVD directory called MYFILE. Then you can burn it with
tovid dvd -burn ./MYFILE |
To do it in one step
tovid dvd -burn myfile.xml |
This will make the structure, then burn it. If you have two dvd burners, then specify the device.
tovid dvd -device /dev/scd0 -burn myfile.xml |
(This isn't always necessary--however, sometimes I've found that for some reason, CentOS will symlink /dev/dvd to /dev/scd1 rather than /dev/scd0.)
If one already has an mpg file, they can just skip the first step of tovid mpg -in infile -out outfile. For example, in the previous section about PAL and NTSC, we created an mpg file called outputfile.mpg, using vobcopy and ffmpeg. Once that file is created, I can finish the job with tovid's xml command.
tovid xml outputfile.mpg -out outputfile |
Once that's done, I can use tovid dvd as described above.
By default, I believe tovid still uses mencoder. This can take a long time as it encodes audio and video separately. Using ffmpeg is much faster, but has to be specified.
tovid mpg -ffmpeg -in myfile.avi -out myfile |
At time of writing however, if using ffmpeg, you can't use subtitles unless they're already hardcoded into the avi file. If you want to include subtitles, don't use the ffmpeg option. Also, as the man page points out, when one does insert subtitles, they are u/ardcoded into the resulting mpg file, meaning you can't turn them off. I have more information on subtitles in general below
I have seen tovid have problems with some High Definition Blu-Ray ripped mp4 files. If using ffmpeg, it takes about 10 seconds and the resulting mpg file is a 0 byte file. If not using the ffmpeg option, it will examine the file, then exit with a message about having a problem encoding the audio to ac3 format.
When that happens, once again, ffmpeg can save the day. When I have run into this situation I've been able to fix it with
ffmpeg -i myfile.mp4 -target ntsc-dvd myfile.mpg |
From there, I was able to use tovid xml on the mpg file and create a reasonably good DVD. As mentioned, in subversion rather than tovid xml, one would just use tovid disc -nomenu -files -myfile.mpg -out myfile
I have more about subtitles in the subtitle section as well. The video track will usually be track 0. The audio track will usually be 1, and if there's a second audio track, that will be 2. (One way to confirm which is which is to use vlc and select the audio track from its menu. Howard covers ways to do it all from command line.)
In this case, we'll say that the first audio track, 1, is in French and the second, 2, in English, and the reader only wants the file with the English track.
ffmpeg -i movie.avi -map 0:0 -map 0:2 -target ntsc-dvd file.mpg |
As usual, there are many more options that can be used. In this case, we're creating an mpg file that can be made into a DVD but will only have streams 0, the video, and 2, the English audio. As far as I understand the -map option, the first 0 refers to the first input file. The number after the colon refers to the stream. An explanation of the map option can be found here on the ffmpeg wiki.
The mencoder equivalent is -aid. For example, for things I find in the US, usually the first audio track is English, and the second another language. If I only want the English track, then I might use something like
mencoder -oac copy -ovc copy -aid 0 myfile.mkv -o myfile.mp4 |
If I wanted the second track, for example Japanese, I would use -aid 1. It counts the first audio track as 0, even though the first track will usually be video. Though I would usually use ffmpeg for this, as mentioned elsewhere, ffmpeg can sometimes have difficulty with subtitles. So, for this, I'll use mencoder. With an mkv file if I extract them, so that I have the subtitle file in the same directory as the mkv file, I can play the file. I cover this below in the subtitle section. For example, assuming that using mkvextract --identify we know that the third track is the subtitle track.
mkvextract --identify myfile.mkv mkvextract tracks myfile.mkv 3:myfile.srt |
If the file works with mkvmerge, then making a new file with one audio track can be very quick. If I have an anime that has English and Japanese audio, and I only want the Japanese, first I check with mkvmerge --identify to get the numbers of the audio tracks. Usually it will be tracks 2 and 3. If I play the file with no options, the first number will usually be the default audio. Therefore, if I play the file and the audio is English, it's usually safe to assume that English is audio 2 and Japanese audio 3. Using ffprobe myfile.mkv should also give the language. Therefore, to get the Japanese audio track
mkvmerge -o japaneselang.mkv -a 3 original.mkv |
The -o is for output the -a is for audio. In this case, I'm telling it to just copy audio track 3, and it will leave out audio track 2. The same can be done with multiple subtitle tracks. For example if mkvmerge --identify tells me that 4 is an English subtitle track and 5 a Spanish one, I can do
mkvmerge -o japaneselang.mkv -a 3 -s 4 original.mkv |
Be careful with this. Sometimes it will show two subtitle tracks as S_VOB. This means that it's the combination of sub and idx file so if you remove either one, you'll have no subtitles. If you tried to run the mkvextract tracks command to get the subtitle file, you will find that mkvextract will write it as an idx, not a srt file.
Therefore, if there were multiple languages, and you really only wanted one set of subtitles, you would have to use -s 3 -s 4 (or whatever numbers the English subtitles were.)
On a somewhat related note, ffmpeg can grab a section of a media file. If you want to only grab 5 minutes of a 20 minute video, the options are -ss in seconds for the start time and -t for the duration, also in seconds. You can also use HH:MM:SS, that is hours, minutes, and seconds. For example, if you have a 20 minute video and you want to only get the second five minutes of it, the syntax would be
ffmpeg -i myvideo.avi -ss 300 -t 300 fiveminutevid.avi |
That means you will grab the video beginning at 5 minutes (300 seconds)
into the video and stop grabbing after 5 minutes (the second 300).
Again, one can use the hours:minutes:seconds format for both the -ss and
-t options.
By the way, a useful way to see which codecs are handled by your version of ffmpeg is
ffmpeg -codecs |
(It gives more than a screen of output, so you might want to pipe it to grep if you're looking for a particular codec.
If using mencoder, the syntax is
mencoder myvideo.avi -ss 300 -endpos 600 fiveminute.avi |
If I want a still shot of something five minutes into the video
ffmpeg -ss 300 -i myvid.mp4 -vframes 1 mypic.jpg |
The vframes 1 part tells it to just grab one frame. Putting the -ss in front of the input file is faster though less precise. I haven't looked too closely into this, but there's an explanation (as well as a slightly different method of pulling a frame) at blog.roberthallam.org (and also gives a slightly different method of extracting one frame, using -t 1 instead vframes 1)
One can also take a small segment of a video and make it into a repeating gif. If I have a video snippet that I want to make into a gif, I can use
ffmpeg -i myfile.mp4 myfile.gif |
ffmpeg -i myfile.mp4 -vf scale=320:-1 -r 10 -f image2pipe -vcodec ppm - | convert -delay 5 -loop 0 - myfile.gif |
That should be on one line. There are a variety of things that can be changed, this superuser.com thread gives some other options with explanations.
ffprobe -hide_banner my_video.mp4 |
which should output, among other things, something like
Stream #0:0: Video: h264 (High), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default) |
So, in that case, we see it is 1280 pixels wide by 720 high--so if we want to remove half the width, we know we need to remove 640 pixels. and could use -vf crop=in_w-640:in_h:0:) (to subtract 640 pixels as done in the examples below) or just use -vf crop=640:720:0:0
Generally, you should crop in multiples of 8, since the way encoding works, usually, if you want to remove around 65 pixels, you would actually want 64 or 72.
If you want to remove pixels from the bottom or the right, it's simple. As shown in the subtitles section, we start the axis at 0, that is the very top and the syntax would be (if we wanted to remove 64 pixels from the bottom)
ffmpeg -i myvideo.mp4 -vf crop=in_w:in_h-64:0:0 croppedvid.mp4 |
(The first 0 means that we also start at the far left.) We want the width to stay the same, therefore the in_w. We want the height to be 64 pixels less, therefore in_h-64. We want the pixels to be taken from the bottom, therefore, we use 0:0, meaning that the video starts at the top and the 64 pixels are coming off the bottom.
(With subtitles, even though I've said use multiples of 8, I've often found 68 to be a good number. The reader can experiment).
Now, if we wanted the pixels taken from the top, we would have set the Y axis lower down.
ffmpeg -i myvideo.mp4 -vf crop=in_w:in_h-64:0:64 croppedvid.mp4 |
This would have removed the pixels from the top. And if we do
ffmpeg -i myvideo.mp4 -vf crop=in_w:in_h-64:0:32 croppedvid.mp4 |
ffmpeg is smart enough to take 32 pixels from the top and 32 from the bottom.
The same premise works for right and left
ffmpeg -i myvideo.mp4 -vf crop=in_w-64:in_h:0:0 croppedvid.mp4 |
will remove 64 pixels from the right of the video. If we want to remove it from the left side, we move its position on the X axis.
ffmpeg -i myvideo.mp4 -vf crop=in_w-64:in_h:64:0 croppedvid.mp4 |
Again, to remove from both left and right, we put the axis position in the middle
ffmpeg -i myvideo.mp4 -vf crop=in_w-64:in_h:32:0 croppedvid.mp4 |
Arch Linux forum user ronnylov gave a very good explanation in posts 5 and 7 in this archlinux forum thread. I also found the explanation on renevolution.com's page to be helpful.
Another way to crop is given at incenp.org. The author gives a simple method to use mplayer to create a rectangle that can be resized, and when the size and position are where you want them, quit mplayer. It will print the numbers you need to STDOUT. I tried it and it worked quite well for me.
Here are the instructions, used with the author's permission. I've changed the wording very slightly, mostly to avoid retyping typos. I do thank incenp.org for their kind permission to use the entire set of instructions.
Create a file in your home directory's .mplayer (note the dot before name) directory--create the directory if necessary. Call the file crop. It reads
RIGHT change_rectangle 2 10 LEFT change_rectangle 2 -10 UP change_rectangle 3 -10 DOWN change_rectangle 3 10 KP6 change_rectangle 0 10 KP4 change_rectangle 0 -10 KP8 change_rectangle 1 10 KP2 change_rectangle 1 -10 |
Run mplayer on the video with the rectangle filter--the conf=crop refers to the file we just made:
mplayer -vf rectangle -input conf=crop input.avi |
A white rectangle frames the video. You can use the numeric 2,4,6, and 8 keys to resize it and the arrow keys to move it to the desired region. When you've got it lined up, stop mplayer You'll see the numbers you want on STDOUT.
rectangle: -vf rectangle=240:160:190:30 |
Now you can run
ffmpeg -i myvideo.mp4 -vf crop=240:160:190:30 |
Step one was to figure out which titles were the actual episodes. I used the lsdvd command, available in most distributions. This showed me that several titles were around 23 minutes long, so I knew those were my episodes.
As I figured it would be much faster to run HandBrakeCLI on a file on disk as opposed to doing it directly from the CD, I would then use vobcopy to first copy a title to disk. I prefer to give it a title rather than let vobcopy decide, as I didn't want to mix them up.
Running lsdvd showed me, for example, that title 02 was 23 minutes and a few seconds long. This indicated that it was episode one of the series. As mentioned in the early part of this article, vobcopy requires a disk be mounted. So, I would mount the disk, then grab my file.
mount /dev/scd0 /mnt vobcopy /mnt -n 2 -t episode01 |
The -n is for the title number. Although lsdvd showed it as 02, using -n 02 gave me an error, so I use 2. The -t is for the title I want to give it. After a minute or two, I then had a file episode01.vob
I then ran HandBrakeCLI to get me an mkv file. (Had I used mp4, I sometimes lose the subs)
HandBrakeCLI -i episode01.vob -s 1 -o episode01.mkv |
The -s 1 was for the subtitle. In most cases this worked, but, as mentioned in the subtitle section below, with some episodes, for whatever reason, the subtitle would not show up. In those cases, as mentioned, I used mencoder to either encode with the subtitle or dump the idx/sub files separately so I could edit the idx file to make them easier to read.
Had I used HandBrake directly on the DVD, then I would have to specify the title there. (It shouldn't be necessary to mount the DVD, though if I did so, I could substitute /mnt for the /dev/scd0).
HandBrakeCLI -i /dev/scd0 -t 2 -s 1 -o 01episode.mkv |
I never did figure out why HandBrake couldn't find the subtitle on these, (I tried a variety of options) but in many cases, the subtitles were in a difficult to read black, so I wound up extracting the subtitle file and editing the color palette. (Explained in the subtitle section) anyway. Then I would strip the original subtitle from the HandBrakeCLI created mkv file and merge the newly edited, easier to read file. This is explained elsewhere on this page, but the procedure would be
mkvmerge -S 01episode.mkv -o 01episodenosub.mkv mkvextract tracks 01episode.mkv 3:01episode.sub |
I should now have two subtitle files 01episode.idx and 01episode.sub. I edit 01episode.idx as explained below to make the subs easier to read, then make a new file.
mkvmerge 01episodenosub.mkv 01episode.idx 01episodenewsub.mkv |
This segues nicely into our next section about subtitles.
I've found it easiest to work with mkv files. The short version is to use ffmpeg to convert your file or files into an mkv. If you're happy with that, then you're done. If converting to mp4, ffmpeg needs a subtitle codec specified. If the subtitle track is a srt or textfile (mkvmerge --identify will show something like S_TEXT/UTF8) then use -scodec mov_text. If it is the type of subtitle that uses a combination of idx and sub (mkvmerge will show something like S_VOBSUB) then use -scodec dvd_subtitle.)
I haven't done too much hardcoding it into an mp4. By hardcoding, I mean it becomes part of the video stream, rather than a separate track. To get that to work, I needed to have ffmpeg compiled with libass support--if compiling from source, include --enable-libass in the configuration line. Then, you can use
ffmpeg -i myvideo.mkv -vf subtitles=myvideo.mkv out.mp4 |
If you get an error of subtitles, no such filter, than you probably don't have libass support.
I've also found, in cases where I got the no such filter, that it would still work with
ffmpeg -i file.mkv -filter_complex "subtitles=myvid.mkv[v]" -map "[v]" -map 0:a myvid.mp4 |
A faster way if you have the srt file as a separate file
ffmpeg -i myvid.mkv -i mysubs.srt -c copy -c:s mov_text out.mp4 |
I have found that this will produce a video that shows subs with mpv on Linux or the BSDs, and even Windows. However, on a Mac, this method won't show the subs. You can get around this by installing VLC on the Mac, then choosing subtitles from its menu, then choosing track 1, but I didn't want the recepient to have to bother with it. The following will hardcode the subtitles into an mp4 file so that someone viewing it on a Mac would see the subs with no further configuration required. This is assuming that you have a separate subtitle file called mysub.srt.
ffmpeg -i myvideo.mp4 -vf subtitles=mysub.srt myvidwithsubs.mp4 |
I've not tried to do this with the dvdsub type of subtitle (where you have an myvideo.idx and myvideo.sub file, but according to the ffmpeg wiki it can be done with
ffmpeg -i input.mkv -filter_complex "[0:v][0:s]overlay[v]" -map "[v]" -map 0:a |
With picture based subs (such as if mkv shows it as PGS) according to the ffmpeg wiki, it can be done with
ffmpeg -i myvideo.mkv -filter_complex "[0:v][0:s]overlay[v]" -map "[v]" -map 0:a:0 |
That should be on one line. Embedding it can be useful if you're planning to do other things with the file afterwards, for example, re-encoding to mp4 for an iPad.
One thing I have noticed is that if working with snippets of a video--for example, trying to get 2 minutes from an anime--if the original video is an mkv and you re-encode the snippet to mp4, the subtitles will be out of sync. The workaround I've found is to re-encode the entire video as an mp4, and then pull the snippet.
There are various tools to convert to mkvs. I use ffmpeg.
ffmpeg -i myfile.avi myfile.mkv |
Sometimes, if one downloads a public domain movie with subtitles, they might get the avi and separate subtitle tracks. You will have myfile.avi as well as myfile.sub and myfile.idx. If you want the subs included into an mkv file, we can use ffmpeg as described above, then mkvmerge. After converting the file to an mkv, you now have myfile.mkv, myfile.idx and myfile.sub
mkvmerge myfile.mkv myfile.idx -o myfile1.mkv |
To find out what files your mkvmerge can work with, you can run mkvmerge -l (a lower case L, as in list). Doing this shows that it can handle idx, ass, and srt subtitle files. In the example, we used the idx/sub combo, but the same would work with srt or others. (You won't include myfile.sub in the command line.)
Typically, the downloaded file has the subtitles already there, and we converted it to make it easier to work with the subtitles.
If you're more comfortable with srt files, there's little tool that will take a sub and idx file and turn them into a nearly perfect srt file, using the command line. It needs tesseract, which I didn't find on CentOS--I wound up using a more current Arch installation. The instructions on the author's site are for Debian and Ubuntu based distributions. If the reader is unfamilar with git, the way to get the program, before doing the configure and build the author mentions, is to run the command
git clone https://github.com/ruediger/VobSub2SRT |
This will create a directory called VobSub2SRT in whatever directory you were in when you ran the command. At that point, you can follow the author's instructions. It should be a simple ./configure && make && sudo make install, but the README seems to be updated from time to time, so it's suggested that the reader check the above link for the author's latest information.
Using the program, by, for example, putting mysub.sub and mysub.idx in one directory, then just running vob2srt mysub will produce a mysub.srt file.
It doesn't always give perfect subtitles--for example, I've seen apostrophes come out as & signs, but usually does a pretty good job, though there are other times where the resulting srt file just wasn't usable.
On one or two occasions, I've wound up with a movie that had black subtitles. I suspect the encoders had younger eyes than I do, and wanted a the subtitles to be less intrusive, but to my aging eyes, they were difficult to read. So, first, I exacted the subtitles with mkvextract as mentioned, mkvextract tracks myfile.mkv 3:myfile.sub. This extracts both the idx and the sub file. Then, I edited the idx file. Around the 12th line or so, there's an entry for palette, and then below it, custom colors. I didn't really know what I was doing, but tried changing all the 000000 entries, which mean black, to ffffff, for white. The idx files use hexadecimal notation for color, as does HTML. Then, I merged the subs back in. With myfile.mkv myfile.sub and the revised myfile.idx, I used mkvmerge -o newfile.mkv myfile.mkv myfile.idx. When I played the movie, the subtitles were white, and much easier to read. I repeat, I wasn't quite sure what I was doing, and it's a good idea to back up your idx file before editing.
One combination that I've used several times (just taken from an idx file where I found the subs easy to read) is
palette: 5f5f5f, e7e7e5, 171717, fdfdfd, 942612, 0732af, f3ff5e, 2a2f6d, fdfdfd, 0732af, f6f6f4, f6f6f4, f5f5f3, f4f4f4, f3f3f1, f2f2f2 custom colors: OFF, tridx: 0000, colors: 000000, 000000, 000000, 000000 |
The palette: line should be on one line and the custom colors on the next line. This usually goes under the line reading forced subs: OFF (or ON as the case may be).
I've also had luck, if the palette: line had a bunch of 000000 (black) entries, just changing each group of 6 0's to F's (white) and then replacing the original with it. (And leaving the custom line alone)
I've also had to, rather than just merge the new subs back in, sometimes had to first strip out the old--I've only run into this two or three times, so haven't experimented that much, but sometimes, I've had to, after extracting the subs and editing the palette and/or custom line or lines, run mkvmerge -S myfile.mkv -o nosubs.mkv, then mkvmerge -o new.mkv nosubs.mkv myfile.idx. As this has been a very rare issue for me, I haven't done too much testing.
In the example below, we're going to use the idx/sub combination, but if the subtitle was in srt format the idea is the same.
First use mkvmerge --identify to figure out which track it is.
mkvmerge --identify myfile.mkv |
You will get back something like
Track ID 1: video (V_MPEG4/ISO/AVC) Track ID 2: audio (A_AAC/MPEG4/LC/SBR) Track ID 3: subtitles (S_VOBSUB) |
Now you know that track 3 is the subtitle track. You can also do this with ffmpeg -i myfile.mkv. In that case you will get back an error that it needs an output file, but you will also get back information, including
|
In this case, if it was in srt format, it would say Subtitle: text (default). One can also use ffprobe instead of ffmpeg -i.
By the way, to save the output of ffprobe as text, you have to redirect it as stderr, not stdout. For example ffprobe myvid.avi > out.txt will produce an empty file. ffprobe myvid.avi >out 2>err.txt will give you an err.txt file with the output of the command. So, if you wanted quickly grep Stream to find out size or codec used ffprobe myvid.avi >out 2>err.txt ;grep Stream err.txt will give you the codecs used.
Generally, the ffmpeg -i stream is one number less than mkvmerge --identify track. Regardless, we now know that to mkvmerge, it's track 3. We can now extract it.
mkvextract tracks myfile.mkv 3:myfile.srt |
The mkvextract program is able to determine the subtitle format. In this case, I've told it to extract to a srt file, but if the subtitle track turns out to be the idx/sub combination, rather than extracting it to myfile.srt, it will extract two files, myfile.idx and myfile.sub. So, I have myfile.mkv, myfile.sub, and myfile.idx in one directory. If I do any sort of conversion, and leave the idx and sub file in the same directory as the file, I can use the subs. In other words, ffmpeg -i myfile.mkv myfile.mp4 will, if I play the resulting mp4 file with mplayer, work, as long as the sub and idx files, (or whatever format, such as srt, the subtitle file or files use), are in the same directory as the mp4. By "work," I mean it will play the file with subtitles. Were I to run the above ffmpeg command, the subtitles will not be encoded into the new mp4 file. However, if they have the same name as the mp4 file, and subtitle file or files and mp4 file are in the same directory, mplayer will be able to use the subtitle file.
In my experience, ffmpeg will only take the first set of subtitles--so if you have a movie with say, English and Japanese, and do ffmpeg -i mymovie.mkv mynewmovie.mkv, you'll only get the first set of subtitles. The way around that is to use the -map option.
ffmpeg -i mymovie.mkv -map 0 mynewmovie.mkv |
If your browser makes that hard to figure out, it's map numeral zero, not upper case letter o.
Sometimes, one wants to remove embedded subtitles. The only way I know to do this is by cropping. The syntax used to be simple with ffmpeg, it had a -cropbottom option, but that's been removed in favor of something that I found confusing enough to get its own section.. As it is, to crop 20 pixels from the bottom, re-encode. In this case, as the audio codec is aac I have to use the -strict -2. This depends upon your version of ffmepg. In many cases if you use the aac codec, you'll get a message that it's experimental and experimental codecs aren't implemented. You will be told to use -strict -2 or perhaps -strict experimental. Either one should work with all versions that give you the message, but if one doesn't, try the other. So if you ever specify aac and get the message that it's experimental decided to use strict, use the -strict -2 option. If for whatever reason, that doesn't work, use -strict experimental.
ffmpeg -i myfile.avi -acodec aac -strict -2 -vf crop=in_w:in_h-20:0:0 |
For more cropping information and examples, see the cropping section. I use 20 pixels as an example here, but generally, somewhere between 64 and 72 pixels is a good number.
ffmpeg -i myfile.avi -acodec aac -strict -2 -vf crop=in_w:in_h-64:0:0 |
I have had occasions where I would pull a VOB file from a DVD that I wanted to back up, and it would play with subtitles. However, if I used ffmpeg, I wouldn't get subtitles in the output mkv file. Usually, even if not an mkv file, running mkvmerge --identify will show that there's a separate subtitle track, but in this case, it just showed a video and audio track. However, I was able to get an avi with subtitles by using
mencoder myfile.vob -ovc x264 -oac pcm -o myfile.avi |
This gave me an avi file with the subtitles. I was then able to run HandBrakeCLI to create an mkv file, although it still wouldn't show me a separate subtitle track. However, the subs were in there, and I was able to turn them on and off.
If you run the above command with vobsubout it will give you a separate idx and sub file (assuming the original subs were in that format--in this particular case, where none of the normal methods were giving me the subtitle format, I had to guess). The syntax would be vobsubout outputfile, so in the case above, to have the subtitle files separate from the video, I would use
mencoder myfile.vob -ovc x264 -oac pcm -vobsubout myfile -o myfile.avi |
At that point, depending upon what I want to do with the file, I can re-encode the avi to an mkv file and use mkvmerge to put the subtitles back in. One example might be if the subtitles were difficult to read, and I wanted to put in the palette and custom color lines mentioned above into the idx file.
One can easily create their own srt files with vi. It's just a textfile. If you look at any srt file, you'll see a pattern of number, time, and the title. For example
1 00:05:10,000 --> 00:05:14 This is my subtitle 2 00:05:20,000 --> 00:05:23,000 My second subtitle |
The syntax is the number, time start time end and then the text. The time is hours, minutes, seconds, and milliseconds. (The one after the comma), and all seem necessary. It also seems necessary to include the empty line between the end of the subtitle and the number above the next one, as I have between the line saying This is my subtitle and the number 2 above the next subtitle.
Sometimes, the aim is the opposite, to get rid of embedded subtitles. Mplayer has a delogo option which makes somewhat of a blur and tries to blend with the surrounding colors. The syntax is
mplayer myvideo.avi -vf delogo=150:250:400:50:-1 |
The numbers refer to the X axis (left to right) Y axis (top to bottom), the width and height of the box and the border. The -1 creates a green border around the blur, which is useful when trying to place the blur. To make it more to the right increase the first number, to make it lower on the screen increase the second number. To make it wider, increase the third number and to increase the height, increase the fourth number. As mentioned, the last number is for the border. When you're happy with the placement, change the -1 to 1 and that should take care of the visible border.
This can also be used with ffmpeg to permanently blur out the subtitles. In that case the syntax is
ffmpeg -i myvideo mp4 -vf delogo=x=150:y=250:w=250:h=50 mynewvideo.avi |
Personally, I find that mplayer makes the subtitles a little too big for my taste. By adding the line
subfont-text-scale="2" |
to my $HOME/.mplayer/config file, it makes them a little smaller, more to my taste. The default size is 3, so if they were too small for you, you can change the 2 to a 4 and see if that works better for you.
With mpv to make subs half the default size, at the commmand line you can use
mpv --sub-scale=.50 |
When using mpv, the scale is 0-100 with 1 being the default. So if 1 is too large, then .75 or .50 (note the period before the number) is probably what you want. You can create a $HOME/.mpv/config file, but generally, mpv will create a $HOME/.config/mpv directory, and you can put the config file in there. Regardless, it should read
|
On occasion, I've found that a subtitle in non-English characters shows up as gibberish, for example, a Japanese subtitle in .srt format. This is usually an encoding and/or font issue. Sometimes it can be fixed with mplayer -utf8 myfile.mkv. Other times, that might just change the gibberish into a solid line or empty squares. Generally, I've found that if I specify a font that can read it, I don't have to worry about the encoding.
To get a font list, one can run fc-list. So, I know that I have several mincho fonts, so I might run fc-list |grep -i mincho, which gives me back, among other things, on CentOS-6.6 IPAMincho,IPA明朝:style=Regular. If the part after the second IPA shows up as gibberish, don't worry, it's just some Japanese characters. So, this time I use
mplayer -font IPAMincho myfile.mkv |
Other systems (such as Fedora and FreeBSD) will return the path to the font, followed by the name. For example, on FreeBSD
/usr/local/share/fonts/TTF/sazanami-mincho.ttf: Sazanami Mincho,さざなみ明朝:style=Mincho-Regular,Regular |
but you're just looking for the name, the part immediately after the path (the part that ended with sazanami-mincho.ttf). If the font name has spaces, such as Sazanami Mincho, then put it in single quotes.
mplayer -font 'Sazanami Mincho' myfile.mkv |
HandBrakeCLI -i /dev/scd0 -o myfile.mp4 |
With ffmpeg
ffmpeg -i my.iso my.mp4 |
One can use presets if desired, e.g HandBrakeCLI -i /dev/scd0 -o myfile.mp4 -Z "iPad". HandBrake, as we briefly discuss elsewhere has many other options that can be used, but the above should create a usable mp4.
This also works if you have an iso file.
HandBrakeCLI -i myfile.iso -o myfile.mp4 |
A simple way to create an avi format would be to dump the DVD into a single vob file, as described earlier, either using mplayer or vobcopy. However, lately, (CentOS-7, FreeBSD-11.2) this no longer seems to work. I'll leave this in, because it may just be my particular setup.
In the example, we'll use vobcopy. Then, run the vob file through ffmpeg. Several options are available. See this thread on linuxquestions.org for some examples. However, it can be done quite simply and still be watchable, although the quality may not be the best.
mount /dev/scd0 /mnt vobcopy -i -m /mnt ffmpeg -i MYVIDEO.vob myvideo.avi |
To refresh the reader's memory, the mplayer command would be
mplayer dvd://1 -v -dumpstream -dumpfile dump.vob |
While such simplicity might make purists gnash their teeth, it works, and is handy when, for example, one has a home made dvd from a camcorder that they wish to share with friends.
There can be problems with subtitles. As subtitles don't always start at the beginning of a movie, ffmpeg can have issues seeing them. For this, we can use the -probesize and -analyze duration options. These two must go before the -i (input file). At times, I've also found it necessary to specify the mapping. First run ffprobe on it, to make sure it sees the subtitles.
ffprobe -probesize 60M -analyzeduration 100M -i my.iso |
Next, in theory running ffmpeg with the probesize and analyze duration should give me the movie with subtitles. However, it sometimes doesn't. So, I may have to use the map option. If the results of ffprobe showed me Stream #0:3 Subtitle: dvd_subtitle, I may have to add -map 0:3 to be sure to get the subtitle. I've also found that by default, ffmpeg wants to use srt type files. Sometimes, I've found such a conversion may fail--if your ffmpeg command fails right when the subtitles come in it's a good sign that it can't convert. In such a case, just use -c:s copy to copy the existing subtitle format. So the command might be
ffmpeg -probesize 60M -analyzeduration 100M -i my.iso -map 0:0 -map 0:1 map0:3 -c:s copy my.mp4 |
The -c:s indicates subtitle codec, and you're telling ffmpeg to copy it from the existing file.
Lately, with some DVDS's at least, as mentioned, this hasn't worked for me. Instead, I was only able to get a TS_VIDEO directory with a bunch of VOB files, using vobcopy. Whether I used -i -m or -m -i, didn't make a difference. I could then cat the VOB files with cat *.VOB >new.vob and work with that file.
Using mpv, however wouldn't work. Googling, indicated that the format of the new.vob file was mpeg (or possibly mpeg2, I've already forgotten), and mpv was having some trouble with the format. Using mplayer worked without problems. Another issue was if the movie had multiple audio and subtitles. In one case, Japanese, the track I wanted, was audio track 2 and subtitles were found on subtitle 1. (This was found using ffprobe on the TS_VIDEO file.) After creating my TS_VIDEO directory I also was able to create a single mkv container from the multiple VOB files with
HandbrakeCLI -i VIDEO_TS --main-feature -a 2 -s 1 out.mkvThe --main-feature option was also necessary.
|
It can also be done with just ffmpeg.
cat VIDEO_TS/*.VOB |ffmeg -i myvideo.mkv |
I've found the easiest to be mkvmerge, from the mkvtoolnix package.
mkvmerge -o my.mkv 1.avi + 2.avi + 3.avi |
This works with all video formats that I've come across.
mkvmerge -o new file.mkv file1.mp4 + file2.mp4 |
If you get an error that the two aren't compatible, it might be size or encoding. If it says stream 0 then it's a video incompatibility, if stream 1, audio.
The easiest way I've found to check is to use ffprobe to get size and encoding of audio and video.
ffprobe -hide_banner myfile.mp4 |
The two files will have to be the same resolution, that is, if you have one mp4 at 540x416 and a second one at 576x304, you will have to resize one of them. This could be done with
ffmpeg -i file2.mp4 -s 540x416 newfile.mp4 |
Then, the mkvmerge command should work properly.
In the same way that the size has to be the same, the audio should all be the same format. I once tried this with three small files. Two of them had stereo audio, the third had mono. In this case, that was the only difference. I was able to fix that by using -ac 2 as a parameter.
ffmpeg -i mymono.mp4 -ac 2 nolongermono.mp4 |
Had I wanted to do the opposite, I could have used -ac 1.
ffmpeg -i mystero.mp4 -ac 1 mymono.mp4 |
See this ffmpeg audio channel page.
I also once ran into an issue because while both were using aac as format, one was using HE-AAC and the other LC. In this case, as LC is still the default as of April 2017, (and still requires the -strict -2 with aac), I used
ffmpeg -i file.mp4 -c:a aac -strict -2 out.mp4 |
The ffmpeg AAC page gives a bit more explanation but the main point is that if one mp4 is HE-AAC and the other LC, they have to match. As of April 2017, LC is still the default.
If files almost match, it may merge but one of the files (usually the second) will show tearing or just grey. I've had this happen where ffprobe showed identical encoding but one showed a rate of 697 and the other 696 kbs. Sometimes the easiest thing to do is just re-encode both files, taking defaults, or specifying aac -strict -2 for audio, and, if the size matches, you should then have two files that match well enough to be put together into one mkv.
To merge mp4s with ffmpeg, there is a concat filter. There is more detailed information on the ffmpeg wiki but in a nutshell, one gives ffmpeg a list of files. So, if are in your directory with myfile1.mp4 and myfile2.mp4, first create a list.txt file. It just reads
file myfile1.mp4 file myfile2.mp4 |
This also assumes that all files have the same codecs. (For merging different types of files see the wiki article linked above.) The command is
ffmpeg -f concat -i list.txt -c copy out.mp4 |
The -f concat means use the concatenation filter, -i is for the list to read from, -c copy means copy all codecs. It can usually be left out. The mkvmerge method, however, is much faster and gives equally good results.
I have used MP4Box, part of gpac, to successfully to merge in audio files. For example, if one has an mp4 and an additional mp3 commentary track
MP4Box -add myvid.mp4 -add mycommentary.mp3 newfile.mp4 |
the commentary track should be in sync. I haven't found a program to play both audio tracks simultaneously, but if one wants to listen to the commentary in sync with the video, the above command will produce a properly synced video file. VLC or other players should allow you to choose which audio track to use when playing it.
To merge a video and audio, say I have two files, my.mp4 and my1.mp4. I want the video from my and audio from my1. First, I strip audio from my with
ffmpeg -i my.mp4 -c copy -an silent.mp4 |
I strip the video from my1.mp4 with
ffmpeg -i my1.mp4 -c copy -vn audio.mp4. |
Now, I merge silent.mp4 and audio.mp4.
ffmpeg -i silent.mp4 -i audio.mp4 -c:v copy -map 0:v -map 1:a newfile.mp4 |
Usually, tovid and ffmpeg can deal with them normally. The my-guides site has a good article on converting to avi with VLC.
Sometimes, I have run into issues trying to simply feed an mkv to ffmpeg. However, so far at least, I've always been able to use the -target ntsc-dvd option that I mention in the tovid section, to get reasonable mpg files.
I've also been able to strip out unneeded subtitles. For that one can either use ffmpeg to re-encode to mp4--as mentioned in the subtitle section, ffmpeg doesn't seem able to encode subtitles to mp4 from an mkv file, or use the excellent mkvtoolnix suite of tools.
For CentOS 6, I used the EPEL-testing repo. For information on CentOS repos, see their wiki article. I had to play around with its dependencies though--enabling epel-testing repo gave me an error about libcurl, but downloading the rpm directly, then doing rpm -ivh worked--it needed some boost-filesystem files, which I found usin yum provides */<missing_dependency>, e.g yum provides */libboost_filesystem-mt.so.5 which was one of the errors.
One of the tools in the suite is mkvmerge. To remove subtitles from the mkv, use the -S option. The syntax is (if the original is called file.mkv and you wish the new file to be called newfile.mkv
mkvmerge -S -o newfile.mkv file.mkv |
Generally, as ffmpeg already can have issues with subtitles, using ffmpeg -in myfile.mkv -target ntsc-dvd myfile.mpg may automatically strip out the subtitles. I'm not sure that that always works though, so it's handy to know the -S option of mkvmerge.
If such a thing happens, and you want to keep the subtitles, one can then extract them with mkvextract. This was covered in more detail in the subtitle section, but to repeat it, use mkvmerge --identify to get the number of the track--typically, track 1 is video, 2, audio and 3 subtitles.
mkvmerge --identify myfile.mkv mkvextract tracks myfile.mkv 3:myfile.srt |
In cases where you have an mkv movie and a srt sub file I find the most reliable way to add the subs to be part of the file is with ffmpeg. I got it from an old reddit thread from around 2019 or so.
ffmpeg -i myfilm.mkv -i mysubs.srt -map 0:v -map 0:a -map 1:s -c copy mynewsubbedmovie.mkv |
|
This should also successfully give you a properly subbed film.
One problem I have run into with that is on some widescreen files. If you run mplayer myfile.mkv and hit ctl+C shortly afterwards, it might show that the aspect ratio is something like 2.21:1 or 2.50:1. What will happen is that it will create the mpg which is fine.
From there, I used the tovid's suite disc commands. However, I received a series of messages like WARN: unknown mpeg2 aspect ratio 4. When I tested the dvd file, it had squashed the wide screen into a square format, complete with distortion of the picture. The way around it seems to be to use an aspect ratio of 16:9 with
ffmpeg -i myfile.mkv -target ntsc-dvd -aspect 16:9 myfile.mpg |
This still seems somewhat square, but it works. I've not yet found a good solution for this problem. Some folks use padding, others use -s as in size rather than -aspect, but I've yet to find the perfect solution for that pesky 2.21:1 (or 2.40 or 2.50) aspect ratio.
A thread with several suggested solutions can be found here, but none were perfect for me.
One handy option for ffmpeg when testing this is the vframes option. If I'm testing an aspect ration, I only need a minute or so of the file. I can run something like
ffmpeg -in myfile.mkv -aspect 16:9 -vframes 2500 myfile.mpg |
This way, rather than waiting for the entire file to be converted, it will only work with the first 2500 frames, taking a minute or so. I can then play the mpg file and see if I am happy with the new aspect ratio.
One should also note that the mpg file will usually be smaller than than the mkv file, so that even if one is working with a 7 GB mkv file, the result might be burnable to a standard 4.7 GB DVD. (Of course, using the tovid suite also took care of it, tovid puts all those options in for you. Although I mention the --split option of mkvmerge below, if the reason for using it is to hope to get an mpg file that will fit a normal size DVD, it may be unnecessary. For example, I've had 6.6 GB mkv file, and after running tovid on it, to turn it into an mpg, the mpg was only 1.6 GB.
As for the aforementioned mkvmerge--as it name implies, it can merge files, but it can do several other things. The general syntax is mkvmerge --[various options, such as split] -o (outfile) filename. Despite the merge in its name, it can also split files based on time or size. For example, if you had a 7 GB mkv file that you wished to split into two smaller mkvs, of about 4 GB and 3 GB, you can run
mkvmerge --split size:40000m -o output.mkv myfile.mkv |
This will create 2 files output-001.mkv and output-002.mkv. The man page goes into more detail. One can also do it by time, as per the example in the man page. To split after an hour's duration
mkvmerge --split duration:00:60:00.000 -o output.mkv myfile.mkv |
The format, according to the man page, must have the form of HH:MM:SS.nnn or be in seconds, e.g. --split 3600s. The man page goes into more detail, also noting that it will split right before the next key frame, so the division might not be exactly what you expected.
The mkvinfo file mentioned above can also be useful for things like removing subtitles, especially if you wanted to use the ffmpeg -map option previously mentioned. Just run mkvinfo myfile.mkv to get various information about the file, including the audio and video and subtitle, if included, track.
I found one other useful mkvmerge trick from an article on automate-everything.com. I wanted to combine a cd1.avi and cd2.avi. However, they had subtitles. In this case, rather than a srt file, each avi had its respective .idx and .sub files--one needs both in order to get the subtitles working. However, with the trick from this article, I was able to make each avi file into an mkv with the subs hardcoded into the file. With cd1.avi, cd1.sub, and cd1.idx all in one directory, I ran
mkvmerge -o cd1.mkv cd1.avi cd1.idx |
I then did the same with cd2 so that I now had cd1.mkv and cd2.mkv. To combine them I used mkvmerge with a + to append rather than add, as the man page puts it.
mkvmerge cd1.mkv + cd2.mkv -o newcd.mkv |
However, when I wanted to burn this to a disk, tovid, even using mencoder instead of ffmpeg, didn't do it properly. In the end, I googled various methods of harcoding the subtitles into the mkv using mencoder. As I had mixed results, and didn't keep track of what I was doing, I advise the reader to just google, using a term like hardcode subs with mencoder. If the included subtitles consist of a sub and an idx file, then I've had success with first making it into an mkv as mentioned, then using mencoder with
mencoder -slang eng -of lavf -lavfopts format=mp4 -oac lavc -ovc lavc -lavcopts aglobal=1:vglobal=1:acodec=libfaac:vcodec=mpeg4:abitrate=128:vbitrate=1200:keyint=250:mbd=1:vqmax=10:lmax=10 -vf harddup file.mkv -o file.mp4 |
This hardcoded English subs into an mp4 file. From there, I was able to make an mpg with tovid.
One can also try with HandBrakeCLI as discussed in the subtitle section.
If the subtitle file is a single .srt textfile, it can be sometimes be done more simply with something like
mencoder mymovie.avi -sub mymovie.srt -o movie_hardsub.avi -oac copy -ovc lavc -lavcopts vbitrate=1200 |
If the quality is bad, then try playing with different ovc formats. Although mencoder's mencoder -ovc help says that lavc produces the best quality video, I've sometimes had better luck using -ovc x264
To test quality, one can first use the mencoder option -endpos (ending position)to make a 50MB file and play it to see its quality. For example
mencoder mymovie.avi -sub mymovie.srt -o movie_hardsub.avi -oac copy -ovc lavc -lavcopts vbitrate=1200 -endpos 50mb |
On occasion, one might find themselves with a collection of mkv files with numerical suffixes, such as file.mkv.001, file.mkv.002, file.mkv.003 and so on. In this case, it's usually been split at the binary level and rather than using mkvmerge to combine them, just use
cat file.mkv* > newfile.mkv |
One other useful mkv oriented program is makemkv. It has both a GUI, which I've hardly used, and a commandline version. Its home page is at makemkv.com. The Linux version links are given on their forums. The link also gives building instructions. It has a list of packges needed for Ubuntu. The CentOS or Fedora user would need expat-devel and openssl-devel if they aren't already installed. If you get errors that other files aren't found during the attempt to build the file, it will usually say which files are missing, in which case, one can use the yum provides option to find what packages are necessary.
Once installed, one can open the GUI with makemkv or use makemkvcon, which is less intuitive. There are some brief instructions here.
Basically if you want all of the titles (say an instructional dvd that has a few sections), and wants them stored in a directory called mymkvs, if the machine only has one DVD drive then use
makemkvcon mkv disc:0 all mymkvs |
The program will then create the various titles as separate mkv files, starting with title00.mkv. I've only needed to use it when I wanted multiple titles from a DVD. If one wants to make it into one file, one can then use mkvmerge as mentioned elsewhere in this article.
mkvmerge -o new.mkv title00.mkv + title01.mkv |
ffmpeg -i myfile.avi -vcodec libx264 -acodec aac -strict -2 myfile.mp4 |
I change the video codec to libx264 and the audio codec to aac.
Recently (late 2015) I've been using libx265 rather than libx264. It takes longer, but seems to give a much smaller size with no loss of quality. As mentioned, the nux-desktop repo for CentOS-6.x's version of mplayer won't work with libx265. Neither will most Debian and Ubuntu versions of mplayer as of November, 2015. However, Debian and Ubuntu have mpv available, a fork of mplayer, that can be installed alongside, that will play videos encoded with libx265. It does seem CPU intensive and causes skipping and lagging on my underpowered old netbook. On LinuxMint-17.3 and lower, neither mplayer nor mpv worked with x265 videos. The rpmfusion version of mplayer usually used with Fedora plays it without any problems.
Keep in mind that there are a great many variables that have an effect when encoding, but in a very rough test, on a CentOS-6.x box with ffmpeg built from source, I took a 176 MB avi file. Encoding with libx264 took about 4 minutes, 15 seconds, and brought it down to a size of 91 MB.
Using libx265 it took around 33 minutes and gave me a 41 MB file.
X265 has an x265-params option. One can put in --lossless=1, although I've found when doing that, it greatly increased the size of the file, removing what is, to me, one of the big advantages of hevc, the smaller size.
As mentioned in this stackexchange post, one can also try
ffmpeg -i myfile.mp4 -c:v libx265 -x265-params crf=23 outfile.mp4 |
which lowers the constant rate factor.
Here are a few others that I've tried.
This one is directly taken from this Ubuntu blog. I'm afraid it didn't work consistently for me, but the reader may find it useful. For me, it often left me with overly pixelated files.
ffmpeg -i input.avi -vcodec msmpeg4v2 smaller.avi |
A suggestion for shrinking mp4 files is to change the acodec to mp2, and in one quick test, that went pretty well.
ffmpeg -i input.mp4 -acodec mp2 smaller.mp4 |
It reduced a 166MB mp4 file to 98MB with little loss (to a non purist) of quality. The user is advised to judge for themselves whether the loss of quality is a problem for them.
Going back to avi files, I found that converting the avi to mp4 with ffmpeg reduced the size from 176MB to 86MB. In some cases a simple ffmpeg -i file.avi file.mp4 gave me an error of
Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height |
Apparently this was an audio compatibilty issue and using ffmpeg -i file.avi -acodec copy file.mp4 fixed the problem. (In other cases, one might need to use aac -strict -2). In this case, once the file was converted to mp4, trying to compress it further with the -acodec mp2 command only made it a few megabytes smaller, so I wouldn't bother trying for further reduction in size.
Going back to using libx264, on a 1.1GB avi file using
ffmpeg -i myfile.mp4 -vcodec libx264 -acodec copy outfile.mp4, |
the size was reduced to about 880MB, with no noticeable loss in quality. The size difference will depend upon the file, obviously.
Using the -s for frame size option and playing with the size may also help, depending upon what you will be using to watch the video. So changing the size to say, 320x240 will shrink a movie, but, always depending upon the original, may result in an unacceptable loss of quality. If you want to try it, I recommend using vframes, mentioned elsewhere, to test it before shrinking the whole movie.
ffmpeg -i myvideo.mp4 -s 320x240 -acodec aac -strict -2 -vframes 3000 test.mp4 |
This only runs through 3000 frames of the movie to give you a sample. The man page, if you search for the frame size section, may give you the acceptable dimensions.
One can also use -vf scale= rather than -s. For example, to make a 720p video into a 420p
ffmpeg -i myvideo.mp4 -vcodec libx264 -acodec aac -strict -2 -vf scale=480:-1 out.mp4 |
The -1 means automatically scale the height in proportion. However, sometimes, one gets an error that the height is not divisible by 2, and it will then give the results, for example, 480x267. There is a formula to work around it which I've never used, as I just found it easier to manually add 1 to the height and put it in--for example, in the example above, if I got the error I would use -vf scale=480:268 (as the message told me it had come to 267).
As mentioned, there can be large quality loss. The ffmpeg H.264 encoding page mentions manually lowering the CRF value and using the slow or even veryslow preset to get better quality. The default CRF is 23. The lower the value, the better the quality, so something like
ffmpeg -i myvideo.mp4 -vcodec libx264 -acodec aac -strict -2 -vf scale=480:-1 -crf 18 -preset veryslow outfile.mp4 |
may give better quality. As already mentioned, it is suggested that the user use -vframes (or -t as in time, or just ctl+c to stop the encoding and view what you have so far), to check the quality.
At times, for whatever reason, ffmpeg would come back with an error but mencoder would work. With mencoder, I can get similar results to ffmpeg with
mencoder myfile.avi -ovc x264 -oac faac -o myfile.mp4 |
I haven't found anything to be completely consistent, but for me, using -vcodec libx264 -acodec aac -strict -2, and leaving the size alone, gives me (generally) reasonably good results. If you lose volume, you can often gain it back with
ffmpeg -i mynewfile.mp4 -vcodec copy -acodec aac -filter:a "volume=2.0" mynewfilelouder.mp4 |
This is being used with the very kind permission of the author.
Assume that your Rapidshare username is john and your password is 1234. Make a directory in your home directory, .cookies. (Note the dot before the name, this keeps it a hidden file). Now run the command
wget --save-cookies ~/.cookies/rapidshare --post-data "login=john&password=1234" --no-check-certificate -0 - https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi > /dev/null |
That's all one line (or one can break the line with \ as is done on the original link.)
Note that that is an upper case letter o, not the numeral zero.
Next, make a shell script. (Again, this is exactly the same script that Axel gives at my-guides.)
#!/bin/bash for url in `cat $1` do wget -c --load-cookies ~/.cookies/rapidshare $url done |
Save it somewhere in your $PATH, for example, $HOME/bin, and call it downloader.sh Make it executable with chmod 755 downloader.sh
Now, if you have a list of urls, such as rapidshare.com/file1.rar rapidshare.com/file2.rar, rather than having to go to each url, make a list of all the urls and save them as a file called urls, which might read
http://rapidshare.com/file1.rar http://rapidshare.com/file2.rar http://rapidshare.com/file3.rar |
(As we all know, the urls are much longer than that, and more of a nuisance to type.) Now, to get your batch of files just type
downloader.sh url
Again, this is taken EXACTLY from the my-guides.net and many thanks to Axel, the author, as it was just what I needed.
If, for example, your friend has made a DVD of their child's dance recital, they may have uploaded it as a series of rars. This will usually have a suffix of something like dance.001.rar, dance.002.rar, and so on. They may also appear as dance.r001, dance.r002. They will usually have either an r00 (or 00.rar), or possibly a number starting at 02. (See below when I explain creating rars.) I'm not sure how Windows rar programs do it, but it's usually fairly easy to figure out. There might be a series such as r001, r002 and one file with a suffix of .rar. In any case, figure out the first file--if you guess wrong, you'll probably get an error message. Assuming it was in the format of r001, r002 and one file with a rar suffix, and that that file is called dance.rar, the syntax is
unrar e dance.rar |
You will see it gradually decompress the files, and when it finishes, you will have an avi, iso, or whatever the original file's format was. If there is no separate rar file, and they're all listed as 001.rar, 002.rar, then run unrar on the lowest number, e.g., unrar e dance.002.rar.
One important point, at least in CentOS' and FreeBSD's versions of rar and unrar is that the command must be run as shown above. If you run rar -e dance.rar, you'll just get a list of available options. (Note that you don't actually need unrar, as rar e will do the same thing as unrar e.
Sometimes, the sender will have an sfx file. This is a self-extracting executable and you can run unrar on that. In that case, the file names will be something like dance.01.sfx, dance.02.rar. One can run unrar e (or rar e) on either the 01.sfx or 02.rar and it will work, it doesn't seem to matter.
Much of this depends upon who you might be sharing files with--if they're your family, they might find it easier to work with rar files. The very few times I've done this were to send Linux iso files to someone who was unable to find a download site, so we used p7zip, so I really don't know--I assume, but it's only an assumption, that the rar format is more popular because it's a more common MS format, though p7zip should work with either unrar or the Windows only 7-zip app.
Regardless, to create a rar archive, the simplest method is to first create a directory, as it will create 50 or more files, depending upon the size of the original file. So, we'll create a directory, copy the dance.avi into it, and make a rar archive. Assuming we are in the directory that contains the dancevideo, which we're calling dance.avi
mkdir dancevideo cd dancevideo cp ../dance.avi . rar a -v15m dance |
You will see it creating the rar files. The a is for add. Again, note that like the e for extract, there is no leading -. For those less experienced with command line, the cp ../dance.avi . has a space and period after the file name. That single period means current directory, so we are copying the dance.avi to the current directory.
The -v15m means each file will be 15 Megabytes. Oddly, in CentOS, if I then did a du -sh on the individual rar files, they showed as 16 Megabytes---to get a du -sh of 15MB, I had to use -v14m. I don't know why. CentOS is the only Linux I've tried it with so I don't know if it's just one more thing that RedHat doesn't do right or if it's a Linux thing. FreeBSD works as expected, if one uses -v15m each rar is 15 Megabytes.
The p7zip program should be available in most distributions. It should also pull in p7zip-plugins. (The names may differ between distributions--I think Ubuntu calls it p7zip-full which brings in both programs). It provides 2 programs 7z and 7za. 7z handles more formats, 7za is a standalone executable. For our purposes, we can use 7z.
Therefore, the actual command is 7z. So, to use it to create an archive
7z a -v15m dance |
This will create files called dance.7z.001, 002, and so on. One would extract them the same way as unrar, 7z e dance.7z.001. As mentioned in the rar section, if someone sends you a rar archive, you can extract it withe 7z e whatever.rar (or r01, or sfx).
7z seems to be a bit faster than rar. I've only benchmarked it very roughly (using the time command to unrar something), so don't take that as a definite fact. Also, once again, in CentOS, using -v15m results in files of 16MB, so once again I use -v14m when making a 7z archive in CentOS.
LiteOn and LG, to name two, make inexpensive, lightscribe capable burners. Lightscribe capable DVDs are usually available, if you look around, for little more than the cost of normal DVDs.
Once the burner is installed, for rpm or deb based distros, the software can be downloaded from Lightscribe's site. First get the system software. You can then get the simple labeler software as well. This creates a directory in /opt called lightscribeApplications. To run the labling software run /opt/lightscribeApplications/SimpleLabeler/SimpleLabeler. It allows you to enter text--you can choose fonts from your system fonts. It creates a very simple label, both top and bottom text if you desire, that is, on each side of the center hole.
If, when running the application, it says something like no lightscribe drive available, try adding the following at the end of your /etc/lightscribe.rc
DriveEnumeration=false; CDROMDevicePath=/dev/scd0; |
Note the semicolons at the end of each line--I missed that and wasted a good deal of time on google. Now try running the application again.
Most of Lightscribe's applications are for Windows and/or OSX. For somewhat fancier labels, you can use LaCie's software. For CentOS-7, I used LaCie's site, but it may be available in your distribution's repositories.
I've been using the 4L software with the lightscribe.com's lightscribe software without problem, as opposed to using LaScrie's lightscribe driver with the 4L software. However, either should work.
After installing the 4L software, you can run it with
4L-gui |
This opens a menu that allows you to import image files by clicking (at time of writing) the uppermost left icon. From there, playing with the icons at bottom, you can fit it to the height and/or width of the disk, or manually scale the image. After that, clicking the upper right icon burns the image to disk.
In Linux at least, one can only make a cover in black and white. I usually convert an image to grayscale, using ImageMagick's convert function.
convert -type grayscale foo.jpg foo_bw.jpg |
If backing up a movie, one can search for a cover at cdcovers.cc or similar site.
One last note. On rare occasions, 4L (or SimpleLabeler) might tell you that it doesn't see a LightScribe writeable disk and that you should clean the disk according to the LightScribe documentation. This may be due to a small smudge on the inner ring, around the hole in the DVD. That inner ring has some data used by LightScribe. So, if you get that message and the label side seems clean, try cleaning the inner ring of the DVD. The one time it happened to me, I just wiped it with a dry cloth, and after that, it was fine.
The only issue is that by default, your computer will use its sound card rather than the HDMI output, so it has to be specified, otherwise, you get no sound. For those using the desktop environments, this can probably be done with the normal GUI controls, but for those of us using smaller window managers, e.g. dwm, you may have to fiddle with command line options and configuration file settings.
With mplayer, I use
mplayer -ao alsa:device=hdmi myfile.mp4 |
If using mpv instead of mplayer it would be
mpv -ao=alsa:device=hdmi myfile.mp4 |
I think that some of the more complete desktop environments, such as Gnome and KDE may handle this automatically, but I've also seen enough mention of it to think that it may be a frequent issue.
FreeBSD is a little more difficult. My machine detects the HDMI card without any problem. Running cat /dev/sndstat shows
Installed devices: pcm0: <VIA VT1802_1 (Analog 2.0+HP/2.0)> (play/rec) pcm1: <Intel Panther Point (HDMI/DP 8ch)> (play) default |
With mpv, one way is to use sysctl to change the default sound device. If I run sysctl -a |grep hw.snd.default I see that I get hw.snd.default_unit=0. If I then run sysctl hw.snd.default_unit=1 (which is the HDMI port), running mpv myfile.mp4 gives me both video and sound.
This is fine with mpv. Playing web content, like Netflix, has been a bit problematic for me. I've only tried this with Fedora, and in the end those who prefer pulseaudio and GUIs can use maketecheasier.com's page. I installed alsa-pulseaudio-libs and pavucontrol and used pavucontrol's GUI setup. I clicked the Configuration option and would choose the Digital Stereo (HDMI) Output. Then sound would play through HDMI. When done, I would just change it back to Analog Stereo Duplex and all was well.
In many cases, I'll just use alsa. Usually, creating a $HOME/.asoundrc reading
pcm.!default = pcm.hdmi |
should work. I've also used this Arch Linux forums thread to create a slightly more detailed $HOME/.asoundrc. In my case, the results of aplay -l (that's a lower case L, as in list) were the same as the original poster on that thread, with my HDMI being card 0, device 3. My $HOME/.asoundrc file reads identically to that poster.
pcm.!default { type hw card 0 device 3 } |
When not using HDMI, just temporarily rename the file. That post, as well as the techmadeeasy page, had samples of scripts to temporarily rename your .asoundrc file. The Arch Linux forums thread goes further, to make it all automatic, but I've never taken it that far.
One can also use ffmpeg. This hasn't worked well for me. Sound was very low and the quality poor. One has to use whatever commands they use to make the input devices loud, e.g. mixer on FreeBSD, and alsamixer or pavucontrol on Linux. For example, on a laptop I have, where I'm using Fedora and alsa, I raise the volume of the internal microphone. The ffmpeg wiki has an article about it. It can done more simply than their suggestions. First, run xrandr without any arguments--in other words, type xrandr at a command prompt. It will give you available resolutions and usually indicate the current one with an asterisk. So, if it gives me something like 1366x768 60.000*+ I know my current resolution is 1366x768. Now, if I'm running something in full screen that I want to capture, I can use
ffmpeg -s 1366x768 -f x11grab -i $DISPLAY -f alsa -i default output.mkv |
The -s is for size. -f x11grab means grab the video. -i $DISPLAY means use the current value of the $DISPLAY variable as input, which will be :0.0. -f alsa means use alsa with -i default meaning use the default device for audio input. (Using -i default also works if you use -f pulse), and output.mkv is the name of the captured file. You may have to play with your input device's volume settings to get something that's neither too soft nor too loud. Note what they say about grabbing it uncompressed and then encoding it on your system.
I haven't paid too much attention to it because, as mentioned (even when using the wiki's advice to improve quality), I haven't been happy with the results.
Sometimes, even if it's an mp4, iTunes or Quicktime will show it as incompatible. Quicktime seems to require yuv420p pixel format, so sometimes you can fix it with
ffmpeg -i my.mp4 -pix_fmt yuv420p out.mp4 |
This pix_fmt yuv420p may also be useful if something won't play on an iPhone.
Every update of Mac OS, IOS, or iTunes makes it more difficult to manage one's files that aren't purchased through the Apple store. But, assuming you have a way to transfer the files to an iPad, read on.
HandBrake is a nice GUI tool that has both iPod and iPad preformats. It also has a command line version, HandBrakeCLI. The 0.9.5 version has an iPad preformat. In that case, one can run
HandBrakeCLI -i myfile.avi -o myfile.mp4 -Z "iPad" |
The -Z is for preset. Sometimes, it's taken much longer than ffmpeg, other times, it's been quicker. I haven't found a pattern, nor can I say one uniformly produces better or worse quality than the other. It depends upon the source. At time of writing, I get it with
svn checkout svn://svn.handbrake.fr/HandBrake/trunk hb-trunk cd hb-trunk ./configure --launch --disable-gtk |
That's going by the online instructions. However, they tend to not work for me, which might simply be my lack of understanding.
I've had more consistent success with using ./configure --disable-gtk (that is, without using launch) This creates a build directory. Then, change into the build directory and run make . This actually only makes the build, so when it was done, run make clean. This creates the binary. In other words one might be best off doing
.configure --disable-gtk cd build make build make clean sudo make install |
(Assuming you've built it as regular user, which you should, and then install it.)
Or, possibly make -j4 build clean. And, sometimes, it's worked perfectly for me to just run ./configure --disable-gtk, then cd into build and run make once, creating the binary. I've really gotten no consistency with build attempts on different distributions--all of these methods have sometimes worked and sometimes caused errors, and I've not figured out the reason.
To summarize, sometimes it has worked by following the instructions and doing ./configure --launch --disable-gtk, sometimes it has worked by doing ./configure --disable-gtk;cd build;make, sometimes I have had to, after cd-ing into build, run make twice, sometimes I have had success doing make build clean, and so on. So, I would start by trying the --launch one, if that doesn't work, doing ./configure, cd-ing into build and running make, then running it again if no binary is created. If I ever figure out something that works for me on all distributions, I'll post it here.
So far, on the few movies where I've needed the subtitles, I've first hardcoded them in with tovid (making sure to use mencoder rather than ffmpeg--see the tovid section), then run HandBrakeCLI on the resulting mpg file, or with mkvmerge. (Which is much quicker.) For mkvmerge, the syntax would be
mkvmerge -o newfile.mkv myfile.mkv myfile.srt |
On a 30 minute 105MB mkv file, it took about 3 seconds. However, this too has been inconsistent. Although the resulting newfile.mkv had the subtitles showing up with mplayer, when I used HandBrakeCLI to make it into an mp4, the resulting mp4 didn't have the subtitles. So, at this point, it seems that when I do need it for an iPad, I'll stick with tovid mpg -in myfile.mkv -subtitles myfile.srt -out myfile. I suspect I'm missing something, and when I figure it out, I'll post it here.
The trouble with using ffmpeg on this is that you'll have to find a guide that matches your system. One can just do a straight ffmpeg -i myfile.avi myfile.mp4, but while it will be watchable, the format may not be that good. Some guides will say use -acodec aac and then you'll use a different system and find that in that case, aac is unknown. Google, and you'll find that you should use libfaac on that distribution. (Or vice versa). In some cases, libfaac won't work, and if you use aac you are told that you must add strict experimental to the command line. It can be a bit frustrating. If you do get that error, the syntax is ffmpeg -i myfile.avi -acodec aac -strict -2 out.mp4. Another possibility, that I've found this one useful for flv files as well, is use -vcodec and -acodec copy, which doesn't re-encode, but does change the format. Or, if your distribution has it, libfaac for audio.
ffmpeg -i myfile.flv -vcodec copy -acodec libfaac -aq 200 output.mp4 |
The -aq 200 is to improve audio quality. That one doesn't work on CentOS 6.x, I get unknown encoder libfaac, although the various faac packages are installed. Note that below I mention using libfaac, that was on CentOS 5.x. As I said, it's often difficult as different distributions and different versions of a distribution will have different names for a particular codec. Lately, however, it seems that in most cases, with ffmpeg, using -acodec aac -strict -2 has been working well for me.
The ffmpeg h264 encoding page has suggestions. I've often used, for an iPad2
ffmpeg -i myflie.mkv -profile:v high -level 4.1 myfile.mp4 |
which usually gives me a smaller file that works. If that doesn't work for you, on CentOS, I've also used 19 ffmpeg commands for all needs. I was able to use the following on CentOS 5.6 with success.
ffmpeg -i source_video.avi -acodec libfaac -ab 128kb -vcodec mpeg4 -b 1200kb -mbd 2 out_video.mp4 |
This usually works--on occasion, it will give an error which will include timebase not supported by mpeg4 in which case, you can usually fix it by adding -r 25 as a parameter. In other words
ffmpeg -i source_video.avi -acodec libfaac -ab 128kb -vcodec mpeg4 -b 1200kb -mbd 2 -r 25 out_video.mp4 |
The size should be 1024x768, but I find, using this syntax rather than the other one with the -vpre option that if I put -s 1024x768 in the ffmpeg command line, when copying the file to an iPad, iTunes will say it can't be played on this iPad. I haven't found the solution for this.
Either way, it seems more dependendent upon the size and ratio of the original avi. Even when the -s 1024x768 didn't give me an error, (in the first example, using -vpre), it still didn't play full screen. This is quite possibly due to an error on my part, but even using HandBrake, the video didn't come out as 1024x768.
Once the file is converted, you can transfer it to a Mac (or Windows machine with iTunes), add it to your iTunes library, then transfer it to your iPad.
One might have an instructional video dvd with a navigation menu and titles. I've never gotten one of these working successfully with an iPad, even when using its version of VLC. I've only been able to get the entire video on the iPad, without the chapters, but playing them in sequence.
First I mount the DVD and use vobcopy to mirror the disk, then I look at the size of the VOB files, cat them into one large VOB file and use HandBrakeCLI on that file.
mount /dev/scd0 /mnt vobcopy -m -i /mnt MYVIDEO cd MYVIDEO |
In any case when I have done this, there was a only a VIDEO_TS directory, no AUDIO_TS. Next I look at the size of the VOB files. Giving an example from an actual DVD exercise video. Remember, we're already in the MYVIDEO directory.
cd VIDEO_TS du -sh *VOB 120K VIDEO_TS.VOB 76K VTS_01_0.VOB 1.1G VTS_01_1.VOB 1.1G VTS_01_2.VOB 1.1G VTS_01_3.VOB 616M VTS_01_4.VOB 120K VTS_02_0.VOB 27M VTS_02_1.VOB |
Anything less than a megabyte is probably spacer. The 27 megabyte file is a disclaimer, along the lines of we take no responsibilty if you hurt yourself. The user can check each VOB file with mplayer to confirm what they want. In this case, I know that I want VTS_01_1,2,3, and 4. So, I make one large VOB file which will run the various sections as one large video.
cat VTS_01_1.VOB VTS_01_2.VOB VTS_01_3.VOB VTS_01_4.VOB > mynewvid.VOB |
Then I can run HandBrakeCLI on the mynewvid file.
HandBrakeCLI -i mynewvid.VOB -o MyExerciseVid.mp4 -Z "iPad" |
On occasion, I have had this method fail, with only the last VOB file being visible. I can use the ffmpeg concat filter mentioned earlier instead, which hasn't failed me yet.
The problem is that it only works on some dmg files. Many times, it will error out, saying it's not a proper dmg file, or something similar. Other times it works like a charm. Your mileage may vary.
As every time I've seen someone post the question about how to burn a dmg on a Linux machine on a forum, someone who doesn't know the answer asks, you shouldn't do that, why are you working with proprietary software on Linux, or something equally only relevant to those who don't use Linux for actual work, let me explain that anyone who works in an environment where both Linux and OSX are used might have a reason to do it. Perhaps the IT department only has Linux and Windows machines, with OSX reserved for customer service, and one has to distribute a properly purchased and licensed program to various users. That's just one example. Sometimes, the Mac users are doing something resource intensive--my own, non-benchmarked impression is that my Linux box uses less resources, and takes less time than using OSX's builtin burning programs. At any rate, there are various reasons it might be easier to do it on the Linux machine,
However, as mentioned, it doesn't always work. One can also try running mkisofs on a dmg, burning it to a DVD and seeing if it works. For example
mkisofs -o myimage.iso myimage.dmg |
Then the usual
growisofs -dvd-compat -Z /dev/scd0=myimage.iso |
Like acertone, this one doesn't always work.
The poweriso program itself, is another that sometimes works. It can be downloaded here. It's a tar.gz of the binary. Extract it with (version number may change, it's 1.3 at time of writing)
tar xvf poweriso-1.3.tar.gz |
This will give you a binary file called poweriso. Move the binary to your $HOME/bin, or /usr/local/bin.
mv poweriso /usr/local/bin |
To use it to convert a dmg to a burnable iso file, run
poweriso convert myfile.dmg -o myfile.iso |
There are a few other options with the tool. Run poweriso -? for a list.
The easiest way, of course, if one does have a Mac, is to right click on the image and choose burn to disc, but as mentioned above, sometimes, it is simpler to create a DVD on another machine for various reasons.
After some searching, I was able to make them available by re-encoding them and specifiying bitrate. So using
ffmpeg -i out.mp3 -b:a 256k out1.mp3 |
made the mp3 findable as a ringtone. Oddly enough, the phone, if I used its builtin file explorer, saw the original tones and could play them, but wouldn't make them available as a ringtone. I don't now if it is a Just Me issue, but this Android 9 seems to be picky. In addition, to load an epub not purchased from Barnes and Noble, until now, one used to put them in the Nook/MyDocuments directory. This Nook app doesn't have a MyDocuments directory, however, I was able to put an epub in the NOOK directory and from then on, it was visible when I opened Nook.
Before I figured this out, a cumbersome, but perhaps, usefulsolution that I found is that one can, in the case of a mobi, use the Amazon send to Kindle option. That page explains the procedure but, basically you go to your content and device page, and see the mailing address and approved sending address for your device. (In this my-phone, and it may have an address of something like myphone_ecad1B1@kindle.com, or possibly your username _ecadwhatever@kindle.com). The item should soon appear in content and devices under docs. Once you see it there, you can select an option to send to your device. It should then appear in home on the device, giving you the option to download it.
Using this enabled me to sideload books I'd purchased from NoStarch press, such as Michael Lucas's wonderful Absolute FreeBSD. If you buy it, they give you the option of an epub, mobi, or pdf. In this case, the mobi was 39MB, too big to mail. So I took the pdf. If you senda non mobi file, you can put convert in the subject line and it will convertt the file to a mobi, which it did.
As for epubs, neither Nook nor several other ereaders seemed to be able to open it on Android 9, though books purchased through Barnes and Noble, as mentioned, were fine. However, I used calibre's ebook-convert to convert the two epubs I had into mobis, then used the send to Kindle option. This is done quite simply with ebook-convert my.epub my.mobi.
When I first bought the phone, Google doesn't include a USB A to C cable, so I used FTP for file transfer, and files transferred that way seemed to be broken. I couldn't open epubs at all and mobis were sometimes readable, but very slow and corrupt. They do provide an adapter for A to C, so you can format a USB stick with fat32 and attach it to the phone and transfer files that way. Ironically, I realized a couple of days later that the reason the epubs and mobis weren't transferring properly was because, with the ftp client, I hadn't specified binary before making the transfers. (It seems to me that binary is usually the default, but it wasn't in this case). Anyway, had I thought of that, I could have saved myself some aggravation.
For file transfer, my preference is for using simple-mtpfs. Of course, that too, was more annoying than it had been. On my old phone, I would type simple-mtpfs /mnt and a dialog would appear on my phone, asking if I'd allow it or not. With this phone, there was no indication, it jsut failed to mount with errors like can't access device.
The solution, and I may have to do this every time I want to mount the device for file transfer), is to either search for USB in settings or sometimes, if you can tap the notification for USB, you can get a more options dialog. One of those options is transfer files. (The default is charging only). Once you tap the Transfer Files option, it should mount. It made me remember the Corey Doctorow (I think) quote to the effect that no one ever woke up thinking, Gee I hope the latest iTunes update lets me do even less with my iTunes. This update seems to make it harder to use, though I did find the workarounds.
As mentioned, my main reason for this article is to save myself some time. It is hoped that the reader finds at least some of it to be useful.