August 12, 2020, 03:25:57 pm

News:

--


Can't crop/trim from exact point

Started by seriousgigi, June 02, 2017, 07:51:57 pm

Previous topic - Next topic

seriousgigi

June 02, 2017, 07:51:57 pm Last Edit: June 02, 2017, 07:56:15 pm by seriousgigi
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?

eumagga0x2a

June 02, 2017, 09:57:51 pm #1 Last Edit: June 02, 2017, 09:59:36 pm by eumagga0x2a
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.

seriousgigi

June 02, 2017, 11:05:22 pm #2 Last Edit: June 02, 2017, 11:07:13 pm by seriousgigi
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?

dosdan

June 02, 2017, 11:18:49 pm #3 Last Edit: June 02, 2017, 11:26:59 pm by dosdan
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.

eumagga0x2a

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 steps into action ;-)). The start point of every segment must be an intra (I-frame).

acritum

June 04, 2017, 05:33:15 am #5 Last Edit: June 04, 2017, 05:42:58 am by acritum
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 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.

eumagga0x2a

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

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 so it doesn't strike that often. We're at it currently.

topinrouen

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

eumagga0x2a

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.

eumagga0x2a

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.

topinrouen

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



eumagga0x2a

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.


topinrouen

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.

topinrouen

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 ?

eumagga0x2a

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.