Reuben Martin
Forum Replies Created
-
Where then is the audio getting re-sampled to 44100? Embedded SDI audio is at 48k.
-
What is the source of the audio? I find it odd that the sample rate that ffmpeg is getting from the source is at 44100. That would suggest that the audio is not embedded in the camera video source. If that’s the case you may be suffering from clock drift due to separate audio / video devices running off of separate clocks.
-
I think you are erroneously conflating two different aspects of framerate manipulation. “Changing the framerate” implies that the video lasts the same amount of time, but the frames are interpolated to increase or decrease the number of frames played within the same timeframe. “Changing the playrate” implies that no frame interpolation is taking place and you end up with the same total framecount, but you play them back at a slower or faster rate.
Regardless of which one you are doing, it really doesn’t matter. If you specify the starting timecode for the timecode track that is all you need to do. There is no timecode conversion. It just sets the start time, and then whatever software is reading it just uses that as it’s starting point and counts up from there depending on the frame rate and frame base that is being used.
A timecode “track” is not something that labels the timecode of every frame. It’s just a single packet that says “here’s the time to start with, count up from here”. The only other time a timcode packet should show up is if the clock source that the recording device is jamming to suddenly jumps to a different time. Then a packets shows up in the timecode track that says “the time changed, start counting up from this new time”. The only time there would be need for a timecode packets at a regular interval is in a live chunked format.
You’re thinking of something similar to an LTC signal, and timecode in digital interchange formats does not work like that.
-
ffmpeg -r 3 -i image-%03d.png -vcodec copy -acodec copy out.mp4
-
The “timecode track” is simply a timestamp at the beginning of the file. Timecode is calculated from that point on. They only reason a timecode packet would show up anywhere besides the beginning of the file is if the timecode source was non-continuous.
If you simply specify the starttime for the timecode argument you should be fine.
-timecode hh:mm:ss:ff
-
There has been a ticket for this feature to be implemented for a while now. https://trac.ffmpeg.org/ticket/3707
-
Just guessing, but you might try actually muxing them to ts with ffmpeg and see what happens. There may be some extra functionality that takes place when the output is known to be ts that doesn’t happen when the output is raw stream files.
Another option to try is seeing what happens when setting the output from ffmpeg to mp4 instead of raw streams and then transmux them to ts with other tools. Bento4 and GPAC both have tools to directly transmux mp4 to ts.
https://github.com/axiomatic-systems/Bento4
https://github.com/gpac/gpac -
You might try to see if it works better in an mp4 container. I don’t know if that causes conflict in your workflow, but since you seem to indicate quicktime is being used I’ve found that it handles mp4 files easily enough.
The mp4 format is loosely based on mov, but it is an official standard, so it is documented quite extensively. mov format on the other hand is apple’s proprietary format, and while some documentation for it can be found, there are lots of things that are vague and open to interpretation, other things totally undocumented, and places where the implementation quirks diverge from the documentation.
It may not fix your problem, but if the content is being encoded to h264 + aac there’s no reason not to try it out.
-
I have never encountered this issue, but then again, I generally use the libfdk_aac encoder.
-
If it really is a mismatch between audio and video stream length, add “-shortest” to the command arguments which stops encoding once the end of the shortest stream is reached.