FFAStrans forum

I've sent you a common Bars in the format that's about 90% of what I have to deal with daily.
MXF HD422 1080i50 PAL
Tested it on your original workflow. Doesn't work on my side.
Thanks again for all your help!

Great, thanks a lot for the sample.
I guess this explains very well whats your probelm and i have to excuse for not delivering a more beginner friendly workflow up in front.

Your submitted file does not have black at start and also not at the end.
So the reason why my first example wf in this thread "does not work" for you is that it fails when there was no black found at start so actually it worked as designed. The sseof option works beautifully on your submitted file.


Now, my first workflow showed you not only how to detect black but also how to react in your workflow when there is no black.
I quickly altered the workflow and simplified it, allowing you to always go the "success path" no matter if there was black or not in the file.

But, no worries: in order not to make your life too easy and give you something to investigate, i added a "populate" processor at start which allows you "easy" altering of the black duration and analysis duration values So to change the values for experimenting, you do not have to alter the "command executor nodes anymore".

Hi again!
Thanks a lot for your effort in this matter.
Still I don't think we are in the same page so let me develop the idea a little further

I need to detect black frames, on MXF HD422 files on the beginning and end.
The files I work with come with 1, 2 or maybe more black frames in the beginning and no black frames, or 1, 2 or more at the end.
What I need to know is exactly how many, to limit them to exactly 2 black frames, at beginning and end.
Adding or removing those blacks is the easy part using FFastTrans.

I understood your first workflow, and changed it to gather the same info that I get from FFMPEG, setting the d=0.04 to get a single frame accuracy.
When I process MXFs in FFMPEG via the command line I do get those values, even with sseof function. But the same file on your workflow retrieves an error. And, yes, they have a few black frames at the beginning and end.

I'm sorry if the file I sent you might have led us apart even further. I just got it from a Bars folder with several formats, because the actual MXFs that I have are from clients and didn't want to send those. But I'll setup a proper MXF with black on beginning and end, that I can get the values in FFMPEg via command line, but that does not work with your inicial workflow to see if we get on the same page

Thanks again!

understood, so lets take this from a different side. I was under the impression you want to check for a specific Duration, e.g. see if there is exactly 1 minute duration black at start. I see now that you "just" want to get out how long the blacks are at start and end.

The first workflow especially fails when there was no black found at the specified conditions.
You say you can get the values using ffmpeg on the commandline, whats your commandline exactly? You say you use 40ms for the minimum black duration but whats the -ss/sseof value you are using?
Also you might want to check the ffmpeg output of the commandline processors by writing s_blackdetect* variables to a file.

Hi again!

I'm currently looking at the first 3 seconds (t-3) with d=0.04 and performing conditionals whether there is no black, or 0.04 (=1f), or 0.08 (2f), etc.
Then, I'll reverse the clip and do it again with t-3, so i'll get the end values and perform more conditionals.
But this is a workaround that just adds more time and resource consumption.

More testing done yesterday I discovered that I can indeed process MXF files using your initial workflow, even with -sseof, only not files from clients!
I can only process files that were already processed by me. Weird. Haven't tried it before because I was focused on the clients files. The "bars clip" situation led me to carry more testing.

I'm trying to gather 2 or 3 small MXF clips that fail on the initial WF to see if there is really something going on the way the file was written in the first place.
I'll get back to you soon! Thanks for all your help

I am really looking forward to see your results.
You might want to know that out of curiosity, i spent a huge amount of time today with the blackdetect and i found out that for most of the files, it will not report any black in certain cases.
E.g. searching for 20 ms minimum at file start, using -t 2 seconds: whenever the actual content black was "longer than the 2 seconds", ffmpeg actually did not report any black. (but searching black with --sseof always worked for me). This indicated some kind of bug in the ffmpeg blackdetect filter for me.

I had a chat in the ffmpeg-user list and fortunately a developer was interested and directly found and fixed this bug, he also added support for more color spaces and such but thats not really of interest.
Anyway, please know that there might be bugs that depend on what and how long you are searching, and how long the black in your video is compared to what you search.

Here is the fix from today,
https://github.com/FFmpeg/FFmpeg/commit ... 0038bda3f4

If you download the latest build tomorrow afternoon or monday, it should already contain the fix.
https://github.com/BtbN/FFmpeg-Builds/releases

In the end, the goal here, and how it should be is to enable you to find your black at start and end in a few seconds, independent of the source file duration (and nearly no processing resources) by using -t for start and -sseof for end. Both should work as expected.