Hello...I have found virtually no information on the "start" property of a video or audio file, whether on stackexchange, the ffmepg site and documentation, or general web.
For those unaware of this property, if you use a header information tool, such as one from FFMpeg or a GUI front end such as Avanti, you can see that video and audio files, such as WEBM, MP4, M4A, etc, have a property called "start", along with other properties. Example:
Source Properties:This says the video is an MP4, 10 min and 25.15 seconds long and starts at 0.007s. A video player will play it essentially at time zero.
Input #0, mov, mp4, m4a, 3gp, 3g2, mj2, from 'D:/path-to-some-file.mp4':
Duration: 00:10:25.15, start: 0.007, bitrate: 312 kb/s ...blah blah blah
Sometimes, however, I get video files with a start property far from zero, such as 15.407000 (15 seconds). If I play such a file, it starts 15 seconds in from where I know it should start. If it was simply a case of file transfer corruption, for example, I'd understand. But a matching audio file (obtained via separate transfer) will have zero start, and the non-zero start property has me curious.
If I want to process the video with FFMpeg, e.g., and get the video from the source before the non-zero start time, which I know exists because I've seen it, I can't.
With an example start in the source video of 15.407000, and a start of 0.00 in a matching source audio file, I've tried these with ffmpeg:
1. Used -ss 0 for the input video file. Result: output video that started at the same frame as the source start property (15 seconds in from known, true video beginning).
2. Used -ss -15.407 for the video input. Result: non-operation by ffmpeg--did nothing and produced no output.
3. Used -ss 15.407 for the (matching) audio source file and no -ss option for the source video. Result: In the output, the audio is synchronized with the video, which starts at 15 seconds in from the known true start of what the source video should show.
(Note that processing just the video without combining it with audio makes no difference. The combo is just illustrative here.)
What is also obvious is that, when a video is processed with no -ss option, the output file is smaller than the source. This (as well as knowledge that the source video should start at zero) suggests that there is:
- either useful content in the video file and the start tag forces players (and ffmpeg) to skip it, or
- there is a single frame from the (ultimate) source repeated in the file I have for the duration until the start property time and then motion-video begins (in a player)
Aside from the apparently obvious, is there more to what the start property really means, and where does it come from? What is contained in the video file before the start property time? It's getting set by some video processors. So can it be worked with using ffmpeg (or some other tool) so that I can re-set the start to zero?
Many thanks to anyone who can share knowledge of this!
+ Reply to Thread
Results 1 to 7 of 7
I've also tried the -itsoffset option with FFMpeg on files with non-zero start property. Examples:
-itsoffset -15.4 -i "vid filepath" ...
Result: video starts ~15 sec in, compared to ultimate source video
-isoffset 15.4 -i "vid filepath" ...
Result: video shows first frame for ~15 secs, then starts motion
UhSomeone tried to cut video using -ss xxx option as input and editors such as ffmpeg will start the frame count at the cut point but throw that portion away. What you get is audio from cut point and frozen video until the next key frame. The correct way is to minimize this not zero start time is to use -ss as output option but at no closer than 2 frames before the key frame. This will give start time less than such as frame duration of say 0.033367 x 2 , like 0.06573. This is usually not discerblnible when playing. There is an algorithm and copies that might fix you problem but it is too long for my smart phone. I will post the process later when on my computer if you like. You dont happen to be able to post for actual test do you? Is it mp4 or mpg?
Hmmm... it seems I didn't save any logs from when I was trying the different combos of options. But they were all just -ss or whatever as an option before the input filespec.
But the algorithm for this phenomenon is:
1. Watch video in web browser on a video site (youtube, vimeo, etc).
2. Use your favorite cache extraction tool to "exume" the video (and its audio) from the browser cache and save it to disk, in 2 files (1 video + 1 audio).
3. Use FFMpeg or a frontend for it (e.g. Avanti) to try to mux the video+audio into a single "video". (Perhaps with a pre-process and then mux.)
During step 3, headers for files show audio starting at zero and video starting at 15 seconds, or 30 seconds, etc.
It seems to be a cache extraction artifact, because when the "original" video is viewed in the browser, it starts at time zero. (Though I'd believe it if you say it's from someone improperly using the -ss option.)
I've seen this happen with both VP9 inside of WEBM and AVC1 inside of MP4. I've seen "start" equal to anything from 16 to 319.91 !
I've read about -copyts and -start_at_zero, and also -seek_timestamp, in the man page, but the explanations aren't clear.
For example, -seek_timestamp (input) in man page says:
"If [this is] enabled, the argument to the -ss option is considered an actual timestamp, and is not offset by the start time of the file."Well, because timestamps are just data points stored in the file, the meaning of "actual timestamps" is relative, to me. By "actual", do the writers of the man page mean "relative to the start of the data in the file"?
That said, I've tried this in Avanti and it balks:
I've also tried this and it didn't work:
(I don't care what the timestamps are in the output, per the man pages for -copyts + -start_at_zero. What I want to do is get to timestamp 0 in the INPUT!)
That's why I started my post with the theoretical--was hoping to garner info about how ffmpeg can just override "start". Me am sad :,(
But hey, I'm happy if someone can explain the man pages!
Ok ... As anyone has learned FFmpeg is a great tool, used by many editors/converter/etc. The only thing is it has some quirks like not cutting at an I-Frame, even if you give it the correct time down to microseconds. For this reason, after much trial and error I use the following method to cut at I-Frame and get frame 0 pts = 0.000000.
I reference ffmpeg because it is widely used by many cutting/ editing software types. Using a 30 FPS, mp4, avc, 0.033333 Frame duration, with GOP (I-Frames) every 250 frames, You have a key frame at 0 and 0.033333 x 25 = @ 8.33325 seconds. If you try to cut at say 2.00000, and you use an -ss as input option, ffmpeg will seek to the Key frame 0 which is BEFORE the cut time since -ss xxx is BEFORE the -i input. Since it can't play from the non-keyframe, you will get some dead video time roughly 8 seconds long until the next Key frame occurs and it's PTS will be whatever time is is away from the cut point.
The method I have found that works for me (-copyts and -start_at_zero, and also -seek_timestamp does not for me without recoding), is cut at exactly 2 frames before the key frame you want to cut at. (or more also works up to a point) and use the -ss as an Output option after -i so ffmpeg will seek to the Key frame After the cut time. It will leave a little overhead for some reason I have yet to find searching the internet.
The following example is a downloaded video starting at time 0.022969 . I find 2/3 of that and use -ss as input option, since ffmpeg cannot seek to a key frame BEFORE because there is only 0.022969 before the key frame and it is not an I-frame.
Refer to the frame 0 time in the images below and frame 50 image with the little black square just entering into the circle. It stays the same but the Start time gradually gets to 0
[Attachment 49257 - Click to enlarge]
0.022969 x 2 / 3 = 0.015312
ffmpeg -ss 0.015312 -i "C:\Users\Bud\Desktop\oh Im Pregnant.mp4" -c copy output1.mp4
[Attachment 49258 - Click to enlarge]
add 0.007012 + Original offset (2/3 of 0.022969 = 0.015312) = 0.022343
run ffmpeg again same as before but with the new time
ffmpeg -ss 0.022343 -i "C:\Users\Bud\Desktop\oh Im Pregnant.mp4" -c copy output1.mp4
Result is frame 0 time of 0.000000
[Attachment 49259 - Click to enlarge]
It's cpnvoluted but work for most MP4's that use AVC 264 codec. Other codec require other algorythms.
I think we may be talking past each other a bit. I'm not sure. So allow me to re-phrase, if you'll entertain my questions.
The 2nd & 3rd paragraphs of your post talk about what happens when cuts are attempted in between key frames. I'm familiar with the problems of this but appreciate the explanation of the -ss option for this. However, I'm not sure that applies to my question, or if you intended for it to apply to your resolution method, or if you were just explaining the concept. I'm not trying to edit video by starting in the middle--I want to get the video from time zero, which an apparent bug has skipped by changing the start time.
Anyway, you then explain your resolution method, which I have a question about...
In paragraph 2, you state your example has key frames at 0 and 0.033333 x 25 = @ 8.33325 seconds. Now, in your resolution example, you state that "ffmpeg cannot seek to a key frame BEFORE [0.022969] because there is only 0.022969 before the key frame and it is not an I-frame".
Q1: Because frame lengths in your resolution example are 0.04, isn't there NOTHING before 0.022969, given that 0.022969 is the time-location of frame 0? Or is there a junk, partial P-frame, or something else?
Now, about our talking past each other... I'm curious about the answer to my original question(s).
Q2: What is the start time, exactly? I've found discussion of start time in descriptions of various atoms/boxes, such as the Edit List box or Movie Header box, on web pages about Quicktime and MP4 format. Many different start times are used to stitch together parts of a track. But why would start time ever be anything but zero for a whole track (excepting small non-zero values to help with syncing audio/video)? I've not found an explanation. And Webm/VP9 structure is entirely different. So internals specific to a particular container/CODEC may not provide a general answer.
Q3: IF a "start" time is significantly away from zero (e.g. 15 seconds), what is in the video track before that start time? Is there always a key frame at 0, making the video from zero to 15s usable but "hidden", or something else? (I'm assuming here that the video hasn't been badly edited with a key frame chopped off the beginning.)
Perhaps FFMpeg can read overall start time but not change it. I would think that strange given all the options like -seektimestamp and -start_at_zero. It's just frustrating to be handling 100MB video files that are unusable because there's a "start" time of 15s in there that can't be changed to zero (assuming that 0 to 15s is good video).
First let me explain the following information is mainly from FFMPEG as the cutting utility since it is used by so many other editors. FFMPEG is great! but it has many quirks, the main one being it will not recognize a key frame even if you seek to it with 6 places precision. I have never been able to get the No_Accurate_Seek, Start_at_zero or any of the other filters to work without re-encoding or messing up the video.
Also my findings, after much trial and error with automated scripts, work on MP4 and FLV so far. Not all Start times for all videos need to be 0 and some should not be. What you describe is what you get from a poorly cut (or transmitted) video. I have successfully acquired start times of 0.000000 by cutting 2 frames before I frames and, knowing there is almost always some over head, apply a function to achieve zero.
I'm sure there are many here that know more than I do, but this has worked for me and I have incorporated into the program i used as an example above. This works when I KNOW there will be a minimal non-zero start time after cutting. If you receive a non-zero video, it may be able to fixed, depending on why the start is not 0.000000, the container type, and other factors.
There may or may not be video during your blank portion and this is determined by the reported length, Using the example below, if I cut in the wrong place I get:
1.. A reported 20 second video that plays audio for 10 seconds (frozen screen) and correct video for 10 seconds.
2. A 10 second video starting in the wrong place.
3. An 10 second video with a start time of something less than 2 frames duration (Example 0.033333 frame duration yields start time of around 0.065983)
If you already have a video that is like one of the above, you will have to try several methods to correct it, depending on the container and the codec used to encode it.
Before everyone here finds fault with my explanation, I would like to point out that everyone knows you have to cut on a key frame or re-encode the portion up to the following key frame from your cut, but if you search high and low for a way to COPY portions of a video, none has worked to achieve a 0.000000 start pts until I for a way to fake it.
To answer the question of whether there is data before 16 seconds, all i know is many times ffprobe says frame 0 is a 'P' frame when that cannot be without displaying a distorted picture, so there must be more in front of it so there must be an 'I' frame before it somewhere?.
But why would start time ever be anything but zero for a whole track (excepting small non-zero values to help with syncing audio/video)? I've not found an explanation. And Webm/VP9 structure is entirely different. So internals specific to a particular container/CODEC may not provide a general answer.
Q3: IF a "start" time is significantly away from zero (e.g. 15 seconds), what is in the video track before that start time? Is there always a key frame at 0, making the video from zero to 15s usable but "hidden", or something else? (I'm assuming here that the video hasn't been badly edited with a key frame chopped off the beginning.)Code:
FFmpeg -ss 0.000000 -i video.mp4 -vcodec libx264 -acodec copy -crf 20 Test_Out.mp4
METHOD for MP4 and FLV (with original start time of 0.000000)
1. Cut 2 frames before Key frame you wish to cut at using -ss as Output option and -c copy. More may work up to a point. Less will never work. output such as output2.mp4
2. Obtain Start PTS Output2.mp4 ( @ 0.065983 or other)
3. Find 2/3 of this (0.048989 may be other.)
4. Use ffmpeg to cut the output2.mp4 using -ss as input option and -ccopy. obtain output3.mp4
5. Find Start PTS of Output3.mp4 (0.001001)
6. Add this to item 3 above (0.048989 + 0.001001 = 0.048990)
7. Repeat step 4. You will have a Output3.mp4 cut at exactly the key frame with Start PTS of 0.00000
Variations need to be applied if you already have a messed up video.
[Attachment 49336 - Click to enlarge]
Image above should say best to cut at Frame 248