VideoHelp Forum
+ Reply to Thread
Results 1 to 9 of 9
Thread
  1. I tried this:

    Code:
    ffmpeg -i input.mpg -ss 00:00:39 -to 00:01:29 -c:v copy -c:a copy output.mp4
    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.

    Did the command produce a lossless copy of the desired excerpt?
    Quote Quote  
  2. 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.
    Quote Quote  
  3. Originally Posted by raywood View Post
    I tried this:

    Code:
    ffmpeg -i input.mpg -ss 00:00:39 -to 00:01:29 -c:v copy -c:a copy output.mp4
    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.

    Did the command produce a lossless copy of the desired excerpt?
    Note the: "-c:v copy -c:a copy". The existing video and audio were remuxed into a new container (MPG to MP4). The video and audio were not re-encoded and lost no quality. Some players can't handle some codecs in some containers -- so you might have problems with playback.

    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".

    Code:
    ffmpeg -loglevel error -stats -i input.mpg -ss 00:00:39 -to 00:01:29 -c:v copy -c:a copy output.mp4
    "-stats" assures it keeps printing progress statistics.
    Last edited by jagabo; 15th Jun 2021 at 22:38.
    Quote Quote  
  4. I did try replacing input.mpg with input.mp4, using this:

    Code:
    ffmpeg -i input.mpg input.mp4
    Running the command shown above on input.mp4 instead of input.mpg pretty much eliminated the error messages. There was a dramatic drop in file size: from 62MB for input.mpg to 16MB for input.mp4. But maybe that's normal: various sources say that MP4 is much more compact than MPG.

    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.
    Quote Quote  
  5. 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.
    Quote Quote  
  6. 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:

    Code:
    ffmpeg -loglevel error -stats -i input.mpg -c:v copy -c:a copy output.mp4
    As with the individual clip (above), adding -c:v copy -c:a copy produced an output.mp4 (i.e., the entire file) that was only 1.5% smaller than input.mpg -- due, I assume, to more efficient .mp4 encoding -- and MediaInfo reported the same pixel dimensions, bitrate and bitrate mode, and so forth.

    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:

    Code:
    ffmpeg -ss 00:01:22 -i input.mpg -to 00:02:06 -c:v copy -c:a copy output1.mp4
    Error messages included these (same as before, I think):
    track 1: codec frame size is not set
    Timestamps are unset in a packet for stream 0
    pts has no value [four copies of this one]
    Output1.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.
    Quote Quote  
  7. 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:

    Code:
    ffmpeg  -i input.mpg -ss 00:01:22 -to 00:02:06 -c:v copy -c:a copy output1.mp4
    Also, interframe codecs need to start segments with a keyframe. So with "-c:v copy" your trim may not start exactly where you specified but at a nearby keyframe. MPEG 2 typically has a keyframe every half second or so. And segments need to end on a keyframe or a p-frame. So they may not end on exactly the frame you requested either.

    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.
    Quote Quote  
  8. 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.
    Quote Quote  
  9. Originally Posted by raywood View Post
    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.
    Yes. "-c:v" is used to specify the video codec. "copy" means copy the compressed video from the input file to the output file (no decompression and recompression). If you wanted to recompress the video you would specify the codec there. For example "-c:v libx264" tells it to recompress the video with the 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.

    Originally Posted by raywood View Post
    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.
    Yes.

    Originally Posted by raywood View Post
    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.
    This is a peculiarity of the way ffmpeg works when no frame starts at exactly your mark-in point. For example, if you have a 29.97 (30000/1001) fps video and specify to remove the first 1.000 second you'll find that no frame starts at exactly 1.000 second. Frame 29 starts at 0.9676333 seconds, frame 30 at 1.001. Your cut-in point is in between the start times of those two frames. So the new video starts with frame 29 but it's display duration is only 0.001 seconds. Which equates to a frame rate 1000 fps for that frame. That keeps all the rest of the frames starting at exactly the right time relative to the cut-in point. A may get a similar fractional frame at the end of the clip. The end result is a variable frame rate video with the fist and last frames having different frame rates than the rest.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!