Can't crop/trim from exact point

[topinrouen]

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 !!!

[Mantis]

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.

[Jan Gruuthuse]

>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

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

[seriousgigi]

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.

[eumagga0x2a]

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

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?

This limitation is pure maths, not a religion.

there'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.

[seriousgigi]

i see...
thanks.

[eumagga0x2a]

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 

[dosdan]

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.

[eumagga0x2a]

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.

[topinrouen]

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

[eumagga0x2a]

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.