Hey, i used to your fan but started to use online cutters after realised avidemux is really bad at cutting or trimming (i don't know which word fits the situation).
The problem is like i said in the title, avidemux can't cut videos from exact point/frame/time whatever you say. if i can't crop the video from exact point what is the point of cutting?
So please fix this problem in your first update.
Sorry but i have to say this, making this mistake is so ridiculous how can you release a program without proper cutting feature?
You can start and end the cut at any point if your reencode video and thus lose quality (edit: maybe you don't know how to seek/navigate in Avidemux?).
You must start the cut at a keyframe and end it preferably at an I-frame or at least at a P-frame if you use the copy mode, preserving the quality.
This is a fundamental limitation of video compression.
holy shit, i feel so idiot. i always used mouse wheel (I frames) when editing and never used left and right keys on keyboard and i had no idea what I-P frames are. so proper cut can be made in p frames, did i understand right?
Quote from: eumagga0x2a on June 02, 2017, 09:57:51 PM
You can start and end the cut at any point if your reencode video and thus lose quality (edit: maybe you don't know how to seek/navigate in Avidemux?).
You must start the cut at a keyframe and end it preferably at an I-frame or at least at a P-frame if you use the copy mode, preserving the quality.
This is a fundamental limitation of video compression.
Yes, but as I understand it, some cutter/editors offer "smart copy" where only the affected region near the cut is re-encoded, and the rest of the clip is copied. (Assuming, of course, that there is no resizing or filtering/effects applied.) The best of both worlds...
Worst AVC files to cut must be downloads from YouTube. 60fps AVC stuff I upload with I-frames usually every 30 frames (every 0.5s), and then later d/l, have been re-encoded to now have an I-frame every 304 frames (I-frame every 5s), as well as now having a bit-rate about half that of what I uploaded.
Dan.
Quote from: seriousgigi on June 02, 2017, 11:05:22 PM
so proper cut can be made in p frames, did i understand right?
No, I-frames. The
end point of every segment (if you save from A to B, then B; if you delete from A to B, then A)
may be a P-frame (in most cases this will work), but with I-frames you are on safe ground (unless a bug in software (http://avidemux.org/smif/index.php/topic,17778.0.html) steps into action ;-)). The
start point of every segment
must be an intra (I-frame).
Quote from: eumagga0x2a on June 03, 2017, 08:19:59 AM
No, I-frames. The end point of every segment (if you save from A to B, then B; if you delete from A to B, then A) may be a P-frame (in most cases this will work), but with I-frames you are on safe ground (unless a bug in software (http://avidemux.org/smif/index.php/topic,17778.0.html) steps into action ;-)). The start point of every segment must be an intra (I-frame).
Here's a strange story. A couple of days ago I converted many videos of my bike trips in Avidemux into MP4, H264, rate factor 29, "super fast" preset. Then I decided to divide these videos into sections and I found a strange thing. In most cases, if I move the marker with UP/DN keys to I-frames, the cropping is made correctly, but in one case it was made wrong. First I thought I made some mistake with the selection and tried again, but got the same result. The saved selection lacked the initial I-frame (that was "kind of" selected in Avidemux). MPC-HC didn't want to open the resulting file saying it was corrupted and some players allowed to play it showing the corruption from the beginning to the second I-frame. This is why I decided that the first I-frame was not saved. I thought it was a bug in 2.7 and installed 2.6, repeated exactly the same selection and got the same result. Finally I gave up and moved the marker to the previous I-frame and the selection was saved without corruption from the first try. I have no idea why that happened exactly in that place, but it's not the first time when I notice this problem. It seems there are rare faulty I-frames that make Avidemux go mad. I've cut many files that day without such problems and saw this problem only once in one I-frame, but it could be repeated as many times as I tried. I don't know what was wrong with it because it was an ordinary I-frame somewhere in the middle of the video and the source video was generated by Avidemux and could be played with MPC-HC without corruption. But if anyone else had such a problem, it's interesting if it's a bug in Avidemux selection routines or in the codec or what. Unfortunately, I already deleted the file that could be used for testing.
Quote from: acritum on June 04, 2017, 05:33:15 AM
A couple of days ago I converted many videos of my bike trips in Avidemux into MP4, H264, rate factor 29, "super fast" preset. Then I decided to divide these videos into sections and I found a strange thing. In most cases, if I move the marker with UP/DN keys to I-frames, the cropping is made correctly, but in one case it was made wrong. [...] The saved selection lacked the initial I-frame
Please look here: Losing the keyframe at the end of a cut in copy mode (http://avidemux.org/smif/index.php/topic,17778.0.html)
This is an old, known bug, which is finally mostly understood (hurray!) and partially fixed by [editor] In copy mode, be more tolerant to timing error, allow 0.3 rather than 0.1 , that helps with dropped keyframes (https://github.com/mean00/avidemux2/commit/74c7dd312997a4e349d6998344317b05a52d2237) so it doesn't strike that often. We're at it currently.
Quote from: eumagga0x2a on June 04, 2017, 08:46:37 AM
This is an old, known bug, which is finally mostly understood (hurray!) and partially fixed by [editor] In copy mode, be more tolerant to timing error, allow 0.3 rather than 0.1 , that helps with dropped keyframes (https://github.com/mean00/avidemux2/commit/74c7dd312997a4e349d6998344317b05a52d2237) so it doesn't strike that often. We're at it currently.
AvideMux is a great software, but I also experienced some troubles when dealing whit cutting issues.
I cut on I Frames both at beginning (A) and at the end (B) without reencoding and save in a mkv file (cut.mkv).
When I open this cut.mkv with Avidemux to check, the final frames are sometimes dropped and the timing indication are
questionning. The file doen't begin et 0:0:00.00 and it seems longer (the end is not reachable).
I don't know how to fix it and I don't understand what is said below "be more tolerant to timing error, allow 0.3 rather than 0.1 ". How to be more tolerant ? What does it mean ?
Thanks for any help. I Think this is a very common issue
The presentation timestamp (pts) of the first frame must be greater than zero if the video contains B-frames. Videos consisting only of I- and P-frames usually start at zero or with a very small delay (decoding timestamps (dts) may not become negative).
Dropped last B-frames may actually belong to the next GOP (this is so called open GOP) and can't be decoded without the next intra. They must be dropped.
Total duration exceeding the pts of the last frame is basically necessary when appending another video (though it doesn't work smoothly ATM).
For more in-depth analysis of a particular case: please provide a sample with steps to reproduce.
Quote from: topinrouen on June 22, 2017, 10:45:39 AM
I don't understand what is said below "be more tolerant to timing error, allow 0.3 rather than 0.1 ". How to be more tolerant ? What does it mean ?
When saving a video in copy mode, Avidemux checks whether decoding timestamps of video frames follow in the right order and at proper intervals (if the check fails, the offending video frame gets dropped, resulting in grave video corruption). The code change made this check less strict, increasing the margin of error from 1/10 of the frame increment to 3/10.
Quote from: eumagga0x2a on June 22, 2017, 11:47:18 AM
For more in-depth analysis of a particular case: please provide a sample with steps to reproduce.
Hello
as requested, I ve provided a sample of what I am trying to do and what doesn't work like I would like.
The sample is a TSfile available here: https://mon-partage.fr/f/lMTioCcX/
Its name is test.ts
When opened with avidemux2.6, the file begin with a I-Frame at time 0:00.00.400
I would like to cut just after a P-Frame (scene changement) located at time 0:00.03.440.
So I put a label [A] at time 0:00.00.400 (on the I-Frame) and a label
at time 0:00.03.480 ( the B-Frame just afer the P-Frame). I just want to copy (with reencoding) and save the file as a mkv.
The result is a mkv file available here: https://mon-partage.fr/f/BSzm0ERX/
Its name is cut1.mkv
When opened with avidemux2.6, the file begin with a I-Frame at time 0:00.01.020
The last frame is a B-Frame located at time 0:00.03.460.
So the cut file is shorter than expected (2s440 instead of 3s040). 0.6s have been dropped (15 frames less at the end).
Thank you for the sample.
Quote from: topinrouen on June 23, 2017, 10:21:27 AM
So I put a label [A] at time 0:00.00.400 (on the I-Frame) and a label [noparse][/noparse] at time 0:00.03.480 ( the B-Frame just afer the P-Frame). I just want to copy (with reencoding) and save the file as a mkv.
With reencoding: works for me, frame-perfect.
Without reencoding, there are issues like "go to the last frame" command failing and the initial delay growing with each saving in copy mode, both issues maybe related.
I made a typo. I meant without reencoding and not with reencoding !
The point is that if I reencode, I want to make it on a small part, so I would have to make a cut before and the problem
would be the same.
Hello
You mentionned in your last post, that when you reencode, there is no problem and the end point is where it should be.
As I said, I don't want to reencode the whole video, as it's not efficient, time consuming.
Do you know if it'spossible to make avidemux copy the main part of the video and only reencode the final part in order to close the video on the end point that is wanted (with a new computed P or I frame for instance in order to close the last GOP) ?
In that way, the main part would be H264 and the last part would be x264. Is it possible ?
No, unfortunately, this is impossible. There are still some deep unsolved issues in editor affecting copy mode and merging.
H264 is the codec, x264 is the encoder.
Hello
I am always looking for a solution for this problem of cropping AVC files (TS with H264 encoding) without reencoding.
I've seen this topic: http://avidemux.org/smif/index.php/topic,16147.0.html
It is mentionned that AviDemux2.5 is based on frames (whereas 2.6 is base on time). It is also expected to be more easily to cut at
the right frame with this older version.
So I have installed 2.5.6 and loaded a TS file. The trouble is that the type of frame is not the same than when i use 2.6.20.
I have compared same position in the movie e.g just after a change of scene.
Moreover, there are no more I frames according to 2.5.6 !!!
Forgive me, but I find a lot of this jargon about different frame types quite confusing. I thought this program was the solution to all my trimming problems! It seems to work great except the accuracy of the cuts. Sometimes videos were off the points where I set A or B markers by a second or more. I've since tried other software but I've experienced nothing but headaches, so here I am trying to properly investigate the problems.
From what you've said, it seems I-frames are the only kind that guarantee accuracy. The problem is that when I navigate these I-frames using up/down keys, each "frame" is a few seconds apart. Of course, this is too imprecise for a lot of trimming. I guess "P-frames" are just standard frames, right? I always used the I-frame up/down keys to get to the point I want and pinpoint it precisely with left/right keys, then place my A/B markers. But as explained, the result is way off. Do you have any suggestions? Thanks.
Oh, and I'm using 2.6.21, running Windows 10 x64 and working with MKV files, but I've tried converting to other formats to see if the problem persists which didn't make a difference. I also make sure to select the relevant output format before exporting. The videos I'm editing use h.264 codec.
Edit: Seeing topinrouen's post I'm going to give 2.5.6 a try and I'll get back to you on this.
Edit 2: Crashed when I tried with the MKV, crashed mid-editing with a converted MP4 (with MP4 codec)... :/
Edit 3: Okay, back to 2.6.21 and I can get what I need with re-encoding. That isn't exactly the result I was looking for, but with all other trimming software I have to re-encode anyway so I'm okay with this. As a side note, basic audio filters would be awesome. I've not really needed it so far but audio fade in/fade out would be nice since this often accompanies video fades.
Quote from: Mantis on July 07, 2017, 09:24:57 PM
>8 >8 Edit 3: As a side note, basic audio filters would be awesome. I've not really needed it so far but audio fade in/fade out would be nice since this often accompanies video fades.
When the video is fully edited, you could import the audio track(s) into audacity. (drag and drop video on to it)
And do the required audio editing in audacity.
Save the required audio track and bring the audio track back into avidemux with Menu: Audio: Select Track: [Track 0 ....] -> [.... add audio track]
This can be done in avidemux copy mode (video & audio)
http://www.audacityteam.org/
ps.: windows require additional: Optional Downloads: Plug-ins and Libraries
QuoteFFmpeg import/export library ââ,¬â€œ Allows Audacity to import and export many additional audio formats such as AC3, AMR(NB), M4A and WMA, and to import audio from video files.
hi me again, so you say there is no way to crop a part of video starting with p or b frames right? but this is so ridiculous, and i don't believe there is no way to do it maybe avidemux can't do it but why? isn't it too stupid? what developers say about this? like i said there're online croppers and they do it so why avidemux can't do it? this quesitons are for the developers.
Quote from: seriousgigi on July 10, 2017, 12:30:31 AM
so you say there is no way to crop a part of video starting with p or b frames right?
Again, you can crop anywhere
if you reencode. In copy mode, which is the only way to preserve quality with lossy codecs like mpeg2, mpeg4, h264, h265 etc., the cut
must start on an I-frame (on an IDR frame, this is what Avidemux shows as an I-frame).
Quotebut this is so ridiculous, and i don't believe there is no way to do it maybe avidemux can't do it but why?
This limitation is pure maths, not a religion.
Quotethere're online croppers and they do it so why avidemux can't do it? this quesitons are for the developers.
They can't without reencoding.
i see...
thanks.
With "the cut must start on an I-frame" I meant "all segments must start on an I-frame" (if you save video from A to B, the single segment starts at marker A; if you delete from A to B and save the remaining video, the second segment starts at marker B), of course :-[
Quote from: eumagga0x2a on July 10, 2017, 07:17:46 PM
With "the cut must start on an I-frame" I meant "all segments must start on an I-frame" (if you save video from A to B, the single segment starts at marker A; if you delete from A to B and save the remaining video, the second segment starts at marker B), of course :-[
What you didn't mention was what needs to be at the end of the segment ("B") when trimming. As I understand it, the segment has to end with (
and keep after trimming) a key-frame/I-frame/IDR-frame as a b-frame, close to the end of the segment, would be looking forward to this key-frame for info.
Dan.
I'm not sure. I'm trying to understand at the code level how Avidemux handles references in copy mode. It is obvious that any missing refs would cause artifacts. On the other hand, the final P- or I-frame precedes the last B-frames in the stream, so even if the video doesn't show such a closing frame (PTS > video duration), the data necessary to decode the last B-frames should be actually there.
Hi all
I am always trying to understand the best way to cut H264 files without reencoding (audio/video stream copy) with AviDemux.
I think that a key point is to find how the GOP is defined (sequence of I, P, B frames). For that I ve used ffprobe (provided with
ffmpeg package). It gave me relevant informations which are coherent with what AviDemux says, but some questions remain
about the way AviDemux cuts. Below I give more details about what I ve done and what I don't understand.
My intention is to keep the beginning of a movie file (the last part has corrupted data) an to join it later with another file (of the same movie) for which it is the beginning that is corrupted. So to make this as nice possible I would like to cut as close as possible to a scene change and I would like to be able to append something to this cutted file.
To investigate, I work on a short part of the original file, named "all.ts". In a Dos Command windows, I have typed the following command: " ffprobe -select_streams v:0 -show_frames all.ts > all.frames "
all.frames is thus a text file with informations about frames: There are 834 frames, the first frame is I type. The frames are ordered according to the presentation time stamp (pkt_pts_time); for the sake of simplicity, I call each frame by its order, frame 1, frame 2.. frame 834.
There is also a parameter named "coded_picture_number", which is not at same order than the order of the frame; I suspect this is the order the frame are decoded before they are shown and it should give some ideas of the dependances between them (I have to investigate more on that point).
I've found a strong scene change with a new scene beginning at frame 347 ( by using AviDemux and checking with DGAVDEc+VirtualDub which allow me to find the time of it and the frame number of this scene change). The sequence of frame around is the following (informations obtained from ffprobe):
Frame 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349
Type I B B B B B B B P B B P B B I
Frame 347 corresponds to time 00:00:14.200 in Avidemux. Frame 1 corresponds to time 00:00:00.400. Besides, the frame types given by AviDemux are strictly identical to that given by ffprobe. Another noticeable thing is the fact that the scene change (frame 347) begins with a B-type Frame, whereas I expected that a new scene would begin with an I-Frame!
To make the cut, I put a [A] label at time 00:00:00.400 (coresponding to frame 1) and a label at time 00:00:14.200 (corresponding to frame 347) and save it (copy mode ) in a file named "cut1.ts".
I hoped a file with 346 frames, as frame 346 is a P-Frame. When analysing cut1.ts with ffprobe (" ffprobe -select_streams v:0 -show_frames cut1.ts > cut1.frames ") I found 335 frames. The first one was the good one (I frame timing at 00:00:00.400 in AviDemux). The last one (335) is an I-Frame, corresponding to what expected (see the table above). This frame should correspond to a timing of 00:00:13.760, but, when loading cut1.ts in AviDemux, it was only be able to show frame up to time 00:00:13.560 and this frame is not reachable.
I made a second try, in which I put a label at time 00:00:13.800 (frame 336), so just after the I-frame 335 and save (copy mode ) in a file named "cut2.ts". The result was the same as for cut1.ts: 335 frames according to ffprobe, and when loading cut2.ts in AviDemux, it was only be able to show frame up to time 00:00:13.560.
From these trials, I have two points:
1) ending at P-frames seems to be not possible
2) ending at I-Frames seems not to work completely properly (whereas this I-Frame is an IDR one, labeled key picture according to ffprobe).
Do you have any idea about what happens ? I can put the files on share links.
Thanks a lot for any idea.
Yann
My first idea was the initial delay incorrectly growing while the total duration remaining the same, thus frames at the end "falling off the cliff". Didn't have time to look deeper into the issue though. This doesn't happen with all videos containing B-frames.