How to change audio codec options?

[happysmash27]

I would like to record flac in 48000HZ. Is it currently possible to do this, and if not, would it be feasible for me, as a person with only basic C++ knowledge (but knowledge of C and the FFMPEG command line), to implement this before tomorrow?

[happysmash27]

frame-writer.cpp seems to have all the encoding for both the video and the audio. Now I need to figure out how to modify it.

...I think it is semi-clear how it works. I will make a fork, I think.

[happysmash27]

Update: It IS in fact feasible for me to modify this program before tommorow! I actually got it to record flac from a variable option and it even appears to work well =(^ヮ^)= !!!

Now the question is: What should I use for the command line arguments? Is the options parser able to take a short form that is too letters instead of one? I used "u" for audio, since "a" is already taken, and "u" is the second letter in it, but I feel that "ac" would be more appropriate.

The next thing I would like to do would be codec parameters, which are also hardcoded to be different than ideal. That too, I feel would be best with two letters, but maybe "q" will work for now, since it is the letter after "p" and rhymes with "u".

[soreau]

Update: It IS in fact feasible for me to modify this program before tommorow! I actually got it to record flac from a variable option and it even appears to work well =(^ヮ^)= !!!

Now the question is: What should I use for the command line arguments? Is the options parser able to take a short form that is too letters instead of one? I used "u" for audio, since "a" is already taken, and "u" is the second letter in it, but I feel that "ac" would be more appropriate.

If you wanted to implement this, it would probably make sense to have something like -C/--audio-codec to set the codec, in efforts to be consistent with the video options.

The next thing I would like to do would be codec parameters, which are also hardcoded to be different than ideal. That too, I feel would be best with two letters, but maybe "q" will work for now, since it is the letter after "p" and rhymes with "u".

Are you referring to the default parameters added when libx264/x265 is used? If so, then perhaps there could be an option to not set them. And since you can set additional parameters with -p/--codec-param, I don't see a reason to be able to change the defaults.

Since wf-recorder uses getopt_long for option parsing, only one letter is allowed for the shorthand option. See the getopt_long manpage for more information.

[happysmash27]

Ah, capital letters! That is a great idea!

By default parameters I was actually referring to the default audio parameters of a 44100 HZ sample rate and an S16 sample format, while to be accurate to my pulseaudio config it would need to be 48000 HZ and S32. Am I misinterpreting what "-p" is for? It isn't that clear in the documentation so I am a still trying to piece it together from the source code.

[ammen99]

@happysmash27 Making these parameters is mandatory, I'm afraid. Some codecs don't support 44100 input at all.

-p is used for video codec parameters. In the same train of thought, maybe -P would be fitting for audio codec params?

[happysmash27]

So, would the sample rate and format part be of the codec parameters, or would those be separate options?

[happysmash27]

I notice that frame rate is set separate from the codec options, for example, in the same way most of the audio options appear to be.

[happysmash27]

To be consistent with the option for "pixel-format" existing and the fact that framerate is set separately from the codec parameters, I have started implementing this as the following, moving the pixel format option to be under framerate in the structure:

{ "codec",           required_argument, NULL, 'c' },
{ "codec-param",     required_argument, NULL, 'p' },
{ "framerate",       required_argument, NULL, 'r' },
{ "pixel-format",    required_argument, NULL, 'x' },
{ "acodec",          required_argument, NULL, 'C' },
{ "acodec-param",    required_argument, NULL, 'P' ),
{ "sample-rate",     required_argument, NULL, 'R' },
{ "sample-format",   required_argument, NULL, 'X' },

I hope I have this right, but if not, it can always be re-implemented.

[ammen99]

Hmm, what kind of acodec-params are useful? (Asking because I'm not that familiar with the options that ffmpeg provides). And I'd also prefer the long options to be full-named, like audio-codec instead of acodec.

Otherwise, LGTM, would you like to send a PR? :)

[happysmash27]

Hmm, what kind of acodec-params are useful? (Asking because I'm not that familiar with the options that ffmpeg provides).

I'm still trying to figure that out. When I read:

Making these parameters is mandatory, I'm afraid.

I had assumed you were referring to -P, but on second thought, I think I may have been mistaken, and you were referring to the sample rate and sample format instead?

And I'd also prefer the long options to be full-named, like audio-codec instead of acodec.

What about for acodec-param? It gets a bit unwieldy when it is changed to audio-codec-param, and it would be inconsistent with the use of "param" instead of "parameter" as well.

Otherwise, LGTM, would you like to send a PR? :)

Exactly my plan! As I haven't done many PRs yet, however, I'm not sure if I should put it as a PR while it is in progress, and update as it gets finished, or leave it in this issue and make a PR when everything is more or less complete.

[happysmash27]

If you are wondering why I chose "acodec", by the way, it is because that is what ffmpeg uses, along with vcodec for video. If you would really like the long version of -P to be "--audio-codec-param", though, I can do that.

[ammen99]

I had assumed you were referring to -P, but on second thought, I think I may have been mistaken, and you were referring to the sample rate and sample format instead?

Yes, I was referring to sample rate and format ;)

Exactly my plan! As I haven't done many PRs yet, however, I'm not sure if I should put it as a PR while it is in progress, and update as it gets finished, or leave it in this issue and make a PR when everything is more or less complete.

You can open a pull request and mark it as a draft. This way, it will be visible to everyone, but since it is a draft we know that it is not ready for review & merging yet.

[ammen99]

If you are wondering why I chose "acodec", by the way, it is because that is what ffmpeg uses, along with vcodec for video. If you would really like the long version of -P to be "--audio-codec-param", though, I can do that.

Hmm, I didn't know that, good point. In this case, acodec is fine.

[happysmash27]

I'm surprised! I'm guessing you learned ffmpeg mostly as an API instead of a program? I use ffmpeg in the command line for many things (even some video editing occasionally), so the options I added that are not based on the current options are mostly based on ffmpeg ones, or are based on both.

This is the command I used to use to record my video output:

ffmpeg -f alsa -ac 2 -ar 44100 -i loopout -f alsa -i pulse -filter_complex amix=inputs=2 -f x11grab -s 1280x1024 -i :0.0 -r 60 -acodec pcm_s16le -vcodec libx264 -crf 0 -preset ultrafast output.mkv
ffmpeg -i output.mkv -vcodec libx264 final.avi
rm output.mkv

Looking back on it, I probably would have used different options today, but that is what I used back then.

If it wasn't a conscious decision to use --codec instead of --vcodec, I would recommend the latter, perhaps preserving --codec as an alias to it for backwards compatibility, just to be a bit more consistent with ffmpeg and with having a codec option for both audio and video. Perhaps that should be a separate issue/pull request, though.

[ammen99]

I'd rather not change what already exists, but maybe we can add vcodec for compatibility (in a separate PR). And yes, I learned mostly as an API, and I have almost zero experience with the actual ffmpeg command :)