I am using Avidemux for postprocesing cuts at ffmpeg mp4 videos. But i have problem, that some keyframes are unusable for cutting. If I cut video at this dead keyframe, video is freezing (audio is going on) at least to the first usable(?) keyframe. it is very irreteable. I must forcely recut the video on another keyframe. :'(
You're saying plenty and not providing info at all?
Provide (upload) a small sample of video, give time index of this dead key frame. (10 seconds video duration would probably do)
- used avidemux? version, 32 or 64 bit, if nightly: revision (ryymmdd)?
- what should we understand with "ffmpeg mp4 videos"?
- ...
ps:- Use a free dropbox account, mega or similar webservice (free public access, without registration to download your uploaded video) thank you.[/quote]
Are you putting h.264 in MP4?
In H.264, the frame can be segmented into sequences of macroblocks called slices.
These slice sequences can be independently processed (multi threading!).
I wonder if these I/Idr frames are actually B frames with an Intra slice?
I also have encountered a problem which may be related. When cutting mp4 in copy mode to I frames, the video between the first I frame and second I frame appears as black video. It doesn't happen with every video (I may just have been lucky in selecting the position of a first cut) but it does happen repeatedly, if the same cut is repeated at the same place. If a different I frame is chosen, for the first cut, in the same video, the black frames may or may not be present. If I move the edit forward to the next I frame (were the video starts after the black frames) and make the first cut, no black frames occur.
The same thing often occurs when editing DVB-T in MKV mode.
v2.6.12 64bit is the first version this has occurred in my case, I didn't try v2.6.11.
The same edits using Machete are fine. I have tried playing the edited video in various players and the black video is present in all the players.
you have to cut first between I frames to create a smaller file , may be something of 5 mns from a 60 minutes one .
then you reuse this part and select the frames you want , then you recompile the video and you will be able to append it to others files you made like that : the files being recompiled again to create a movie .
beware of the audio ac3 codec . i have good result to recompile it in aac and some bugs with the ac3 .
the best is to compile in aac and at end to create an ac3 if you have some hardware decoding it , like a creative labs card
I have been doing something similar. Because I have Machete (I don't like using it because it is unresponsive) If my first cut gives the black frames, I simply move to the next I frame and start there. I then cut the short start section with Machete and append on to the main file with Avidemux.
Strange thing is, the problem only seems to happen on the first cut and not every I frame but I think, alternate I frames, depending on which is chosen as the first cut. Every other cut in the file is fine.
It is interesting that you seem to suspect the audio may be causing a problem, I have be using copy for audio as I usually do. I will try re encoding the audio to see if that has an effect.
I have gone back to v2.6.10, the last version I've used and the problem is gone.
If you had a reproducible test case, that would help
(including files)
The files are nothing unusual, just some mp4 files and DVB-T HD files of the type I have been editing in copy mode for quite a few years. I have just started noticing the problem after installing v2.6.12. I didn't try v2.6.11. It may well be at my end if no one else is seeing the problem.
Thanks for the great work on this software by the way, I have got a lot of use out of it over the years.
After a few weeks using v2.6.10, I decided to give v2.6.12 another try. When I un installed v2.6.10 I noticed that the v2.6.10 files were still in the Avidemux folder so I deleted them before installing v2.612. After about 2 weeks there has been no problem with black frames at the start of edited video files.
EDIT. False alarm, I am still seeing the black frames issue at the start of some edits.
Is this problem solved? It is very frustrating... :(
Did you provide a test case ?
Quote from: mean on July 23, 2016, 08:57:13 AM
Did you provide a test case ?
http://files.uloziste.com/2d3920436f039e9b/test.mp4
00:01:02.920 - good I-frame
00:01:03.960 - dead I-frame
00:01:11.400 - dead I-frameThe test case was created on Windows 10 64bit by-
ffmpeg.exe -i "%%a" -vf "scale=0:400" -sws_flags lanczos -c:v libx264 -aspect "16:9" -preset slower -crf 23 -c:a aac -b:a 64k -ss "01:00" "%%~na.mp4"
ffmpeg version N-81118-gfb91850 gcc 5.4.0 zeranoe.com
does not seem to be easy to reproduce, might have been fixed
Can you try with a nightly ?
(http://www.avidemux.org/nightly)
Quote from: mean on July 30, 2016, 07:50:33 PM
does not seem to be easy to reproduce, might have been fixed
Can you try with a nightly ?
(http://www.avidemux.org/nightly)
It seems that the problem is solved
Problem is still here. >:(
What build are you referring to?
Actually on reflection, I have been seeing the dead 'key frame' in edits using Avidemux 2.6.12 (standard release) but only when editing DVB-T HD in copy mode. Some edits produce a freeze at an edit point and some don't. On playback, after the freeze in the video, the playback continues when the play head reaches the next key frame. If I move the play head back to just behind where the freeze occurs but before the next key frame, playback continues immediately, in frames that were frozen in continuous playback. I would assume this is related to problem I have mentioned earlier in this thread, about black frames at the first edit in mp4's in copy mode. I will try the nightly build to see whether this still occurs and if so, will look into posting a sample. The video is just standard DVB-T HD video, captured by USB tuner, so there is nothing unusual about it and I'd be amazed if the developers haven't reproduced it.
Try a nightly
Quote from: fish on August 17, 2016, 02:56:03 PM
The video is just standard DVB-T HD video, captured by USB tuner, so there is nothing unusual about it and I'd be amazed if the developers haven't reproduced it.
This could be provider (the ones who provide the signal on air or the TV channel) related. Each of these can use other parameters, without access to original recorded video: hard to detect what is going on.
On the other side this could be related to the usb dongle: hardware or driver issue and the used hardware where the dongle sits on: PC, STB and their used OS's.
could this also be the "null frame" (kind of black screen transmitted)?
I have considered that the problem may be caused by inconsistent captured DVB-T HD files, although playback of the files before editing them did not show any issue. I have older versions of Avidemux on an external drive which I can try, to see if the problems are consistent on older versions. The problem only began after v2.6.10, so either the DVB-T HD's have changed to cause the issue or something in Avidemux has changed to cause the issue. The black frames after the first edit occurred with different mp4 files, not DVB-T HD files. I see an Avidemux v2.6.13 just been made available, so there's an excuse not to install an older version. Onwards and upwards.
This problem isnt typical only for captured stream. In ffmpeg reencoded videos is too.
Interesting is, that if you have a several consecutive dead keyframes - you can reopen avidemux-reencoded video (with dead keyframes at starting), and obviously the 2nd keyframe (which was not done previously satisfactorily cut) can be revitalised for cutting (before not).
It testifies to the fact that each keyframe is generally suitable for editing, just avidemux not correctly interpret it.
Yes, I have noticed that the frames, just after the cut, that no longer play in continuous playback, do seem to be ok because they play if the play head is moved to them. I have also noticed that either the 'Frame Type' indicator in Avidemux, is displaying I-frames as P-frames or keyframes in DVB-T HD can be I or P-frames. When next keyframe is selected, Avidemux quite often goes to, or indicates, that it is on a P-frame. This may be due to a feature of of TS files. There was one BBC HD capture I had of the Olympics I was editing, that had over 15 minutes of P and B-frames but no I-frames, at least according to the indicator in Avidemux.
There is a very useful utility called G-Spot for showing GOP information but it is quite old and the 'display GOP structure' feature only works for MPEG1 and 2 files. There may be a similar, more up to date utility, for MP4 files I must take a look.
http://www.free-codecs.com/gspot_download.htm
Look at the difference between I & IDR
I don't remember seeing IDR frames in DVB-T HD files. I see I-FRM, I-TFF, P-TFF, when moving through keyframes and B-TFF, P-TFF, as well as the other 3 when moving from frame to frame. I will keep a lookout for IDR frames.
For mpegTS, the alternate way is to have recovery time at 0, when that happens it is a IDR in disguise
I had a short DVB-T HD file recently that exhibited the freeze problem, so decided to chop it up, firstly into two parts. Part 1 from the beginning to the I-frame where the freeze occurs and part 2, from the I-frame where the freeze occurs to the end. Both parts played without any signs of a problem.
I also cut the file into 3 parts. Part 1 from the beginning to the I-frame where the freeze occurs, part 2, from the I-frame where the freeze occurs to the I-frame where play resumes in the original and part 3 from I-frame where play resumes in the original to the end. All parts played without any signs of a problem.
I then joined the two parts together and the three parts together and the two new files exhibited the same freeze problem as the original.
One thing I did notice when I reduced the playback rate in MPC, was a slight glitch a few frames before the I-frame where the freeze occurs. I guess these sort of .TS files are prone to these sort of tranmission glitches from time to time and the only way to repair them is to split the file or re-encode.
yes, errors in TS are pretty common
Depending on the type of error, it can be a problem for avidemux
A player will just skip and resume later
Avidemux is trying to seek accurately, and if it fails at finding the correct seek point/ decodable starting point, it will bail