-1

I'm currently struggling with getting variables within "quoatation marks"
My code looks like this:

const char* cmd = "ffmpeg -r 25 -f rawvideo -pix_fmt rgba -s 1280x720 -i - "
"-threads 0 -preset fast -y -pix_fmt yuv420p -crf 21 -vf vflip output.mp4";

Now I got two int variables named "previewWidth" and "previewHeight" and I want them to replace the "1280x720". But I can't figure out how to do that

Thanks,
Marco

Marco Reisacher
  • 85
  • 1
  • 13

3 Answers3

2
std::string get_command(int previewWidth, int previewHeight) {
  std::stringstream ss;
  ss << "ffmpeg -r 25 -f rawvideo -pix_fmt rgba -s ";
  ss << previewWidth << 'x' << previewHeight;
  ss << "-i - -threads 0 -preset fast -y -pix_fmt yuv420p -crf 21 -vf vflip output.mp4";
  return ss.str();
}

then at point of use:

const std::string cmd = get_command(previewWidth, previewHeight);

and call cmd.c_str() to get the raw const char* to pass to whatever API.

Note that this is not the fastest solution, but you are about to call an external process to do audio file manipulation (probably writing to disk), so the relatively slowness of stringstream shouldn't matter much.

stringstream makes it really easy to build up strings, and is very safe. It is quite slow at it compared to alternatives, but ease and safety often trumps speed.

Advanced technique:

In C++11 I will sometimes use a lambda:

const std::string cmd = [&]{
  std::stringstream ss;
  ss << "ffmpeg -r 25 -f rawvideo -pix_fmt rgba -s ";
  ss << previewWidth << 'x' << previewHeight;
  ss << "-i - -threads 0 -preset fast -y -pix_fmt yuv420p -crf 21 -vf vflip output.mp4";
  ss.str();
}();

and do my string building in there rather than create helper functions, if I don't think this task deserved a helper function. The above is a useful technique to create trace messages or the like, or for simple "scratch" work before I refactor the string building operation into its own function.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
0

Use sprintf.

In your case:

unsigned int previewWidth = /* init */;
unsigned int previewHeight = /* init */;

const char* raw_cmd = "ffmpeg -r 25 -f rawvideo -pix_fmt rgba -s %ux%u -i - "
"-threads 0 -preset fast -y -pix_fmt yuv420p -crf 21 -vf vflip output.mp4";

char result_cmd[256];

sprintf(result_cmd, raw_cmd, previewWidth, previewHeight);

Now, result_cmd contains your result command, but these two %u were replaced with values of previewWidth and previewHeight, respectively.

Null terminator is automatically appended by sprintf().

One more thing, I assumed, that width and height cannot be negative. If they can, replace %u (unsigned) with %d (decimal).

See this page for complete list of specifiers available for many printing functions in C(++).

Mateusz Grzejek
  • 11,698
  • 3
  • 32
  • 49
-1
int previewWidth, previewHeight;
// ...
char cmd[1024];
sprintf (cmd, "ffmpeg -r 25 -f rawvideo -pix_fmt rgba -s %dx%d -i - "
    "-threads 0 -preset fast -y -pix_fmt yuv420p -crf 21 -vf vflip output.mp4",
    previewWidth, previewHeight);

Since this is C++, you'd be better off using std::string.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • What if you have really, really big ints? – Yakk - Adam Nevraumont Mar 26 '15 at 20:38
  • Thanks!! Working perfectly – Marco Reisacher Mar 26 '15 at 20:43
  • @Puppy One step at a time. – David Schwartz Mar 26 '15 at 20:46
  • @Puppy to be fair, it would require `int`s of size more than (1024-125-1)/3=150 bits to overflow that buffer. So the above code is not *likely* to cause undefined behavior. However, seemingly innocuous modifications to the above code by a novice can easily cause things to break horribly, which is the real problem with it. – Yakk - Adam Nevraumont Mar 26 '15 at 20:47
  • You need to use `snprintf` to prevent buffer overflows. – Thomas Matthews Mar 26 '15 at 20:48
  • @ThomasMatthews the above code can be proven to be safe against buffer overflows until `int` approaches 1347 bits (my /3 above was wrong -- should be *3). The problem isn't a direct buffer overflow: it is what happens when it falls into its maintenance lifecycle. Someone (say, a new programmer who doesn't know how to format ints for printing, but can copy someone else's code and make trail-and-error changes to it) makes a change that isn't careful, and it explodes on them long after they make the change. – Yakk - Adam Nevraumont Mar 26 '15 at 20:57
  • @Yakk: I'm presently working on a safety critical embedded systems project. Murphy's law is what we are trying to avoid. The cases that "won't likely happen" **will** be triggered by the customer, it's only a matter of when. For safety critical systems, if this can be avoided, it's another hazard removed that will save the company money trying to defend lawsuits (especially those that begin with "we new the probability was low...). – Thomas Matthews Mar 26 '15 at 21:00
  • @ThomasMatthews The code as written **will not** buffer overflow on any actual hardware in existence. The code as written **is dangerous** because future modifications to the code can easily cause it to buffer overflow. Nothing about this is "won't likely happen". No customer of the above code that does not modify it could possibly make it buffer overflow. If it is in a code base that persists longer than the short term, it and code like it present a *high* probability (approaching certainty) that buffer overflows will be introduced. Again, nothing "won't likely happen". – Yakk - Adam Nevraumont Mar 26 '15 at 21:11
  • Downvoters are expecting a question from someone asking how to crawl to explain how to operate a motor vehicle on a congested highway. – David Schwartz Mar 26 '15 at 21:54
  • @DavidSchwartz: It's substantially *easier* to simply use a stringstream or something. Furthermore, whilst I accept that he should go one step at a time, that step should actually benefit the learner. – Puppy Mar 27 '15 at 12:14
  • @Puppy Having someone who knew how to use `stringstream` but didn't know how to use `sprintf` would, at least in my opinion, be a strange thing indeed. I think it's just a matter of which you consider "first", and maybe I'm showing my age here. – David Schwartz Mar 27 '15 at 15:31