I tried this:
It produced the desired output clip, but the process was slow and accompanied by many messages. MediaInfo says both input.mpg and output.mp4 are variable bitrate; it states that the bitrate for input.mpg is 5,995 kb/s whereas the bitrate for output.mp4 is 6,022 kb/s; both are 720x480; both are 29.97 fps; both use a lossy compression mode.Code:ffmpeg -i input.mpg -ss 00:00:39 -to 00:01:29 -c:v copy -c:a copy output.mp4
Did the command produce a lossless copy of the desired excerpt?
+ Reply to Thread
Results 1 to 9 of 9
No, it not only changed the container but also converted form one format to another: MPEG-2 to MPEG-4. For just cut without conversion you should use output.mpg.
Though for such a short video the remux should have been near instantaneous. Spitting out lots of warning messages can slow the process down. You might be able to get rid of the warning messages by adding "-fflags +genpts" before the input file. Or change the loglevel to only show errors: "-loglevel error -stats".
ffmpeg -loglevel error -stats -i input.mpg -ss 00:00:39 -to 00:01:29 -c:v copy -c:a copy output.mp4
Last edited by jagabo; 15th Jun 2021 at 22:38.
I did try replacing input.mpg with input.mp4, using this:
ffmpeg -i input.mpg input.mp4
During the process, I got a number of messages like this:
frame= 2873 fps=163 q=29 size= 3072kb time=00:00:24.51 bitrate=939.9kbit/s speed=5.44x
I timed it. The conversion from input.mpg (62MB) to input.mp4 (16MB) took 17 seconds. So that step, at least, was definitely not instantaneous.
I'm going to add that suggested loglevel stats language to the command.
Your new command line is reencoding the video and audio, reducing quality as well as the file size.
Your previous command line simply remuxed the video and audio. There would be little difference in file size -- just the slight difference in container overhead. It's just like taking a cake out of one box and putting in another. The cake hasn't changed. It still tastes the same.
MPG and MP4 are containers. Containers don't determine the quality of what's inside them. The codecs and codec settings determine that. Any time you re-encode with a lossy codec you will get a reduction of quality. Of course, if your goal is to reduce the file size you will have to accept some loss of quality. That loss may be anywhere between imperceptible and horrendous.
I tried -loglevel error -stats but concluded that, at least for now, I like it better with the additional information.
Not to be slow, but just to make sure I had the idea, I tried again, using a modified form of the command shown above, this time to copy the whole file:
ffmpeg -loglevel error -stats -i input.mpg -c:v copy -c:a copy output.mp4
So it seemed that, for individual clips or for the video as a whole, the -c:v copy -c:a copy language was essential, or at least provided one valid option, to produce lossless output.
Then I tried this, with a different input video:
ffmpeg -ss 00:01:22 -i input.mpg -to 00:02:06 -c:v copy -c:a copy output1.mp4
track 1: codec frame size is not setOutput1.mp4 had duration of 2:06. Apparently input seeking alters the alleged functionality of -to? It seems that -to functions like -t in this context.
Timestamps are unset in a packet for stream 0
pts has no value [four copies of this one]
Note that by putting "-ss 00:01:22" before the input file you are skipping the first 1 minute and 22 seconds of the source video -- and restarting the timestamps at 00:00:00. So your "-to 00:02:06" gives you a 2 minute and 6 second output video. If your intention was to start the segment at 1:22 of the source video and output from there to to 2:06, a 44 second segment, you should put the -ss after specifying the input:
ffmpeg -i input.mpg -ss 00:01:22 -to 00:02:06 -c:v copy -c:a copy output1.mp4
This is further complicated by the fact that MPEG encodings are often Open GOP with frames stored out-of-order. Even when a segment starts at a keyframe there may be b-frames from the previous GOP stored after that I frame. Those b-frames are supposed to be displayed before the keyframe and cannot be reconstructed without access to the previous GOP. Different players/editors will deal with that differently. Some will display junk for those leading b-frames. Some will display the keyframe in their place. Some will just skip over those b-frames and start with the keyframe.
I really appreciate the assistance, and your patience with my slow grasp of this material. I do check various sources -- and often come away befuddled.
For example, from somewhere I got the idea that reversing the order of -ss and -i would influence the question of whether the command did a simple copy or a re-encode. I think the answer must be that it's the copy language that determines that.
It seems you may be saying that FFmpeg will take as its starting point the first item in the command that gives it a particular place to look. So if I lead with -i input.mpg, then FFmpeg will begin its time calculations at the start of that file; but if I specify -ss 00:01:22 first, it will begin its time calculations at that point in whatever video I am about to name.
My plan is to use a video player to identify the starting point of each desired clip in input.mpg, with an accuracy of one second (because that's what the video player displays). I plan to export the full contents of input.mpg, in however many clips it contains -- so the starting point of clip B is automatically the ending point of clip A.
I expect to use a video editor (probably Adobe Premiere Elements) to stitch together the desired portions of the lossless output clips. So I don't mind if there's a little excess material at the start and end of each clip.
I plan to use Excel to generate the desired FFmpeg commands automatically, once I supply the starting point of each clip. To make sure I'm not losing any material due to what you were saying about keyframes, I was planning to set the Excel formula to include two seconds of material before and after the identified start and end times for each clip. I'd rather allow only one second if that will satisfy the technicalities of keyframes.
A trial run, extracting every clip from a short video, using your last suggested command as the template, produced the desired results in terms of clip duration. The combined size of the clips in KB was just a bit over that of input.mpg, consistent with the addition of four seconds to each clip. It did appear that I would want at least one second of buffer time before and after each clip; still not sure about two.
MediaInfo reported that the output clips tended to share the characteristics of input.mpg (e.g., 4kbps bitrate, 720x480). I found framerate puzzling. In input.mpg, MediaInfo said the rate was simply 29.970. It didn't say framerate was variable. But it did say that in the output videos. So their stated minimum and maximum framerates went as low as under 2 FPS and as high as 90 FPS. Not sure if that was a consequence of one of those error messages that drifted past. Not sure I should care, at least until I discover a specific problem.
x264 encoder. If you don't specify a codec ffmpeg will use a default which varies by output container. "-c:a copy" does the same for audio.