FFAStrans forum

Hello,

I have updated an instance of ffastrans from 1.2.2.0 to 1.3.0.2
After that a "custom ffmpeg" stopped applying changes on one of the audo tracks.

We are using sources file of this type:

This is the custom ffmpeg settings:

This creates a file that has the second audio track with the incorrect codec (shows as pcm s16le and not pcm s24le in vlc), bitdepth and bitrate:
While if i manually duplicate the parameter in top part of the custom ffpmeg in the ffmpeg option section:

I get a file with the correct detaits:

Is the custom ffmepg broken or am I doing something wrong?
I feel like its a bug as I can fix it by doing the duplication of parameters.

Regards,
Lue.

To be absolutely fair, when it comes to custom FFMpeg Script I've always inserted everything inside and left the things at the top blank, that's why I never noticed.
It makes sense, though, think about the commands you write as a BAT File, you would wanna have everything in there like in the second command you wrote, right?

As a really simple example, this is what I mean:




In your case, I know you think it's a regression, but to me it sort of makes sense.
Like, you specify a codec in the fields, such a codec is applied to the 0:1 only 'cause nothing is written to 0:2 so it default to PCM 16bit 'cause the container is mxf and it only supports PCM...

Anyway if you wanna be 100% sure, just treat the Custom FFMpeg script almost as you would treat a BAT File and specify everything in there and you won't have any surprise of this kind

Such issues should not happen after upgrading, @admin might be interested so i notify him hereby.

Alternatively to what frank said above, you can, step up from custom ffmpeg to cmd executor, all you have to do is to insert before your "FFmpeg options in custom ffmpeg node
and the output location of the final file at the end, e.g. And insert all the stuff into cmd executor processor instead of custom ffmpeg.

This way you have multiple benefits over using custom ffmpeg, e.g. the final file goes directly to the final output location instead of being written unneccessary to the local media cache, also you don't need a deliver processor anymore.
Besides that, it is a lot easier to debug and understand.

Hi lue3099,

Your right, this is due to a change in 1.3. It behaves different as it now only sets the codec parameter for the first output as opposed to a global option. When thinking about it the behavior of 1.2.2 was probably more correct when using the codec fields.

-steinar