Why does GUI_SeekByTime() rewind to the previous I-Frame?

Started by chubacca, December 17, 2016, 10:56:58 PM

Previous topic - Next topic

chubacca

Hi,

I'v been using Avidemux for over a year on several versions of Ubuntu (12.04, 14.04. and currently 16.04.). I use it mostly for frame acurate cutting of video material captured from TV. My video files are mostly MPEG-4.

At first, I used the GTK-version (I guess it was 2.5.? or something), as this was the version that came with Ubuntu by default. In this older version, I really liked the ability to step forward or backward through the video file in steps of 1,2 or 4 seconds using the keyboard shortcuts <Shift>/<Ctrl>/<Shift>+<Ctrl> - <Left>/<Right>.

I have switched to 2.6.15, Qt, and now these shortcuts don't work anymore. When I load a video file and set the current timestamp to  e.g. 00:00:10,000 (10 seconds after start, an I-Frame in my video file), and I press <Shift>-<Right>, I'd expect the current timestamp to change to 00:00:11,000. Instead, nothing happens, the timestamp stays at 00:00:10,000. This is logged in the terminal for this action:


[HandleAction] 22:32:12-580  ************ Forward1Second **************
  [GUI_SeekByTime] 22:32:12-580  Seek to:00:00:11,000 ms
  [seektoTime] 22:32:12-580  First frame of the new segment is a keyframe at 10000ms
  [DecodePictureUpToIntra] 22:32:12-580   DecodeUpToInta 250 ref:0
[edCache] Flush
[goToTimeVideo] 22:32:12-583  Seek done, in reference, gone to 10000000 with segment start at 0


It seems, that at first the correct timestamp of 00:00:11,000 is calculated, but later on the program ends at 10000ms again.

I can reproduce this behaviour with any of the video files I tried, starting at any I-Frame.

I did some debugging and found, that in function GUI_SeekByTime() (avidemux/common/gui_navigate.cpp) a call to video_body->getPKFramePTS() is made. This call seems to rewind the calculated timestamp to its previous I-Frame. Is this correct?


bool GUI_SeekByTime(int64_t time)
{
   uint64_t pts=admPreview::getCurrentPts();

   if (time < 0 && pts < -time)
         pts = 0;
   else
         pts += time;

   ADM_info("Seek to:%s ms \n",ADM_us2plain(pts));
   if(video_body->getPKFramePTS(&pts)) // FIXME: Rewinds to the previous I-Frame, why?
       return GUI_GoToTime(pts);

   return false;
}


My video files typically have an I-Frame about every 10 seconds. I think, in the current version of Avidemux, it is impossible to step forward or backward in steps of 1,2 or 4 seconds. Stepping forward 1 second from an I-Frame simply does nothing, stepping backward 1 second rewinds too far (about 10 seconds in my video files).

I built the current Avidemux without this call to video_body->getPKFramePTS(&pts), and: ... stepping forward and backward in second-steps is working again :D.

So, is this call really necessary or could it possibly be removed? (I could find no errors in my build without it so far.).
If this call really is necessery for some reason, is there a way to make the shortcuts <Shift>/<Ctrl>/<Shift>+<Ctrl> - <Left>/<Right> working again?

Thank you.

eumagga0x2a

The call is necessary because GUI_GoToTime(pts) will fail if pts doesn not match a pts of a frame exactly. I have a patch in the works.

Jan Gruuthuse

Quote from: chubacca on December 17, 2016, 10:56:58 PM

At first, I used the GTK-version (I guess it was 2.5.? or something), as this was the version that came with Ubuntu by default. In this older version, I really liked the ability to step forward or backward through the video file in steps of 1,2 or 4 seconds using the keyboard shortcuts <Shift>/<Ctrl>/<Shift>+<Ctrl> - <Left>/<Right>.

If shortcuts are not showing in menu/working check this out: QT5 shortcut not showing

eumagga0x2a

I've opened a pull request. The patch implements (or rather restores?) the ability to jump precisely to the frame just before the specified time and fixes navigation in 1/2/4s steps.

chubacca

Quote from: eumagga0x2a on December 18, 2016, 03:28:08 AM
The call is necessary because GUI_GoToTime(pts) will fail if pts doesn not match a pts of a frame exactly. I have a patch in the works.

Thank you for clarifying this.

Quote from: eumagga0x2a on December 18, 2016, 06:23:15 AM
I've opened a pull request. The patch implements (or rather restores?) the ability to jump precisely to the frame just before the specified time and fixes navigation in 1/2/4s steps.

Wow, very quick reaction.  :D

The keyboard shortcuts are working now, thank you very much.