[Mark Burton]

[len hugh]
If you run your ffmpeg code without the fast start flag does it fix the white flash fault?
Thanks for the ideas L, really appreciate having your help. I still see the white flash on files encoded without the fast start flag in the command.

If so, if you run ffmpeg over the output and only add the fast start does the fault remain gone?
eg
ffmpeg -i outputFile.mov -movflags +faststart outputFile_with_faststart.mov
Although removing the fast start flag didn’t work, I did try this and it actually makes the problem worse.

Looking at these files in iMediaHUD, the original Avid source file has a duration of 00:01:11.042, this is shown the same for both the video and audio tracks.

Encoding with ffmpeg (with or without fast start flag) shows a duration of 00:01:11:042 for the video track and 00:01:11:063 for the audio track.

Doing the fast start only command on the output file from above makes it even worse; now the video track has changed to 00:01:11.084 and the audio track has changed to 00:01:11.116.

Both of the above files show white frame at the end of the clip.

Is the Mpegstreamclip output the correct number of frames and the FFMPEG output is one frame longer then your avid sequence?
Exactly, MPEG Streamclip fixes the discrepancy between the video and audio tracks.

I have also tested doing the original ffmpeg command with the a:c set to copy and this produces a perfect file, albeit with uncompressed audio which is not much help to me. So we know its an AAC issue.

Looking at the available AAC encoders, I would have to compile ffmpeg myself in order to use alternate AAC (non free) encoders and I’m not sure they would make any difference (see link below).

If you use -ss and specify the same start and end code as you have in avid does that effect the result?”
Good idea. Although not sure -ss is the right one to use is it? I tried adding -t to the command and entering 00:01:11.042, but the audio track is still longer.

Reading this post, it seems like this has been an issue for a very long time and almost considered the correct behaviour. Very strange. Surely creating H264 AAC files is one of the most popular uses for ffmpeg, can’t believe this is an acceptable output.

Do you not see this on your AAC files?

[Mark Burton]

I have now tested doing an open and resave of the encoded file in MPEG Streamclip (which retains the fast start header I need) and the resaved file does not display the white frame!

Interestingly, looking the length of the file in our streaming player, the original encode shows its 1 frame longer than the resaved version. This all points to the fact the audio is being encoded a few milliseconds longer than the video and a ‘false’ frame is being created by the player to allow the audio to finish playing.

I need my files to be saved with the faststart header and obviously it would be great to avoid using MPEG Streamclip each time on top of the encode process.

Still keen to properly test the -shortest flag, as so far I’m not finding thats helping but may not be using it in the correct place.

Any other thoughts? I can’t use another aac library as the other high quality libraries are not included in the binaries due to licensing restrictions I believe.

[Mark Burton]

Thanks. I did try that before since it was mentioned in another thread – from my first post – the user in that post reported that it made no difference for them. I found it also made no difference for me. Although I wasn’t 100% clear on the best place to put -shortest in the ffmpeg commend, where should it go in the command?

Many thanks to everyone for the continued help and ideas.

[Mark Burton]

Thanks for that. Have tested with the latest and its no different unfortunately.

[Mark Burton]

Got it. Could you point me to the latest Mac OS X build from the current git master.
Thanks

[Mark Burton]

As per the other threads linked, this appears to be limited to x264 and clips with both audio and video and has something to do with millisecond differences in the audio length compared to the frames of the video. Really hoping someone has found a workaround as making H264 files is a hugely popular use for this tool.

Please test a build from recent git master. For OS X you can get a recent snapshot from here:
https://evermeet.cx/ffmpeg/
No difference with latest 2.7.2 build.

What player are you using? Does it occur with ffplay?
It does not show in QT Player and other Quicktime based playback engines. It does show in VLC, Quicktime and another online viewing platform we use. I don’t use ffplay, but believe it does show the issue based on the other threads linked. Basically its there, its just that some players down’t read it.

Does it occur if you do not encode the audio? (add -an option)
Only occurs when there is audio as well.

Does it occur with a different video encoder, such as mpeg4?
Issue seems to be limited to the x264 codec.

Does it occur with just one input file, or others too? Do you have a short input file you can share so the issue can be reproduced?
Happens across all clips, sometimes it doesn’t, but I believe this is luck based on the audio samples and video length.

[Mark Burton]

Apologies, here is the full command and result.
Note – I have edited the inputfile and outputfile paths to remove the full path.
They are both located on the Desktop of the system.

Many thanks for any help you can offer,
Mark

ffmpeg -i input.mov -y -c:v libx264 -profile:v main -preset medium -b:v 2400000 -pix_fmt yuv420p -movflags +faststart -strict -2 -c:a aac -b:a 128k output.mov
ffmpeg version 2.5.2 Copyright (c) 2000-2014 the FFmpeg developers
built on Jan 1 2015 20:24:48 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
configuration: --prefix=/Volumes/tempdisk/sw --as=yasm --enable-gpl --enable-pthreads --disable-ffplay --disable-ffserver --disable-shared --enable-static --enable-libvpx --disable-decoder=libvpx --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libx265 --enable-libxvid --enable-zlib --enable-avfilter --enable-fontconfig --enable-libfreetype --enable-libass --enable-libutvideo --enable-filters --enable-postproc --enable-runtime-cpudetect
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 13.100 / 56. 13.100
libavformat 56. 15.102 / 56. 15.102
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 2.103 / 5. 2.103
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘/input.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2015-08-14 18:59:43
timecode : 01:00:00:00
Duration: 00:11:00.21, start: 0.000000, bitrate: 118696 kb/s
Stream #0:0(eng): Video: dnxhd (AVdn / 0x6E645641), yuv422p, 1920x1080, 116391 kb/s, 24 fps, 24 tbr, 24k tbn, 24k tbc (default)
Metadata:
creation_time : 2015-08-14 18:59:43
handler_name : Apple Alias Data Handler
encoder : Avid DNxHD Codec
Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, stereo, s32 (24 bit), 2304 kb/s (default)
Metadata:
creation_time : 2015-08-14 18:59:43
handler_name : Apple Alias Data Handler
Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
Metadata:
creation_time : 2015-08-14 19:03:29
handler_name : Apple Alias Data Handler
timecode : 01:00:00:00
[libx264 @ 0x7f8d8903b000] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 0x7f8d8903b000] profile Main, level 4.0
[libx264 @ 0x7f8d8903b000] 264 - core 142 r2479 dd79a61 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - https://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=36 lookahead_threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=24 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2400 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mov, to '/output.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
timecode : 01:00:00:00
encoder : Lavf56.15.102
Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x1080, q=-1--1, 2400 kb/s, 24 fps, 12288 tbn, 24 tbc (default)
Metadata:
creation_time : 2015-08-14 18:59:43
handler_name : Apple Alias Data Handler
encoder : Lavc56.13.100 libx264
Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp (24 bit), 128 kb/s (default)
Metadata:
creation_time : 2015-08-14 18:59:43
handler_name : Apple Alias Data Handler
encoder : Lavc56.13.100 aac
Stream mapping:
Stream #0:0 -> #0:0 (dnxhd (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (pcm_s24le (native) -> aac (native))
Press [q] to stop, [?] for help
[mov @ 0x7f8d89081000] Starting second pass: moving the moov atom to the beginning of the file
frame=15845 fps= 82 q=-1.0 Lsize= 11956kB time=00:11:00.22 bitrate= 148.4kbits/s
video:1145kB audio:10362kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.906625%
[libx264 @ 0x7f8d8903b000] frame I:64 Avg QP: 0.16 size: 431
[libx264 @ 0x7f8d8903b000] frame P:3993 Avg QP: 0.02 size: 78
[libx264 @ 0x7f8d8903b000] frame B:11788 Avg QP: 0.04 size: 71
[libx264 @ 0x7f8d8903b000] consecutive B-frames: 0.8% 0.0% 0.0% 99.2%
[libx264 @ 0x7f8d8903b000] mb I I16..4: 100.0% 0.0% 0.0%
[libx264 @ 0x7f8d8903b000] mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip:100.0%
[libx264 @ 0x7f8d8903b000] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:100.0%
[libx264 @ 0x7f8d8903b000] final ratefactor: -46.80
[libx264 @ 0x7f8d8903b000] coded y,uvDC,uvAC intra: 0.0% 0.0% 0.0% inter: 0.0% 0.0% 0.0%
[libx264 @ 0x7f8d8903b000] i16 v,h,dc,p: 99% 0% 1% 0%
[libx264 @ 0x7f8d8903b000] i8c dc,h,v,p: 100% 0% 0% 0%
[libx264 @ 0x7f8d8903b000] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x7f8d8903b000] kb/s:14.20

[Mark Burton]

I just came across your post here:
https://forums.creativecow.net/thread/291/1369

Which seems to have exactly what I’m looking for with regards to the timecode data read.

Do you know of any OS X ffmbc binary builds that are available for direct download? Building the binary myself is pretty daunting since I’ve never done anything like that before.

Thanks

[Mark Burton]

Thanks Len, this is great. For me its halved my encode time, amazing! We also have a drawtext putting a spoiler over the picture and resulting in a 1280×720 file.

The next task is to work out how to get ffmpeg to read the infile’s embedded timecode start value and somehow pass this to a drawtext filter set to burnin timecode. So far I’ve come up blank with all my searches.

Seems like it might not be a supported workflow with ffmpeg alone and may need to use something like ffprobe to grab the TC value before passing this onto an ffmpeg command. Possibly a two step applescript.

Are you working with infile embedded timecode at all?

[Mark Burton]

That is very interesting, thanks for testing those all out. I’ve been trying to put a filter string together to do crop and pad a 1920×1080 INPUT to 1280×720 OUTPUT, but am failing miserably at the moment. Can you give me any help with the crop and pad string you have working.

Many thanks
Mark