Issues with cutting of h264

[framesurfer]

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!

[dosdan]

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

Code Select Expand

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.

[Jan Gruuthuse]

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

[dosdan]

Jan, that's not a problem.

Dan.

[dosdan]

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.

[Jan Gruuthuse]

was avidemux that dropped the last frames while viewing, while I muxed audio track into it.
Numbered Frames reloaded, 1st is gone
1st MPEG-4 (base media/v2)
2nd Matroska
3rd dash

[framesurfer]

Hi Dan,
thank you for the hint with AviSynth.
I almost expected someting like an existing solution to my testvideo approach 
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.

[Jan Gruuthuse]

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)

[Jan Gruuthuse]

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.

Code Select Expand

ffprobe 250-500.mp4

Code Select Expand

ffprobe 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

[eumagga0x2a]

What does it look like if you disable B-frames while generating the initial video out of an image sequence?

[framesurfer]

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  [/list]

[eumagga0x2a]

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.

[framesurfer]

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.

[Jan Gruuthuse]

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

[framesurfer]

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?