Page 2 of 2

Re: 1.0.0.5 | Watermark glitches with x264

Posted: Fri May 15, 2020 8:27 pm
by emcodem
ArsenioV wrote: Fri May 15, 2020 3:47 pm I tried it in CMD with a simple add command

The "mp4box --add" was all i wanted you to test, this way you changed the mp4 container from ffmpeg to the default one from mp4box. Currently we have no indication that any special "box" in the mp4 is missing, i just wanted a different container manufacturer but the same essence.
After testing the CBR setting, did you see the "Overall bit rate mode=Variable" gone in the new file?

To give you some insight, what i do for this kind of incompatibility issues, i first need to get out if it is about the container or the video/audio stream.

To be honest, i am still not 100% convinced that the container is out of scope here, but still, my next steps would be:
-) check for logs from protools that may indicate if the problem is in container or video or audio (or metadata)
ArsenioV wrote: Fri May 15, 2020 3:47 pm Also where should I put the Command Executor step in the FFastrans workflow once this is setup? Before the Delivery or after?
Instead of the Delivery node. After Encoding, the File is located in the cache directory of ffastrans. When you rewrap you can just specify the final destination path as output path.

BUT you should not automate anything in ffastrans (or anywhere else) until you exactly know what to do, so first get out whats causing the incompatibility, then automate the solution

Next steps for me would be to try to remove the video from the non-working mp4 file by using "ffmpeg -codec copy -vn".
If that works, we are pretty sure that it is about the video encoding properties and need to try to recreate all possible stuff from the working file into the non working file (my first guess would be b-frame related stuff)

-- done for today ;-) --

Re: 1.0.0.5 | Watermark glitches with x264

Posted: Fri May 15, 2020 8:39 pm
by ArsenioV
deleted

Re: 1.0.0.5 | Watermark glitches with x264

Posted: Sat May 16, 2020 10:05 am
by momocampo
Hi Giacomo,
Well, if you have a BM Ultrastudio HD, and if the installation is correct (Thunderbolt to MAC/HDMI output and/or SDI to monitoring/BM Desktop with last driver installed), you must be able to read almost all video codecs :
Image

So no need to create any H264. You have a real good video engine and the desktop app is compatible with your Pro tools version:
Image

BUT you told us you want h264 files to save storage so OK. The pro tools link from previous page said "H.264 (CFR Media Only) (MOV, MP4, M4V)" so as @Encodem told you , you need to create a file with constant bitrate. I just try to read this kind of file with BM media express(which could be installed with BM desktop video installation MAC) and no problem to read, so your BM Ultrastudio can read it too.
Hope it helps because I must admit it's difficult for me to understand your final purpose :)

Cheers.

Benjamin

Re: 1.0.0.5 | Watermark glitches with x264

Posted: Mon May 18, 2020 10:49 am
by ArsenioV
deleted

Re: 1.0.0.5 | Watermark glitches with x264

Posted: Mon May 18, 2020 2:52 pm
by emcodem
Hey Giacomo

cool that you understood what i want from you and that you were able to isolate the cause of the issues.
So, using the h264 processor node, -c:a aac is set by default (you can check the internally generated ffmpeg command using the webinterface).
Also, "-b:a 256k -ar:a 48000" can just be set using the node configuration interface, on the top right, Bitrate and Sample rate. Setting those parameters will cause exactly the ffmpeg command that you like...

And no worries about the 17ms duration difference, this is just some kind of "header" in the aac codec, it should be there in each and every file that has aac codec and it is something that mediainfo displays even if it should not really display it.