Lossless MP4 clipping at keyframes doesn't work ~33% of the time.

Started by avidemuxguest2, November 28, 2016, 12:59:32 AM

Previous topic - Next topic

avidemuxguest2

Using simple and standard mp4 videos downloaded from Youtube, and jumping to keyframes (copy video/audio) then saving as mp4 results in corrupt files ~33% of the time (last 2 releases only). In previous versions this worked 100% of the time.

The video doesn't play and the first frame appears black in media players, and when re-opened in avidemux the first frame is also black and a '?' is seen in the frame type box.

Before saving I verified that the first frame was an I frame. Like I said this happens ~33% of the time, so choosing an earlier key/I frame usually works.

Edit: Lossless clipping at an earlier key/I frame, then opening the new file and clipping at the key/I frame that previously failed now works. So this is a tedious work around until there's a fix.

2nd Edit:

In answer to the questions...

1) I used 2.6.14, then 2.6.15, and the problem persisted, on Win7 64-bit (32 bit AviDemux).

2) I tried both containers (MP4 & MP4v2), plus it still happens with others (e.g. mkv).

3) I tried jumping to keyframes using both the buttons and up/down arrows.

4) A sample video is the 720p version of 'Melanie Martinez - Pacify Her (Official Video)' from Youtube, then jump to the fourth keyframe (previous 3 worked). Like I said, it only occurs ~33% of the time.

5) The 2.5 branch isn't plagued with this bug.

Jan Gruuthuse

Do you save with mp4 muxer? Try mp4v2 muxer or Reverse if other wise.

Quote from: avidemuxguest2 on November 28, 2016, 12:59:32 AM
>8 >8

Before saving I verified that the first frame was an I frame. Like I said this happens ~33% of the time, so choosing an earlier key/I frame usually works.

Edit: Lossless clipping at an earlier key/I frame, then opening the new file and clipping at the key/I frame that previously failed now works. So this is a tedious work around until there's a fix.

Keyframe is only selectable with up/down keyboard arrow key!
Quote from: mean on November 23, 2016, 07:30:35 AM
I frames are not necessarily IDR
i.e. navigation point

Quote from: avidemuxguest2 on November 28, 2016, 12:59:32 AM
>8 >8 (last 2 releases only) >8 >8
meaning 2.6.14 & 2.6.15?
In that case please switch to latest 2.6.15 from November 24th 2016 found @ http://www.avidemux.org/nightly?

If you are on ubuntu LTS 14.04.5 or 16.04 64-bit try:
   
- avidemux Cli/Qt5 2.6.15 64-bit deb download ubuntu 16.04.1 LTS
- avidemux Cli/Qt4 2.6.15 64-bit deb download ubuntu 14.04.5 LTS

If no solution, please report back and state used OS and used bit  (32-bit or 64-bit)

eumagga0x2a

Quote from: avidemuxguest2 on November 28, 2016, 12:59:32 AM
Using simple and standard mp4 videos downloaded from Youtube, and jumping to keyframes (copy video/audio) then saving as mp4 results in corrupt files ~33% of the time (last 2 releases only). In previous versions this worked 100% of the time.

The video doesn't play and the first frame appears black in media players, and when re-opened in avidemux the first frame is also black and a '?' is seen in the frame type box.

Can't reproduce. Please specify which particular YouTube-ID with which particular format code fails for you or provide a sample.

avidemuxguest2

#3
In answer to the questions...

1) I used 2.6.14, then 2.6.15, and the problem persisted, on Win7 64-bit (32 bit AviDemux).

2) I tried both containers (MP4 & MP4v2), plus it still happens with others (e.g. mkv).

3) I tried jumping to keyframes using both the buttons and up/down arrows.

4) A sample video is the 720p version of 'Melanie Martinez - Pacify Her (Official Video)' from Youtube, then jump to the fourth keyframe (previous 3 worked). Like I said, it only occurs ~33% of the time.

5) The 2.5 branch isn't plagued with this bug.

eumagga0x2a

Cutting from keyframes 3, 4, 5, 6 and 7 to the end of the video using the YT video with ID 9u14-QBPzSE and format 22, which has a pretty strange 1280x536 aspect ratio, works for me impeccably both on Linux and Windows 7 with Avidemux builds from the current git master, the resulting .mp4 videos can be played by Avidemux itself, mpv on Linux and Windows Media Player on Windows without any issues.

The Linux build is a 64 bit Avidemux, the windows one 32 bit, cross-compiled on Linux using MXE.

avidemuxguest2

Thanks for confirming eumagga0x2a. I too can go to the 4th to end and save successfully.

It only happens when you cut out the start to the 4th, then save. Can you confirm this?

It's the same file size and length, but one works and the other doesn't.

I can't avoid cutting things out because I'm retaining multiple segments.

eumagga0x2a

Now I can reproduce, thanks!

STR:


  • Navigate to the 5th keyframe (press UP 4 times)
  • Set marker B
  • Press Delete
  • Save the video in copy mode

What should be the first keyframe of the resulting video gets lost.

eumagga0x2a

Are you sure the problem exists with 2.6.14 as well? And with 2.6.13? There were big changes to the editor, the part of Avidemux responsible for deleting, copying, pasting, managing markers etc., but they all happend after the 2.6.14 release.

eumagga0x2a

You can workaround the issue for now by setting marker A to the first keyframe, not leave it at the default value of 0 (the first keyframe has a PTS > 0 in this video), i.e.


  • Load the video in question in Avidemux
  • Press Ctrl+PgUp (set marker A)
  • Go to the 5th keyframe (press UP 4x)
  • Press Ctrl+PgDown (set marker B)
  • Press Delete
  • Save the video in copy mode

The resulting video should be OK.

avidemuxguest2

Thanks eumagga0x2a, the workaround worked.

Also, it still happens with v2.6.14. I just tested it again with that version to verify.



avidemuxguest2

I'll try to narrow it in later, but so far it's after v2.6.5 (worked) and before v2.6.13 (didn't work).