Is this an updated project file from 8.0 to 8.1 or a brand new 8.1 project file? Try a new one.
This occurs in new projects as well.
Hadn't tested that till now, if you PM me directly i can provide you with a piece of footage created this way for internal testing.
after doing a bit of testing i found adding:
to the output lets AE see all the frames.
This is leading me to believe that any other speed setting is writing something to the first two frames that the latest versions of adobe products cannot read.
This should be looked into.
I just stumbled upon this bug as well. Is there any update on this?
Our organization has submitted a report on this, but it is still present in CC 2015.
I've had a report from Adobe that states the file's timecode starts 2 frames into the video, and that is the beginning. FFMPEG appears to be adding this discrepancy according to Adobe, and therefore they are reading the file correctly.
Might be one to take up with FFMPEG rather than Adobe...
Except this issue doesn't present itself in any other programs. Avid, and QT read it properly.
I don't doubt there's a problem with FFMPEG since i discovered the -ultrafast argument fixed the issue.
I just don't see why there is a discrep between different editorial programs and media players with After Effects. I suspect spaghetti code.
Still has an issue as of latest CC 2015 release. I've tried re-encoding the ffmpeg output (h.264) in other programs like Handbrake (with same framerate, encoding, etc) and then imported back into Premiere and AE. Missing 2 frames can be read correctly afterward. That makes me think its more ffmpeg's issue... doesn't explain why other progs can play those missing frames though.
Hi JoJo and LemurGuy,
I left my thread to languish, but it turns out there are ways around this. You have to be a big creative with your coding, and some of it might have to be rejigged to get it to work, but I found that utilizing the -r value for FPS causes the timing in FFMPEG to lose 2 frames when opening in Premiere. This can be worked around by using the -filter_complex command and fps=fps=XXX[outfps] where XXX is your frame rate and then I have used the -vsync 0 command to keep the timing. Annoyingly you cannot use -filter_complex and -filter (or -vf) in the same script. so you have to convert any filters into the filter_complex syntax and you can sometimes get long runs of commands separated by commas, but it does work.
ffmpeg -i "%filename%" -filter_complex "fps=fps=29.97[outv]" -vsync 0 -pix_fmt yuv420p -deinterlace -flags +ildct+ilme+gmc -cmp 13 -c:v libx264 -x264opts "chroma_me=1:keyint=50:keyint_min=5" -top 1 -b:v 4000k -maxrate 4000k -minrate 4000k -bufsize 10000k -map [outv] -map [0:1] -map [0:2] -c:a aac -strict -2 -ar 48000 -b:a 128k "%outputfile%.mp4"
Having spoken to Adobe they stated that the video (according to them), starts at the 2 frame mark. I have still been trying to work out why, but I believe it to be something to do with the reference frames and the timing.
Hope this helps.
This is a huge problem for my workflow too. I am being given large amounts of footage encoded in ffmpeg and re-encoding is simply not an option. Along with the 2 missing frames, the audio is slightly out of sync also, but not by exactly 2 frames, unfortunately (rather it is somewhere between 2 and 3 frames). This makes it nearly impossible to correct easily.
Since other programs as well as older versions of Premiere can handle the footage, I hope that a fix on the side of Adobe is possible.
I have the same problem, here is what I have found.
- DavidChaldecott mentioned using -vsync 0 helped. I was not able to get this working.
- LemurGuy mentioned -preset ultrafast helped him. This worked for me but the low quality with ultrafast does not work for me so I did a bit of research on it. I found this page that explains the differences between presets: beandog's x264 preset reference. I noticed that ultrafast was the only one with 0 bframes so I tweaked my ffmpeg command to use the medium preset and 0 bframes and it is working now. It is not as good as medium with bframes but it will let me get by, and I have some more tweaking I can do.
ffmpeg -i input_file.mov -vcodec libx264 -pix_fmt yuv420p -profile:v high -level 4.0 -preset medium -bf 0 -acodec pcm_s24le output_file.mov
When you used the mov encode with vsync=0 did you use your above code? I found that even though you are NOT doing a standards convert, the FPS value in my above example had to be set, then mapped. It's actually this that maintains the timing, then the -vsync value uses the original video timing. If this doesn't work I would be most interested, as I have an upcoming project doing the same thing but with SD content (from .mov's).
I really hope Adobe is willing to fix this issue from their side, as I have project workflows where I have no control over the encoding and re-encoding is simply not an option. Other applications don't have this problem, so it should be fixable on Adobe's side.
I did try vsync while specifying the framerate with -r.
I would suggest playing around w/ the bframes
1 person found this helpful
The correct workaround for this until Adobe fixes it is to disable B-Pyramids '-b-pyramids none'
B-Pyramids is a setting to allow B-frames to be used as reference frames. This can be useful on extremely static clips but overall has little to none improvement on the visual quality / file size.
From the ffmpeg documentation:
Set method for keeping of some B-frames as references. Possible values:
- ‘none (none)’
- ‘strict (strict)’
Strictly hierarchical pyramid.
- ‘normal (normal)’
Non-strict (not Blu-ray compatible).
The default is normal, which you can see isn't even Blu-Ray (or most other hardware players) compatible.
And it's safe to say that it's not Adobe compatible either but it's even worse than that! Adobe can't handle strict either. So the only thing you can do is to disable B-Pyramids.
So DON'T disable B-Frames all together. You're loosing way too much quality by doing that. Just disable the use of b-frames as ref frames. (B-Pyramids)
I hope this clear things up.