Custom FFMPEG Processor s_source

[whtghst1]

When s_source is set by a processor prior to a Custom FFmpeg processor, I would expect that the Custom FFmpeg processor would update the s_source after it is done transcoding. Am I wrong in thinking this?

The first processor following the Custom FFmpeg processor in my workflow still shows the s_source as it was set by the processor before the Custom FFmpeg processor.


Custom Plugin Processor#1(Sets s_source)->Conditional Processor(Checking number of audio channels)=>Custom FFmpeg processor->CMD Processor(still has s_source that was set by Processor#1).

[whtghst1]

If I removed the custom plugin processor and put in a populate variables processor and manually set the %s_source% simulating what the custom processor is doing the workflow works.

The one thing I noticed is the ticket that is received in the original workflow's custom ffmpeg and cmd processors has the following in the ticket

Code: Select all

"variables": [
    {
      "name": "s_source",
      "data": "\\\\testhost\\testshare\\FFAStore\\20231023-1359-0015-02d7-b31eaa475a67\\20231026-1527-1955-34d2-f495ce627f42\\test.ts
    },
    {
      "name": "s_success",
      "data": "Localized"
    }
  ],

The custom plugin does not set this so it must be something be added by ffastrans when s_source is set in the outputs from the custom plugin. Would this be whey the CMD processor is is getting the wrong value for %s_source%?

cmd string for the CMD processor:

Code: Select all

%comspec% /C "C:\bmx\bin\bmxtranswrap.exe -t op1a --aes-3 --track-map "0-5;6,7" -o "%s_job_work%\%s_original_name%.mxf" "%s_source%""

[emcodem]

After spending an hour with this, i was not able yet to find the root cause. It is probably something that @admin finds out and can correct in a few minutes.

Some findings:
-) it is still reproduceable in 1.4
-) It looks like the issue is not bound to the custom ffmpeg encoder but it can be reproduced with any encoder.
-) funny enough, it is not reproduceable with the populate vars proc, even if they look the same from code perspective regarting setting $s_JOB_SOURCE_FILE

We can use this workflow to reproduce, it sets s_source to c:\temp\image.png, you want to replace this by some existing path to some small file.

emcodem_reproduce_s_source.json

(3.04 KiB) Downloaded 37 times

[emcodem]

Thankfully steinar was able to locate and fix the issue quickly, i created a hotfix version of it for you from the source code of the latest official release, 1.3.1. Just replace \Processors\processors.a3x. Of course the next release 1.4 has the fix also.

processors.a3x

(802.95 KiB) Downloaded 29 times

The fun is that i didn't yet create a plugin proc that produces a new s_source so the support for setting it was more theoretical until you located this issue

[whtghst1]

This fixes the issue for me.

Thanks to you and steinar!

Now my testing for my custom plugin processor is complete and works.

[emcodem]

Perfect, thanks for the confirmation. Sorry for this shortcoming..