By default the following unpresuming FFmpeg command:
ffmpeg -i "input.mp4" "output.mkv"
...will lossily encode a file unless it has the -c copy flag added, which will then pass the video through without any encoding. I remember not realising this as a beginner to FFmpeg years ago and being surprised when I found out, and ever since then it's something I've wondered about but not got around to asking.
The main justification for this behaviour that comes to mind for me is that encoding is a much more common operation, and it might be annoying to have to pass an extra -encode flag for most uses.
Was this ever one of the reasons cited for this design decision? Has the issue ever even been discussed in the FFmpeg mailing lists, or has it remained unquestioned since being written during the days of Fabrice Bellard?
Related
I understand how to make timelapse video from the sequence of files.
But what if my files have names like YYYYMMDDHHmmSS.jpg? How can I pass them in the correct order? I would prefer not to rename them (there are 55'000 files, almost 10 Gb).
I just found that there is no much sense to do any additional actions, the files are already sorted in the correct order, so the command below works well:
ffmpeg -framerate 500 -pattern_type glob -i '*.jpg' -c:v libx264 -pix_fmt yuv420p out2.mp4
I know there are some bat/shell commands possible for that, but IMHO it makes things more complicated for so little.
In similar cases I prefer using renaming softwares like Ant Renamer.
Drag & drop your files in the main window
In the Actions tab, click Enumeration in the list
You're given a naming scheme (look down the options to see the different schemes available).
I recommend using the default %name%_%num%%ext%, starting at 1 and with one more digit than your total number of files. Which in your case will result in YYYYMMDDHHmmSS_XXX.jpg
Click the Go button to process.
Once finished, check if the numbers added adequate the original file names (it should since the naming used is already chronological, but do check for safety).
It might not suit you, especially if you really want to do everything from command lines. But for other people, it might be enough.
I am working on re-encoding some footage (x264), including some grainy footage. I am interested in CRF-only bitrate management (I want to avoid artifacts during demanding scenes).
What are recommended parameters to be set instead of leaving them at their defaults?
Here is what I got so far, pretty simple:
ffmpeg -i in.mkv -vf unsharp=3:3:1 -c:v libx265 -tune:v grain -crf 24 -c:a copy out.mkv
(this example has grain tune as many files are grainy, and without it it washes it out and all the "detail by noise" is lost + I am applying a light sharpening filter, I find there is always a room to sharpen a bit without causing noticeable sharpening artifacts)
If I am not mistaken all the params one does consider are ones contained in the presets, but is there some other or one of those which is a good practice to adjust manually to achieve a better result? I was wondering specifically about P,I,B-frames and AQ (but I guess there are some other as well).
The defaults are what the developers recomend. But every video is different, and could be improved with custom settings. There is no “Better default”, because it could be worse on a different file. It can’t be know by anyone without the video file, and the preferences of the viewer.
I am using FFmpeg to mix a MP3 file containing a commentary track into the soundtrack of multimedia file. So far I have had great success using FFmpeg's sidechaincompress filter to auto-duck the soundtrack stream before mixing in the commentary. You can hear the commentary clearly, even when there's loud music or explosions going on in the film.
Awesome.
However, the issue I have now is during the very quiet scenes. When the soundtrack is very quiet, the commentary seems far too loud. If I adjust the volume of the entire commentary track so that it sounds right during the quiet scenes, it's too heard to hear during the loud scenes.
My current idea is to somehow use the sidechaincompress filter to duck the commentary track as well, before finally mixing it into the soundtrack. The problem though is that sidechaincompress compresses the target's volume when the source is loud, but I need the volume to be compressed when the source is quiet.
I have to admit that I am a quiet the newbie in this domain, so I may coming at this entirely wrong. I'm happy for any advice you can provide!
I've run into a similar problem recently and it seems like sidechaincompress does exactly what we need in this situation.
I used the following command to merge commentary[0:2] track with main track[0:1]
ffmpeg -i "multi-audio-track-source.mkv" -filter_complex "\
[0:1]aformat=sample_fmts=s16:channel_layouts=stereo[main];\ # these eliminate warnings about mismatching tracks.
[0:2]aformat=sample_fmts=s16:channel_layouts=stereo[commentarytmp];\ # these eliminate warnings about mismatching tracks.
[commentarytmp]asplit=2[commentarycmpr][commentary];\ # same connecting pin cannot be used in 2 filters so we have to make a copy of the commentary audio track for later mixing.
[main][commentarycmpr]sidechaincompress[cmpr]; \
[cmpr][commentary]amix[final]" \
-map "0:0" -map "[final]" \
-c:v copy -c:a aac single-audio-track-output.mkv
Used a older version of ffmpeg on a project and now im planning on switching over to avconv and was wondering if the -fps filter has been changed or depreciated? If it has been changed what is the current substitute for the -fps filter in avconv? Much Thanks
I have found that -r works quite well. But you care correct it does seem that fps filter has seen better days. It does almost work sometimes, but not others.
Make sure to use -r right before the output file, otherwise it can be interpreted to be the frame rate of one of the input streams if you write your command in some ways.
how can i create a checksum of only the media data without the metadata to get a stable identification for a media file. preferably an cross platform approach with a library that has support for many formats. e.g. vlc, ffmpeg or mplayer.
(media files should be audio and video in common formats, images would be nice to have too)
Well, it may be 11 years too late for an answer, but in case others like me stumble upon this...
ffmpeg can output checksums for individual streams. So the same audio or video would output the same checksum independently of it's container format or metadata.
Example for the video track of file $filename, writing the output to $filename.md5 :
ffmpeg -i "$filename" -map 0:v -codec copy -f md5 "$filename.md5"
For audio, use -map 0:a.
To output to STDOUT, use -. For example:
ffmpeg -i "$filename" -map 0:a -codec copy -hide_banner -loglevel warning -f md5 -
I don't know of any existing platform-independent software that will accomplish this, but I do know a way that this could be accomplished in an interpreted (platform-independent) language such as Java.
Essentially, we simply need to strip any metadata (tags) from the file, demultiplexing video files beforehand. Theoretically after demux and removing metadata, one could hash the file and compare against another file that has undergone the same process to match identical files despite having different tags. Unlike a fingerprint, this would not identify similar songs/movies but identical files (imagine you might want the 10 different versions or bitrates of a given song you've archived, but don't want 2 identical copies of any of them floating around).
The most troubling part of this is removing tags as there are many different specifications for tag formats which are not necessarily implemented the same across different applications, i.e. the same exact audio file given identical tags separately through two different applications may not result in identical output files. The only way this could pose an issue fatal to the concept of an audio-only checksum is if popular tagging software makes any changes to the binary audio portion of the file, or pads the audio in a non-standard way.
Taking a checksum is trivial, but I'm not aware off the top of my head of any platform independent libraries to demux and detag mpeg files. I know that in 'nix environments, mpgtx is a great command-line tool that could perform the demux and detag, but obviously that is not a platform-independent solution.
Maybe someone out there feels ambitious?
one possible solution i found seems to be with vlc:
./VLC -I rc snd.mp3 :sout='#std{mux=raw,access=file,dst=-}' vlc://quit | sha1sum