I have tried combining with both MP4box and ffmpeg (no reencode, straight copy) and it gives the same issue.
I THINK I know whats going on.
So I had a look at the framerates -- All the videos before combining are 47.952047 fps After combining, These are the framerates i get out of it: 4 x 47.951612 1 x 47.951592 1 x 47.951520
The 47.951520 does not work, but the 47.951592 one does.
I am guessing that the fps comparison is rounding to the nearest 0.0001 fps... so after rounding it would be 5 x 47.9516 1 x 47.9515
I think it needs to be 0.001fps instead. so the resultant fps would be 6 x 47.951
I will pm you with two files. one which is the original, one which is the concatted 3 times. these SHOULD work together but dont in AVP.
We reproduce your issue by merging your files with ffmpeg. And other applications (like VLC) also detect the framerate difference. In AVP, we are able to merge mp4 by using "Import all GoPros" dialogue.
So, to well merge your files you can simulate that your videos are GoPro chapter and use the merger of AVP. To do that, rename your videos like GOPR0002.MP4, GP010002.MP4, GP020002.MP4 and put them in a folder like "D:\DCIM\100GOPRO" Check the option "Merge successive chapters" before to transfer the selection. Merged video should have the right framerate.
We will think about to expose this merging feature outside the GoPro importer.
This issue is not only with ffmpeg but also with mp4box. both output the same framerate change
We will think about to expose this merging feature outside the GoPro importer.
That would be ideal... or even a way of pointing to a folder to process.
Is there a more technical reason for what is going on? just so that we can find a way of processing them without the importer? (all the cameras have been transferred and wiped, not to mention on firmware v3.00(mtp mode))
Got the same issue here, with files combined with FFMPEG. Can't you just change this error check in AVP to be a little bit less picky? Does it really matter if the framerates are off on the 4th decimal? (that will likely never be noticed by anyone as far as how the cameras sync) We're talking about tiny fractions of a second, I think AVP needs to be a little more forgiving here.
Since I even had to stitch a converted file from 25 to 29.97 fps once and it went pretty much ok (granted, not much happened in that frame), I'd say +1 for looser framerate requirements!
Hi, Ok so on the topic of framerate matching, no, it's never a good idea to loosen our checks. The MP4 containers do not store framerate, so we recompute them. When the result is 47.951612 vs 47.951592 vs 47.951520, we can't know why. Is it rounding error from a video merge? Is it a real fps difference? What we do now (I think that's in 2,5) is that we truncate fps after the 3rd decimal. Doing more rounding or truncating exposes use to frame desynchronisation after a few minutes of video, which is... bad.
Plus AVP 2,5 has a new tool to merge videos, in "tools" > "merge videos" that doesn't change the framerate of the input videos, and that should help a lot. And we will update the wiki page accordingly.
Emeric, thanks for taking time to reply, much appreciated! What I said is not to loosen checks, but loosen requirements and issue a warning. If the video is short enough, problems won't be noticed even with .03 fps difference (29,97 vs 30) in the vast majority of videos. I know that we're dealing with edge cases here but it's still something really annoying when it happens, and I found myself fiddling with ffmpeg doing the worst #### to make AVP gulp it down Super Low priority, but you could even give the possibility to adjust synchro by allowing putting drop frames or double frames for specific cameras.
Btw when you're dealing with hundreds of takes that were alreay downloaded on set, your in-program tools have, to be honest, still a long way to go before being useful at all (:
Well regarding your 29,97 vs 30 frames per seconds, there will be one frame desynchronisation per 33 seconds of video. So honestly, loosening the requirement will produces more bugs reports / forum posts than it will solves...
And for the merger, would an multiplatform drag&drop GUI be of more interest to you?
Emeric, sometimes the camera that was misconfigured looked the right way (meaning, not where the action is) and nobody would notice a frame's difference, or the take just needs to last 20 seconds. You being the dev, it's clear that it's up to you, for sure, deciding what is the path of least resistance: • Loosen the requirements, issue a big, flashy warning, and maybe implement something to try to match the framerates (double frames/drop frames), but let the user be able to still use takes (sometimes you just can only use what you've got, no reshoots allowed) without having to resort to workarounds (ffmpeg, as I do as of now), and deal with the annoyance of people coming with bug reports/forum posts • Let things stay the way they are, and only let very minor discrepancies in, and make people who have a real big problem in their hands already (misconfigured footage) not coming their way.
Each approach has its pros and its cons, it really depends on what you consider the best outcome.
On the merger tool: I currently use a custom made bash script that divides videos already downloaded from the microSD cards in various folders (by take) and automatically concatenates what it needs using ffmpeg (converting to transport stream, btw) Your in-program tool requires a whole lot of clicking as it only makes files one by one. When we come back from production we have maybe some 300 files to be merged, not something you can do by hand - that's the whole purpose of using a computer, to automate stuff. I can share it with you if you want, if you don't mind the comments being in Italian ( : Just so you have an idea of what a true we-just-literally-shot-two-hundred-takes-with-four-different-cameras-and-we-have-four-terabytes-of-footage hell it would be without proper ingesting. Each click required can mean hours spent in front of the computer because it gets multiplied x10000 (not kidding).
I still have the issue with 2.5. Going to try Renan's Gopro method. Just letting you know, I dled the RC2 of 2.5 today and after merging Pixpro files, I have the framerate message.