First of all please let me say a big thank you to the developers of Avidemux, it comprises all basic features you need for basic handling of videos!
I had some issues with cutting and created for testing purposes with ffmpeg a small h264 video out of 62 jpg images with a "1" on frame 1 and so on. The code was:
D:\Video\ffmpeg\ffmpeg -f image2 -framerate 24 -i pic%d.jpg -c:v libx264 -x264-params keyint=30 imageVideo.mp4
In fact the second iframe was on frame 26.
Then I saved a selection with "copy" mode from frame 1 (A) to frame 26 (B).
I expected to get frame 1 to 25 as it is described in the manual: "...the set of frames saved is [A,B).".
That is the first issue as it is usually not good to get the consecutive iframe in the saved snippet, since this is often the first frame of a changed scene.
What else is strange, is that the first frame starts with 0.083s and frames 25 and 26 are not shown in Avidemux, when the saved snippet is opened.
The answer might be given by the strange Presentation timestamps of the frames. In the following table some data gathered by ffprobe of the the last few frames is shown
| frame | 23 | 24 | 25 | 26 |
| key_frame | 0 | 0 | 0 | 1 |
| pkt_pts | 90001 | 93751 | 97501 | 93751 |
| pkt_pts_time | 1,000011 | 1,041678 | 1,083344 | 1,041678 |
| pkt_dts | 90001 | 93751 | N/A | N/A |
| pkt_dts_time | 1,000011 | 1,041678 | N/A | N/A |
| best_effort_timestamp | 90001 | 93751 | 97501 | 93751 |
| best_effort_timestamp_time | 1,000011 | 1,041678 | 1,083344 | 1,041678 |
| pkt_duration | 3750 | 3750 | 3750 | 3750 |
| pkt_duration_time | 0,041667 | 0,041667 | 0,041667 | 0,041667 |
| pkt_pos | 12520 | 13275 | 11738 | 13651 |
| pkt_size | 376 | 376 | 782 | 2513 |
| pict_type | B | B | P | I |
| coded_picture_number | 22 | 24 | 21 | 25 |
This could still come from the unexpected start value of frame 1 (0.083s).
In the next step I appended the snippet to itself by the following sequence:
D:\Video\ffmpeg\ffmpeg -i "cut1-26.mp4" -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts
D:\Video\ffmpeg\ffmpeg -i "cut1-26.mp4" -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate2.ts
D:\Video\ffmpeg\ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc out-conc.mp4
With this video I get the following strange moves, if I navigate with the arrow keys in Avidemux:
^ jumps to Iframe 26 at 1.042s as expected
< stays on it (does nothing, probably since frame 25 would be at a higher timer)
< jumps to frame 24 at 1.041s
> jumps to frame 25 at 1.083s
> jumps to frame 1 at 1.166s (first frame of second part)
The reason for this supposed to be the strange Presentation timestamps of the frames as mentioned earlier.
Any suggestions to the issues are welcome!
BTW, if you want to create a test sequence with sequential frame numbering, Avisynth loaded via VirtualDub is a pretty easy way to do this. You experiment until you get the character size that will suit your frame size. Here's the script I used to generate 3,600 Full HD numbered frames, 00000-03599, i.e. a 60.06s clip at 59.94fps. This was saved as an .AVI and as an .MP4.
FRAME_SEQUENCE.AVS
ShowFrameNumber(BlankClip(length=3600, width=1920, height=1080, fps=60, color=$000000),size=800)
It's interesting to load this sequence and cut it (e.g. the MP4 version has I-frames every 250 frames) to see how much you lose when cutting with ADM.
When I test, I usually set "A" to frame 250 and "B" to frame 500, so as to avoid any from-the-start anomalies.
Here's the 3,600 frame MP4 test sequence (7MB):
https://dl.dropboxusercontent.com/s/glu03zfq45qdjnw/Sequence.mp4
Dan.
Dan
I uploaded your created sequence onto avidemux demo tube, If you don't mind. Otherwise let me know if you don't want this.
your clip: Numbered Frames (https://www.youtube.com/watch?v=jEVewMQ4iu8)
Jan, that's not a problem.
Dan.
Jan, the length of the clip is 3,600 frames, 0-3599. The highest frame number shown online in YT may depend on the player. But if you download it (youtube-dl https://youtu.be/58w_f-sKI0o) and load it into Vdub, you'll see the correct length.
Normally, when I upload my action 1080p60 12-14Mbps uploads to YT, they come back much smaller, and the i-frames are every 304 frames.
This time the downloaded version is bigger. The video stream bitrate is 1,000kbps in the uploaded version and 2,454kbps, as well as a small audio stream, in the downloaded version. (I-frames have changed from every 250 to every 304.) Either I've reached a lower bitrate limit for YT's re-encoding of 1080p60 material, or the h.264 re-encoder is not properly handling compressing this "unusual" video content.
Dan.
was avidemux that dropped the last frames while viewing, while I muxed audio track into it.
Numbered Frames (https://www.youtube.com/watch?v=jEVewMQ4iu8) reloaded, 1st is gone
1st MPEG-4 (base media/v2)
2nd Matroska
3rd dash
Hi Dan,
thank you for the hint with AviSynth.
I almost expected someting like an existing solution to my testvideo approach ;D
I never worked with AviSynth, maybe I should test it.
If I save it from frame A=250 till B=500 I still get an I frame at the and and still the noncontinous pts_time at the end
...
4.133578
4.150244
4.166911
4.183578
4.166911
Any ideas? ???
Btw. I forgot to mention: I used Avidemux 2.6.18 Release on Windows.
switch to nightly: 32- or 64-bit matching your OS: http://www.avidemux.org/nightly/ (10 feb 2017)
You do know 2.6.x is not a frame editor! 2.6.x is time based editor. Editing points should be selected only with keyboard up/down arrow.
If the end of marked selection is not intended to add more video at the end, you could be more flexible selecting endpoint (left/right arrows)
avidemux player refuses to show the last frames (developers should perhaps have a look at this)
when you play the saved video marked (250-500) with vlc, all frames are there.
ffprobe 250-500.mp4ffprobe version 2.8.10-0ubuntu0.16.04.1 Copyright (c) 2007-2016 the FFmpeg developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '250-500.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42isom
creation_time : 2017-02-11 10:33:41
Duration: 00:00:04.18, start: 0.033333, bitrate: 1062 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 1054 kb/s, 60 fps, 60 tbr, 90k tbn, 120 tbc (default)
Metadata:
creation_time : 2017-02-11 10:33:41
encoder : JVT/AVC Coding
What does it look like if you disable B-frames while generating the initial video out of an image sequence?
Thank you for the suggestions so far.
Regarding the "time based editor", to be honest I never understood the real meaning of it, but in fact the video consists of frames and when I navigate with ^ key to the next Iframe (Avidemux confirms frame 26 is an Iframe) then I would expect to get frame 1-25 as result when saving!?!
That Avidemux refuses the last two frames, is most probably directly related to the messed up time stamps (see post #1 or post #6.
Changing to the latest nightly build did not alter anything.
Creating the intial video without B-Frames (see attachment) leads to the following changes
- start of first frame now on 0.000s (you directly see it, when you open the file w/o saving anything: the first frame is at 0.000s). Hence all frames of the saved snippet are shown and pkt_pts_time is in good order. No issues with concatenated video either.
- the last frame of saved snippet is still Iframe #26 :-[
For me it looks like Avidemux is confused about the presentation timestamp of the first frame in case, that B-frames are present, which is the regular case with h264 of course.
Plus the last frame of a selection is saved by accident, maybe no one found it troublesome expect me ;D[/list]
The last frame of a selection is saved not by accident but by design and this should be this way (you probably mix up the behaviour when cutting out and the one when saving). It may be a keyframe or a P-frame, but not a B-frame. "Time based" means frames are ordered by PTS and a B-frame from the first GOP with PTS > the PTS of the keyframe of the second GOP is AFAIK illegal by definition (early B-frame from the second GOP are possible though). Non-zero PTS of the first keyframe is entirely normal.
If I look at the manual, I have a different opinion about the expected design.
In http://www.avidemux.org/admWiki/doku.php?id=using:cutting it is written:
"Saving: You can save part of a stream by going to File→Save→Save Video. Every frame from marker A to marker B will be saved, excluding the frame at marker B. Mathematically speaking, the set of frames saved is [A,B)."
And it should that way: think of a save action from Iframe 250 to Iframe 500, where a new scene starts from fgrame 500 onwards. With [A,B] you will end up with a snippet, which has one sole frame from a new scene.
It gets even worde, if you save several of such snippets and append them to create a new video. Then you will get two consecutive Iframes and a flashing frame.
Of course you could avoid it, by shifting Marker B to frame 499. In fact Avidemux appears to look for the first PFrame upfront and cut there, which is a good decision. But I do not see the usecase of saveing [A,B] and the manual tells me [A,B) should be saved!?!
A non-zero PTS of first frame would be fine with me, but I think it is the reason for the distorted PTS at the end of the snippet (see post #1 for details). Here I've got after saving a non monotonic (rising then falling) PTS time:
pkt_pts_time ... 1,000011 1,041678 1,083344 1,041678
This makes no sense and leads to the mentioned strange behaviour during navigation.
Keep in mind the manual could be only related to avidemux 2.5.# branch (frame editor).
No longer supported nor developed:
https://sourceforge.net/projects/avidemux/files/avidemux/2.5.6/
https://sourceforge.net/projects/avidemux-mswin/files/?source=navbar
Did I get it right, the manual under http://www.avidemux.org/admWiki/doku.php?id=build:doctop is for 2.5 branch only? I am asking, because I cannot find any hint for that.
If so, is there a documentation for 2.6 branch existing?
You missed "could be" in my previous posting.
Development goes faster then documenting. Most documentation is from 2.4/2.5 Some parts are newe/updated/under review. On Bottom page of avidemux wiki you would find a Last modified date, this would give you an idea on recent or not
This is a slow process and has lesser priority. There is a great time deficit on the development side (Huge time shortage).
This is my understanding as user of the whole process.
This is a voluntary affair, with most of the work coming from "mean". Coding is more intellectually stimulating than writing documentation, so it's understandable that the documentation for most small projects is way behind.
Some users, although not good at coding, are OK at describing how to perform specific tasks, and contribute a tutorial. Sometimes this helps to fill in the information void.
But the main documentation is usually stale. For example, look at the user manual for the RawTherapee project
Dan.
Please don't get me wrong, I really see and appreciate the huge effort behind this how you call it "small project"!!
I still try to figure out, which reason / usecases could have been led to the design change from [A,B) to [A,B] during saving.
I could think of if B is at the end of the video, you would like to save until the last frame, maybe there are other of such usecases (?).
In the case you save snippets of a video in copy mode at keyframes, I would rather prefer the old design.
Maybe there should be a differentiation between last frame is an Iframe or not.
What do others think of the best design?
Some frames could be orphans
i.e. they depend on frames that are showing later and have been cut out, as a result they are dropped as impossible to decode without their non existing reference
Hello mean,
yes thats clear and I tried out with my initial experiment how Avidemus copes with it and it does well.
In case the selection is IBBBPBBBPBB the saved GOB is IBBBPBBBP to avoid orphans.
In case the selection is IBBBPBBBPBBBPI (which I saw as quite common) IBBBPBBBPBBBP would be a good decision to save.
In case the selection is IBBBPBBBPBBBI just avoiding the last IFrame would lead to orphans, but IBBBPBBBP (ommitting the succedding BFrames) would be the best compromiose in my opinion.
I read a lot about referencing over severeal frames and even Iframes, what could of course still lead to artefacts, but here I am missing the detailed know how.
One solution could be to make the behaviour configurable(?).
What do you think about the noncontinous pts_time at the end of a saved snippet nd the start pts_time greater than 0 in case BFrames are present (I even had a look in the source code, but couldn't figure it out so far, since I am not much used to C and never did C++ programming)?
The reorderding introduces a delay
If you video is IPBB, it will decode I & P but their PTS will be in the future as it must wait 3 frames to start outputting frames
i.e.
IPBB
xxxIBBP
Thanks a lot for information.
I will have to think about that.
Can you tell me in which source file and function this waiting procedure is performed?
Btw: Is the writing of the container performed by ADM directly or by a call of ffmpeg?
There is no wait, the PTS is computed depending on the use case
There is no call to ffmpeg, only calls to libavformat when appropriate