[FFmpeg-user] ff* command lines that work

Moritz Barsnick barsnick at gmx.net
Tue Mar 10 11:51:41 EET 2020


On Mon, Mar 09, 2020 at 17:44:29 -0400, Mark Filipak wrote:
> On 03/09/2020 05:10 PM, Robin A. Jensen via ffmpeg-user wrote:
> > This will work.
[...]
> > ffmpeg -txt_format text -txt_page 599 -fix_sub_duration -ss 00:02:40
> > -c:v h264_mmal -i 'Beck Øje for Øje (4).ts' -to 01:32:10 -map 0:0 -c:v
> > h264_omx -b:v 4800k -map 0:2 -c:a copy -map 0:1 -c:s:0 mov_text
> > -metadata:s:s language=dan 'Beck(4).mp4'

This is proof of why this intent of collecting command lines is totally
misleading. This will work *in certain cases*. What if the text page is
different? What if it's not run on a Raspberry Pi? (It won't work
anywhere else!). You need to understand both the input and the intent,
in order to understand a command line. (Kudos to Robin for
complementing his command line with that.)

> Thank you, Robin. I assume that 'text' is a text-URL.

There you go. You got a "working" command line, and you make assumption,
and they are wrong. How did this command line help you? If you had
looked up (yes, did your own homework) the option "-txt_format", you
would have seen that "text" is a literal value for this option:

$ ffmpeg -h full | grep -A5 txt_format
[...]
  -txt_format        <int>        .D...S.... format of the subtitles (bitmap or text or ass) (from 0 to 2) (default bitmap)
     bitmap          0            .D...S....
     text            1            .D...S....
     ass             2            .D...S....
  -txt_left          <int>        .D...S.... x offset of generated bitmaps (from 0 to 65535) (default 0)
  -txt_top           <int>        .D...S.... y offset of generated bitmaps (from 0 to 65535) (default 0)

Also feel free to check the docs instead. You would e.g. land here (via Google "ffmpeg txt_format"):
https://ffmpeg.org/ffmpeg-all.html#toc-Options-6

> Also, this provides welcome clues regarding '-map'.

Map is well explained in the docs, but we can reiterate, if you have a
specific issue.

I honestly suggest that you work this the other way around: Give
yourself a task, i.e. describe what you want to achieve with ffmpeg,
and work yourself though it. Easiest: remux a video file, e.g. from
Matroska to MP4. Again, I could give you a "proven working" command
line, and it may still not work for you:

$ ffmpeg -i input.mkv -c copy output.mp4

I say: "It works for me!" You say: "It doesn't work!" Who was right?
Will you throw it out of your collection of command lines? Here's the
reasons why it might not work:
- MP4 can't handle one of the input's codecs (by design, not by
  ffmpeg's fault)
- ffmpeg can't convert the subtitles to an MP4-compatible format, so
  you miss them.
- One of the audio streams is missing. (ffmpeg by default only carries
  one over. But no need to overcomplicate the command line if the input
  only has one audio stream 99.9 % of the time.)
- Everything is fine, but your media player shows a blank screen. (Your
  media player can't handle the pixel format, e.g. yuv444p. The
  conversion was still "correct", but not for your requirements, which
  you may only figure out later.)

There are so many ways that something which is correct can be
incorrect. That's why a big collection is useless. Especially with "-c:v
h264_omx" if you're not running on a RaspberryPi. ;-)

As others have suggested often: Read some docs, read along on this list
(or in its archives) for a few weeks, find some personal requirements,
fiddle around with them, Google or StackOverflow your issue, and come
back to us if something then isn't turning out as expected. Provide
your actual command line and its complete, uncut console output. ;-)
Also figure out what your are trying to achieve, later tell us what
that was, and why the result didn't meet your expectations.

Cheers,
Moritz


More information about the ffmpeg-user mailing list