I had a bash script in 13.2 to convert camera video files to mp4. Now, after a fresh install of leap 42.1 I cannot convert any video anymore. I get:
[NULL @ 0x17377a0] Unable to find a suitable output format for ‘/home/XXX/uploads/pc195526.mp4’
/home/XXX/uploads/pc195526.mp4: Invalid argument
Anyone has a solution?
I tried by replacing any ffmpeg related package for one from packman but the result is the same. Did a compare with my old install which is on another partition to find missing packages, also not.
I used this command:
ffmpeg -i /mnt/datadisk/fotos/nieuw-OM-D-EM5/pc195526.mov -pix_fmt yuv420p -s 568x320 -b:v 500k -vcodec libx264 -r 30 -ar 44100 -b:a 128k -acodec libmp3lame -y /home/XXX/uploads/pc195526.mp4
I also tried more basic commands, and other destination codecs, nothing seems to work.
Have you tried running mpeg instead of ffmpeg?
Different set of tools, but from the command line pretty much the same as ffmpeg.
Then, it’s simply a matter of what codecs you have installed.
I still don’t know what is the “crippled” nature wolfi may be describing, but in my experience codecs are pretty basic and universal (except gstreamer implements a whole new architecture). It’s hard for me to envision an issue with the codecs themselves but might consider something may be amiss with the tools used to manipulate functionality accessing the codecs so if this is the case then “mpeg” might bypass any possible ffmpeg issues which might exist.
Maybe you should also mention where to get this “mpeg” from.
wolfi@linux-lf90:~> mpeg
If 'mpeg' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf mpeg
wolfi@linux-lf90:~> cnf mpeg
mpeg: command not found
I still don’t know what is the “crippled” nature wolfi may be describing,
The ffmpeg and accompanying libraries (libavcodec in particular) included in openSUSE do not contain support for many “restricted” formats/codecs.
but in my experience codecs are pretty basic and universal.
Right, but they are just missing completely in the packages shipped by openSUSE.
Thx wolfi,
Been a little while since I did this, so this is updating my recommendation…
As you described, the app I actually meant to refer to “mplayer” is not in the current OSS and don’t know why (The project is very current and actively maintained). I remember that smplayer is similar in ways but not the same as “mplayer” which includes not only the player app but the important “mencoder” functionality which can be used to do stuff like transcoding. In fact, this “mencoder” is the heart and engine upon which the more well known actual view/player is based on.
I don’t know of another application similar to mplayer that is as powerful and versatile, so I wonder the reasoning for dropping mplayer (don’t know when). If you install it, it also will install its own ffmpeg codecs so I assume this should also address anything that might affect other ffmpeg distributions. In fact, this was the way I addressed the codecs issue before the current recommendations found in the Multimedia Forum stickies.
The machine I’m on does not have Packman installed, so don’t know if it’s available through Packman.
The mplayer downloads page, note there are instructions how to build, and a link to the binary codecs that are ensured to work with mplayer and mencoder. http://www.mplayerhq.hu/design7/dload.html
Based on my prior usage, I highly endorse using mencoder to transcode, and the mplayer app itself was always a useful alternative to other video players (yes, historically not all videos are easily viewed in the same player or some player just might do a better job).
That could be easily tested.
AFAIK the most common and well known codec with licensing issues is h.264 and until very recently h.264 had no peers for quality. The most common publicly licensed codec was (and probably still is) vorbis-ogg, but many will notice a quality difference.
So,
The OP should be able for instance try to transcode to OGG using any container format including mp4, avi, etc. and see if it works on a current openSUSE default setup… and it should work.
Then try again but the only difference would be to specify h.264 instead and that would fail.
IIRC the h.264 license should be free for private use but subject to fees for anything created for publishing.
The main alternative today should be Google’s webm which is owned by Google and freely usable for any purpose, private or commercial without encumbrances but I haven’t looked into what kind of tools support.
For the same reasons that ffmpeg was missing until some months ago.
Restricted codecs cannot be included in the distribution for legal reasons.
I remember that smplayer is similar in ways but not the same as “mplayer” which includes not only the player app but the important “mencoder” functionality which can be used to do stuff like transcoding. In fact, this “mencoder” is the heart and engine upon which the more well known actual view/player is based on.
Ok, so you actually meant “mencoder”, not “mpeg”.
If you install it, it also will install its own ffmpeg codecs so I assume this should also address anything that might affect other ffmpeg distributions. In fact, this was the way I addressed the codecs issue before the current recommendations found in the Multimedia Forum stickies.
That’s wrong.
Packman’s MPlayer package uses the system ffmpeg since a few months.
From the package changelog:
* Fri Jul 10 2015 joerg.lorenzen@ki.tng.de
- build against libffmpeg-devel
And:
* Tue Oct 20 2015 joerg.lorenzen@ki.tng.de
- update to version 1.2.r37548
- remove ffmpeg source package because all required devel files now
are provided by libffmpeg-devel.
So if ffmpeg doesn’t “work”, mencoder likely will not as well.
Btw, ffmpeg was originally developed by the MPlayer team AFAIK…
The machine I’m on does not have Packman installed, so don’t know if it’s available through Packman.
And what does that mean?
OGG is a container format, just like avi and mpeg (mp4 not).
The container format doesn’t really matter, it’s the codecs that are missing.
And yes, transcoding from/to OGG (with VORBIS as codec e.g.) should work in a default setup, but transcoding from (or to) e.g. mp4 or divx will not.
avi is supported (as it’s just a container format), but it depends on the actual codecs used.
Another alternative, particularly if you intend to use the command line tools directly(invoking command line) and aren’t concerned about providing integrated support for applications (like players)
You can simply clone the ffmpeg source which should be completely self-contained (and bleeding edge up to date), not modified by anyone
Yes, but you might break the installed packages (i.e. your desktop’s sound notifications, vlc or any other installed media player) by doing this.
Although, the changes in ffmpeg are not that drastic and incompatible nowadays as they have been in earlier times…
In the end I’d say it isn’t really worth the effort. Just consider ffmpeg a low-level package like glibc, if you want working multimedia.
And I am not a guy who’s afraid of recompiling things himself…
