Video preview jumps forward when stop is pressed

[Alan Thew]

Hi everyone. I've been using Avidemux for a couple of years on Linux and Windows, and I think it's wonderful; but yesterday I encountered a very odd problem that I can't resolve. Currently I'm using Windows 10 64-bit.

Very simple to describe the problem: if I open a video and start to play it, and then stop it, when the video stops it jumps forward by about ten frames. This happens if you press SPACE or if you use the buttons.

The type of video doesn't seem to make any difference: replicated using an MPEG2 file in TS container (a digital satellite DVB stream) and x264 in MP4 (captured from analogue using FFMPEG). I've tried uninstalling and reinstalling versions 2.6.12, 2.6.13 and 2.6.14 (64-bit) and the behaviour is the same in all of them. I've tried rolling back and re-updating my video driver (Intel HD 4600). I've tried removing the few Windows updates it's possible to remove. Rebuilding the indexes makes no difference.

I hadn't used Avidemux for a couple of months until yesterday, but I used it every day for weeks a few months ago, and I'm sure this odd behaviour wasn't occurring back then. I wonder if the Windows Anniversary Update could have screwed something up?

Possibly related: the "Frame type" indicator under the preview video doesn't change when the video is playing; it only updates when the video is stopped. I'm sure this used to rapidly change while the video was actually playing. It definitely did in version 2.5. Also, the stop-jumping issue does not occur in version 2.5.

Is anyone else experiencing this, or able to replicate it, or able to offer any insight? Many thanks everyone.

Alan

[eumagga0x2a]

It has nothing to do with Windows, video drivers or even decoder. When stopping playback, Avidemux displays and gets the timestamp of the last decoded frame from the cache, which holds 8 frames, i.e. you see the video jumping max 8 frames ahead.

Avidemux is not a video player and playback is by no means a way to navigate with precision. I agree that this is not very polished, but compared with other problems this imperfection is a non-issue IMVHO.

Possibly related: the "Frame type" indicator under the preview video doesn't change when the video is playing

Why should it??

[Alan Thew]

Thanks eumagga, I appreciate the reply and technical insight.

It has nothing to do with Windows, video drivers or even decoder. When stopping playback, Avidemux displays and gets the timestamp of the last decoded frame from the cache, which holds 8 frames, i.e. you see the video jumping max 8 frames ahead.

What's the reason for doing that? Why not just freeze on the currently displayed frame? That's what version 2.5 did. It didn't jump when you pressed stop.

I agree that this is not very polished, but compared with other problems this imperfection is a non-issue IMVHO.

I'm not bothered by a lack of polish -- as I said, I think Avidemux is great. I just couldn't believe that I would not have noticed this behaviour a couple of months back, when I used Avidemux day after day after day. Especially since it hit me in the face straight away when I used it a couple of days ago after a gap of a few weeks. Therefore I assumed something had changed, causing it to go wrong at my end. So you're saying that everyone using version 2.6 on any platform is getting the jump, and I must have had it (but not noticed it) before?

Possibly related: the "Frame type" indicator under the preview video doesn't change when the video is playing

Why should it??

Just because it used to in v2.5, that's all. I've got no knowledge of what's going on in the code. I just thought the link might be helpful to someone diagnosing what had changed. I agree it's not especially useful to see Is, Bs and Ps whizzing in front of your eyes while the video is actually playing.

[eumagga0x2a]

When stopping playback, Avidemux displays and gets the timestamp of the last decoded frame from the cache, which holds 8 frames, i.e. you see the video jumping max 8 frames ahead.

What's the reason for doing that? Why not just freeze on the currently displayed frame? That's what version 2.5 did. It didn't jump when you pressed stop.

Stopping exactly at the currently displayed frame is not a problem, just leave out the call to admPreview::samePicture I linked above, the problem is to resume playing from that spot afterwards. The function admPreview::getCurrentPts doesn't return expected correct values when called before the exit of GUIPlayback::run e.g.

I'm quite new to Avidemux and even more so to coding (I was just an occasional user who needed a couple of show-stopper bugs fixed, so I started to contribute as a translator in return), both my knowledge of the Avidemux code and the ability to express my ideas in c++ are rather limited 

I can't refer to Avidemux 2.5, the legacy version is sort of a completely different application under the hood. I do know that it worked frame-based instead of time-based, which was incompatible with modern codecs.

So you're saying that everyone using version 2.6 on any platform is getting the jump, and I must have had it (but not noticed it) before?

Yes, even though I didn't pay attention to this behaviour earlier either. Even more, I was blissfully unaware that admPreview::samePicture doesn't do exactly what its name suggests. Thank you for raising the topic 

Possibly related: the "Frame type" indicator under the preview video doesn't change when the video is playing

Why should it??

Just because it used to in v2.5, that's all. I've got no knowledge of what's going on in the code. I just thought the link might be helpful to someone diagnosing what had changed. I agree it's not especially useful to see Is, Bs and Ps whizzing in front of your eyes while the video is actually playing.

Actually, the rendering of the navigation toolbar during playback consumes so much computational power that my dated PC turns out to be not powerful enough to play 720p videos in Avidemux with A/V in sync in some circumstances if it is not hidden, depending on Qt theme. I'm so glad that it doesn't try to further increase the load displaying frame type for each frame.

[Alan Thew]

Thanks eumagga, you've helped me enormously understanding the differences in the ways versions 2.5 (frame-based) and 2.6 (time-based) work. If I open an AVC mp4 SD video grab in v2.5, the frames are numbered from 0 into the thousands, and the time code starts from 00:00:00.000 and increases strictly in accordance with the fps (i.e. 40ms increments for PAL). If I open the same video in v2.6, there is no frame numbering displayed, and the time code starts from 00:00:00.120 (something to do with ffmpeg or the capture device, I guess); and though it mostly goes up in 40ms increments, as you'd expect, there is a place where it increases by 80ms, where two files were joined. I assume this explains why v2.5 complains on opening the file that sync may be lost.

I don't know, incidentally, why joining the two files (it was done in Avidemux 2.6.14, strictly on I-frames, using File>Append) caused this single frame gap in the time code sequence. But I guess that's another issue.

You're right about the processor-intensive nature of the preview. I'm only working with PAL SD (from VHS grabs and broadcast streams) and playback in v2.6 pushes my CPU usage to about 31%. Playback of the same file in v2.5 troubles it to about 6% max.

I used to be a developer, but not in C++. Wish I had time to poke around in the code, I'm sure it would be really interesting!

[eumagga0x2a]

If I open an AVC mp4 SD video grab in v2.5, the frames are numbered from 0 into the thousands, and the time code starts from 00:00:00.000 and increases strictly in accordance with the fps (i.e. 40ms increments for PAL). If I open the same video in v2.6, there is no frame numbering displayed, and the time code starts from 00:00:00.120 (something to do with ffmpeg or the capture device, I guess); and though it mostly goes up in 40ms increments, as you'd expect, there is a place where it increases by 80ms, where two files were joined. [...]

I don't know, incidentally, why joining the two files (it was done in Avidemux 2.6.14, strictly on I-frames, using File>Append) caused this single frame gap in the time code sequence. But I guess that's another issue.

Yes, this is a different issue related to the way Avidemux calculates video duration and to the fact that the PTS of the first frame may have legitimately a non-zero value. For now, I'd recommend to delete the last GOP or at least from the last P-frame to the first I-frame of the appended video manually (using a recent nightly could be helpful). I experimented with automatically creating a segment starting with the first I-frame when adding a reference video; this would result in videos always starting at zero and would eliminate the gap when appending. Unfortunately, this broke so many things (especially interlaced videos) that I gave up for now until I understand all the intricacies.

There was a related topic recently: http://avidemux.org/smif/index.php/topic,17266.0.html.

You're right about the processor-intensive nature of the preview.

You should compare CPU usage with navigation toolbar visible and with navigation toolbar hidden (Ctrl+Alt+N). This results in combined avidemux3_qt5 and Xorg CPU usage drop of approx. 30% on my system, highly depending on the FPS of the video.

[Alan Thew]

Thanks once again eumagga and sorry I've only just had time to reply. I think I may take a break from Avidemux and maybe try using it again a few versions down the line, as I'm having further problems, and I really need to have confidence in the compliance of the mp4 files I'm producing. Specifically, my hardware mp4 player (a Comag SL40HD digital satellite receiver) does not seem happy playing back mp4 files created in Avidemux, even when all I've done is chop off the beginning and end of an original x264/AAC mp4 file created in ffmpeg and copied the video and audio streams to a new file. Sometimes, playback just freezes for ten seconds, then recommences, having missed a chunk out. (There may also be a slight audio drift leading up to this point ... or I may be imagining it.) I've never seen this happen on the same hardware using mp4 files created directly in ffmpeg, or using mp4box; but it does happen sometimes viewing videos off my phone, which I know are also variable frame-rate mp4. Since, of course, for VHS and TV grabs, I don't want variable-framerate functionality, and ffmpeg and mp4box seem to produce compliant, absolute fixed-rate output, I think I'll stick with them for safety. Still, it's a pain having to do crops using the numerical timestamp on the command line, rather than in Avidemux's GUI.

Just to be clear, I haven't had time to do enough testing to be sure I'm not barking up entirely the wrong tree here, and if I do, I'll post back. So I'm not alleging any bugs or anything; but it does superficially look like my box doesn't like Avidemux output, and I'm guessing the time-stamp is something to do with the reason. If I find, for example, an mp4box-output file that also won't play properly, I'll know I must be mistaken about Avidemux introducing the problem.

[eumagga0x2a]

It would be immensly helpful if you provide test samples created with the latest Avidemux nightly build which your satellite receiver fails to play smoothly. Without such samples the chances are good that you'll have to resort to ffmpeg for cutting videos in copy mode even a couple releases later.

Do these "freezes" affect the sound too? If not, I'd interpret them as an I-frame failing to decode or missing completely. If they do affect audio, then the next question would be whether they happen always at the same spots in the video or randomly. If they happen reproducibly at the same spots, please note their timestamps, at least approximately.

The PTS gaps at the joint points have nothing to do with variable framerate, I've already explained how to clean up these locations.

[Alan Thew]

Eumagga, your commitment to helping others resolve their problems is amazing -- thank you!

Do these "freezes" affect the sound too? If not, I'd interpret them as an I-frame failing to decode or missing completely. If they do affect audio, then the next question would be whether they happen always at the same spots in the video or randomly. If they happen reproducibly at the same spots, please note their timestamps, at least approximately.

Yes, the freezes affect sound and vision: playback literally hangs for about ten seconds, then recommences after the missing chunk. As I type this, I realize ten seconds is about the length between I-frames on the video in question, but it's not at a point I've done any edits (there were none, apart from the lopping at the beginning and end).

The PTS gaps at the joint points have nothing to do with variable framerate, I've already explained how to clean up these locations.

There aren't any joint points in this video, and I'm assuming no PTS gaps because MediaInfo gives the frame rate as constant (not variable, min 12.5 fps, as it does when there's a time stamp skipped). I confused things by saying "also variable frame-rate", sorry.

I will try to dig into this more deeply, to provide a scenario to recreate the freezes and some samples, but it might be a while before I get some free time. If I could spend all my time messing around with video files life would be more interesting!

Off to do something far less interesting...

[mean]

It looks like a bad cut
I.e. an intra was dropped and the player is waiting for the next one to be able to decode