slider position displayed time

[Jan Gruuthuse]

The hour part is not showing in its time display [Time:] [l:05:53.833 (marked red). Time permitting, could someone look at this?
And perhaps give the same time display properties as used with box A: and B: (marked green)
Thanks

[dosdan]

Jan, what happens in the Time display when you load a MP4 or a MPEG and you drag the slider part-way to the right and then drag it back fully to the left? It's not going back to 0:00:00 for me, and each time I repeat this action, a different starting time is showing.

2.6.14 - Release - Win64.

Dan.

[Jan Gruuthuse]

Confirmed. I always use the Go to the first frame (beginning)
with 11 hour video I got differences up to 48 minutes
Tested with commit ab5ddb4 on ubuntu 14.04.5 64-bit QT4

update: This also happens with mpeg-ts

[eumagga0x2a]

The hour part is not showing in its time display [Time:] [l:05:53.833 (marked red).

We've already discussed this in http://avidemux.org/smif/index.php/topic,17079.msg76767.html#msg76767. Avidemux is not HiDPI aware (or Ubuntu's Unity doesn't accomodate such applications enough).

And perhaps give the same time display properties as used with box A: and B: (marked green)

This is http://avidemux.org/smif/index.php/topic,16935.msg77232.html#msg77232.

what happens in the Time display when you load a MP4 or a MPEG and you drag the slider part-way to the right and then drag it back fully to the left? It's not going back to 0:00:00 for me, and each time I repeat this action, a different starting time is showing.

Confirming the bug for Qt5 builds from the current master, could be related to https://github.com/mean00/avidemux2/commit/c0ce0daea3c81c4a9f46583a7b26fc2d010c9561, will check later. This is completely unrelated to the initial HiDPI issue though.

[Jan Gruuthuse]

The hour part is not showing in its time display [Time:] [l:05:53.833 (marked red).

We've already discussed this in http://avidemux.org/smif/index.php/topic,17079.msg76767.html#msg76767. Avidemux is not HiDPI aware (or Ubuntu's Unity doesn't accomodate such applications enough).

As timer indicator A and B @ righthand (same screen shot) can display the hour, so it (c/sh/w)ould be possible? make the box wider?

[eumagga0x2a]

As timer indicator A and B @ righthand (same screen shot) can display the hour, so it (c/sh/w)ould be possible? make the box wider?

QPushButton has a different size policy. You could try out the following patch (not yet for production):

Code Select Expand

diff --git a/avidemux/qt4/ADM_userInterfaces/ADM_gui/gui2.ui b/avidemux/qt4/ADM_userInterfaces/ADM_gui/gui2.ui
index 6e4bda4..ab3a98d 100644
--- a/avidemux/qt4/ADM_userInterfaces/ADM_gui/gui2.ui
+++ b/avidemux/qt4/ADM_userInterfaces/ADM_gui/gui2.ui
@@ -1335,15 +1335,14 @@
          <item>
           <widget class="QLineEdit" name="currentTime">
            <property name="sizePolicy">
-            <sizepolicy hsizetype="Fixed" vsizetype="Fixed">
+            <sizepolicy hsizetype="Minimum" vsizetype="Maximum">
              <horstretch>0</horstretch>
              <verstretch>0</verstretch>
             </sizepolicy>
            </property>
-           <property name="maximumSize">
+           <property name="minimumSize">
             <size>
              <width>100</width>
-             <height>16777215</height>
             </size>
            </property>
            <property name="text">
@@ -1363,7 +1362,7 @@
          <item>
           <widget class="QLabel" name="totalTime">
            <property name="sizePolicy">
-            <sizepolicy hsizetype="Minimum" vsizetype="Fixed">
+            <sizepolicy hsizetype="Minimum" vsizetype="Maximum">
              <horstretch>0</horstretch>
              <verstretch>0</verstretch>
             </sizepolicy>

(Sorry, the initial version was too bad)

Be warned that the current logic which sets the initial size of the Avidemux window overrides the needs of the text in the QLineEdit widget holding the current time string. If your font size in pixels is big (and due to HiDPI it is huge), you will have to pull the window wider or load a HD video to allow the complete string to become visible. Specifying a fixed minimum size would in turn break the GUI on low-res displays. The patch does allow the widget to grow in order to accomodate big font sizes.

A real solution would have to include a redesign of the GUI resizing logic.

[eumagga0x2a]

what happens in the Time display when you load a MP4 or a MPEG and you drag the slider part-way to the right and then drag it back fully to the left? It's not going back to 0:00:00 for me, and each time I repeat this action, a different starting time is showing.

Confirming the bug for Qt5 builds from the current master, could be related to https://github.com/mean00/avidemux2/commit/c0ce0daea3c81c4a9f46583a7b26fc2d010c9561

No, I was wrong. This commit is not a factor here.

[Jan Gruuthuse]

Be warned that the current logic which sets the initial size of the Avidemux window overrides the needs of the text in the QLineEdit widget holding the current time string. If your font size in pixels is big (and due to HiDPI it is huge), you will have to pull the window wider or load a HD video to allow the complete string to become visible. Specifying a fixed minimum size would in turn break the GUI on low-res displays. The patch does allow the widget to grow in order to accomodate big font sizes.

A real solution would have to include a redesign of the GUI resizing logic.

patch diff seems to work fine on QT4 ubuntu 14.04.5 64-bit unity, showing 720p video

[eumagga0x2a]

The following patch fixes the issue with video not following the slider back to zero, remaining stuck at random offsets:

Code Select Expand

diff --git a/avidemux/common/gui_navigate.cpp b/avidemux/common/gui_navigate.cpp
index 23df368..2b783a1 100644
--- a/avidemux/common/gui_navigate.cpp
+++ b/avidemux/common/gui_navigate.cpp
@@ -70,9 +70,12 @@ static int ignore_change=0;
           ADM_info("Scale Time:%s ms \n",ADM_us2plain(pts));
            if(false==video_body->getPKFramePTS(&pts))
             {
-                ADM_warning("Cannot seek to %" PRIu64" ms\n",pts/1000);
-                ignore_change--;
-                break;
+                if(false==video_body->getNKFramePTS(&pts))
+                {
+                    ADM_warning("Cannot seek to %" PRIu64" ms\n",pts/1000);
+                    ignore_change--;
+                    break;
+                }
             }
              ADM_info("Seeking to  Time:%s ms \n",ADM_us2plain(pts));
             if(true!=admPreview::seekToIntraPts(pts))

If I got it right, we gave up if there was no previous keyframe available, ended up with a random last decoded one. But there is no previous keyframe at pts==0, so try to look also for the next keyframe in this case.

[Jan Gruuthuse]

the behaviour is still the same on VDPAU Vdpau
tested with duration 2:15:00.366 swr HD sat recording
with right click mouse selected slider go to end of video, don't release mouse right click and go back to start with slider.
and keep repeating this action
begin shows every time a different start time at begin, seems random always below 01:00:00:.000

What did change is the (|<) button behaviour: It goes now to the 1st key frame [00:00:00.706] and not 1st frame [00:00:00.000)

could there be a relation to report by ajschult: Window not repainted after navigation

[eumagga0x2a]

the behaviour is still the same on VDPAU Vdpau
tested with duration 2:15:00.366 swr HD sat recording
with right click mouse selected slider go to end of video

Have you configured the right mouse button to perform the middle click? The (right) right mouse button has no effect on the slider, won't drag it.

don't release mouse right click and go back to start with slider.
and keep repeating this action
begin shows every time a different start time at begin, seems random always below 01:00:00:.000

Dragging (with the left mouse button) the slider works now as it should for me (goes back to the first keyframe) with a patched Avidemux. Doesn't work without the patch.

What did change is the (|<) button behaviour: It goes now to the 1st key frame [00:00:00.706] and not 1st frame [00:00:00.000)

I didn't touch the related code.

could there be a relation to report by ajschult: Window not repainted after navigation

Can't reproduce with VDPAU on gnome-shell and the necessary VDPAU_NVIDIA_NO_OVERLAY=1 (should not be related) in env.

[eumagga0x2a]

Re. "Pos 1" key / "|<" button: whether a video starts at zero or with an offset depends on the video. Avidemux detects and shows the PTS of the first keyframe. It can't go before the first keyframe, obviously. It was always this way.

Re. VDPAU issue I can't reproduce: please disable decoding in hardware and the VDPAU video output just for testing purposes. You do test with an Avidemux build which includes the patch for gui_navigate.cpp, don't you?

[Jan Gruuthuse]

the behaviour is still the same on VDPAU Vdpau
tested with duration 2:15:00.366 swr HD sat recording
with right click mouse selected slider go to end of video

Have you configured the right mouse button to perform the middle click? The (right) right mouse button has no effect on the slider, won't drag it.

You're right, it is left click keep pressed, not right.

don't release mouse right click and go back to start with slider.
and keep repeating this action
begin shows every time a different start time at begin, seems random always below 01:00:00:.000

Dragging (with the left mouse button) the slider works now as it should for me (goes back to the first keyframe) with a patched Avidemux. Doesn't work without the patch.

yes, with patch

update: youtube screen capture of behaviour

[eumagga0x2a]

Thanks for the video. This is exactly how an unpatched Avidemux behaves, no matter which decoder and video output.

[eumagga0x2a]

Just to be sure: what does

Code Select Expand

grep -n "getNKFramePTS(&pts)" avidemux/common/gui_navigate.cpp

return when run in the Avidemux top source directory?