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
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.
Confirmed. I always use the Go to the first frame (beginning) (https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fwww.avidemux.org%2FadmWiki%2Flib%2Fexe%2Ffetch.php%3Fmedia%3Dusing%3Afirst_frame-qt.png&hash=259e563672c5e389db15a6a886df5e39b33b5fb7)
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
Quote from: Jan Gruuthuse on September 28, 2016, 06:55:07 AM
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 (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).
QuoteAnd 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 (http://avidemux.org/smif/index.php/topic,16935.msg77232.html#msg77232).
Quote from: dosdan on September 28, 2016, 07:06:13 AMwhat 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 (https://github.com/mean00/avidemux2/commit/c0ce0daea3c81c4a9f46583a7b26fc2d010c9561), will check later. This is completely unrelated to the initial HiDPI issue though.
Quote from: eumagga0x2a on September 28, 2016, 04:10:07 PM
Quote from: Jan Gruuthuse on September 28, 2016, 06:55:07 AM
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 (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?
Quote from: Jan Gruuthuse on September 28, 2016, 05:50:34 PM
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):
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.
Quote from: eumagga0x2a on September 28, 2016, 04:10:07 PM
Quote from: dosdan on September 28, 2016, 07:06:13 AMwhat 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 (https://github.com/mean00/avidemux2/commit/c0ce0daea3c81c4a9f46583a7b26fc2d010c9561)
No, I was wrong. This commit is not a factor here.
Quote from: eumagga0x2a on September 28, 2016, 06:52:39 PM
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
The following patch fixes the issue with video not following the slider back to zero, remaining stuck at random offsets:
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.
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 (http://avidemux.org/smif/index.php/topic,17186.0.html)
Quote from: Jan Gruuthuse on September 30, 2016, 06:10:26 AM
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.
Quotedon'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.
QuoteWhat 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.
Quotecould there be a relation to report by ajschult: Window not repainted after navigation (http://avidemux.org/smif/index.php/topic,17186.0.html)
Can't reproduce with VDPAU on gnome-shell and the necessary VDPAU_NVIDIA_NO_OVERLAY=1 (should not be related) in env.
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?
Quote from: eumagga0x2a on September 30, 2016, 06:34:30 AM
Quote from: Jan Gruuthuse on September 30, 2016, 06:10:26 AM
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.
QuoteQuotedon'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 (https://www.youtube.com/watch?v=rM-3vfz8of8)
Thanks for the video. This is exactly how an unpatched Avidemux behaves, no matter which decoder and video output.
Just to be sure: what does
grep -n "getNKFramePTS(&pts)" avidemux/common/gui_navigate.cpp
return when run in the Avidemux top source directory?
how to tell if patch was applied correctly?
I did:
git apply update.diff with above code starting with:
Quotediff --git a/avidemux/common/gui_navigate.cpp b/avidemux/common/gui_navigate.cpp
and rebuild
Quote from: eumagga0x2a on September 30, 2016, 07:46:44 AM
Just to be sure: what does
grep -n "getNKFramePTS(&pts)" avidemux/common/gui_navigate.cpp
return when run in the Avidemux top source directory?
73: if(false==video_body->getNKFramePTS(&pts))
Yes, it is patched. I strongly hope that Mean will look at it and test as well, because the patch fixes the bug for me 100%, I can't reproduce the buggy behaviour when dragging slider to zero with patched Avidemux.
I usually just use
patch -p1 < /path/to/the/diff/file.patch
to patch and
patch -Rp1 < /path/to/the/diff/file.patch
to revert.
you do test with with mpeg-ts over 2 hours in duration? Just in case?
I try your way of patching, see if that makes difference.
update:
patch -p1 < ~/Downloads/dragging-slider-to-zero-does-not-rewind-video-to-zero-fix.patchQuotepatching file avidemux/common/gui_navigate.cpp
test if code is present:
grep -n "getNKFramePTS(&pts)" avidemux/common/gui_navigate.cppQuote73: if(false==video_body->getNKFramePTS(&pts))
now rebuilding
Yes, with transport streams, program streams and mkv files up to 3 hours in duration, both HD (h264) and mpeg2. Works 100%
The way of patching should not matter in this case, because the patch was successfully applied.
Actually, the approach used in the path would fail in the case if getNKFramePTS (getting the PTS of the next keyframe) fails at the start of the video for whatever reason. Could you please drag the slider from right fully to the left (and leave it there) and post the last ~100 lines of the Avidemux console output?
as requested: 7zipped, its a bit longer
Thank you, but the slider was never moved fully to the left (to zero) as requested. You've moved it fully to the right instead and left it there:
grep Scale\ : SliderFromLeft\ ToRight
[HandleAction_Navigate] Scale :9
[HandleAction_Navigate] Scale :1211
[HandleAction_Navigate] Scale :2128
[HandleAction_Navigate] Scale :2173
[HandleAction_Navigate] Scale :2618
[HandleAction_Navigate] Scale :2947
[HandleAction_Navigate] Scale :3179
[HandleAction_Navigate] Scale :3259
[HandleAction_Navigate] Scale :3500
[HandleAction_Navigate] Scale :3758
[HandleAction_Navigate] Scale :4016
[HandleAction_Navigate] Scale :4087
[HandleAction_Navigate] Scale :4363
[HandleAction_Navigate] Scale :4657
[HandleAction_Navigate] Scale :4862
[HandleAction_Navigate] Scale :4889
[HandleAction_Navigate] Scale :5058
[HandleAction_Navigate] Scale :5646
[HandleAction_Navigate] Scale :6652
[HandleAction_Navigate] Scale :6803
[HandleAction_Navigate] Scale :7124
[HandleAction_Navigate] Scale :7578
[HandleAction_Navigate] Scale :7907
[HandleAction_Navigate] Scale :7925
[HandleAction_Navigate] Scale :7970
[HandleAction_Navigate] Scale :8308
[HandleAction_Navigate] Scale :8700
[HandleAction_Navigate] Scale :9207
[HandleAction_Navigate] Scale :9288
[HandleAction_Navigate] Scale :9323
[HandleAction_Navigate] Scale :9421
[HandleAction_Navigate] Scale :9813
[HandleAction_Navigate] Scale :9858
[HandleAction_Navigate] Scale :9920
[HandleAction_Navigate] Scale :9947
[HandleAction_Navigate] Scale :10000
damm, you're right.
I see, you did not mention: the jump to start only happens when you release left mouse press.
It's a way of solving issue, ....
Quote from: Jan Gruuthuse on September 30, 2016, 08:47:04 AM
I see, you did not mention: the jump to start only happens when you release left mouse press.
No, it works for me even without releasing the slider (which executes ACT_Scale once again: https://github.com/mean00/avidemux2/blob/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_gui2.cpp#L251 (https://github.com/mean00/avidemux2/blob/master/avidemux/qt4/ADM_userInterfaces/ADM_gui/Q_gui2.cpp#L251) at line 259).
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
[HandleAction_Navigate] Scale :0
[HandleAction_Navigate] Scale Time:5 ms (total=8100366 ms)
[HandleAction_Navigate] Scale Time:00:00:00,005 ms
[searchPreviousKeyFrameInRef] Cannot find keyframe with PTS less than 00:00:00,005
[getPKFramePTS] No previous previous keyfr for frameTime 5000 in ref 0 seg:0 nkTime 140724603453 refTime:5 ms startTime=0 r=0
[searchNextKeyFrameInRef] Found nextkeyframe 706 0:0:0 at frame 0
[HandleAction_Navigate] Seeking to Time:00:00:00,706 ms
[DecodePictureUpToIntra] DecodeUpToInta 0 ref:0
Is says "Found nextkeyframe" so it should have worked.
Console output from your Avidemux build differs from mine in one significant point though: there are always double scale events all over the place. Don't understand why yet.
perhaps mean has a clue
Would you please test the following compound not-for-production patch (which includes an unrelated fix for PgDown after loading a video resulting in an error)? As far as I understand, it would force Avidemux to redraw twice after a scale event and when navigating to the next or previous keyframe.
diff --git a/avidemux/common/gui_navigate.cpp b/avidemux/common/gui_navigate.cpp
index 23df368..f3b5615 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))
@@ -80,6 +83,7 @@ static int ignore_change=0;
ADM_warning("Scale: Seeking to intra at %" PRIu64" ms failed\n",pts/1000);
}
UI_setCurrentTime(pts);
+ admPreview::samePicture();
UI_purge();
ignore_change--;
}
@@ -90,8 +94,26 @@ static int ignore_change=0;
uint64_t pts;
if(action==ACT_GotoMarkA) pts=video_body->getMarkerAPts();
else pts=video_body->getMarkerBPts();
- GUI_GoToTime(pts);
-
+ if(false==video_body->goToTimeVideo(pts))
+ {
+ if(action==ACT_GotoMarkA)
+ {
+ ADM_warning("Go to Marker A: Seek to time %s ms failed\n",ADM_us2plain(pts));
+ }else // PTS returned by getMarkerBPts() may be beyond the last frame.
+ // Go to the last frame then.
+ {
+ pts=video_body->getLastKeyFramePts();
+ if(pts==ADM_NO_PTS) break;
+ admPreview::deferDisplay(1);
+ GUI_GoToTime(pts);
+ while(admPreview::nextPicture())
+ {
+ }
+ admPreview::deferDisplay(0);
+ }
+ }
+ admPreview::samePicture();
+ GUI_setCurrentFrameAndTime();
}
break;
@@ -228,6 +250,7 @@ void GUI_NextKeyFrame(void)
A_timedError(QT_TRANSLATE_NOOP("navigate","Cannot go to next keyframe"));
return;
}
+ admPreview::samePicture();
GUI_setCurrentFrameAndTime();
UI_purge();
}
@@ -297,6 +320,7 @@ void GUI_PreviousKeyFrame(void)
A_timedError(QT_TRANSLATE_NOOP("navigate","Cannot go to previous keyframe"));
return;
}
+ admPreview::samePicture();
GUI_setCurrentFrameAndTime();
UI_purge();
This patch includes the previous one, so please revert dragging-slider-to-zero-does-not-rewind-video-to-zero-fix.patch first.
with current patch:
The patch was not related to redoubled scale actions
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
in the output. It was trying to fix the issue I can't reproduce with the video window showing previous picture (not refreshing). Does Avidemux still fail to display the first keyframe when the slider is dragged (but not released) fully back to the left?
most of the time, It goes wrong when mouse pointer goes of avidemux gui: seems to me.
Quote from: Jan Gruuthuse on September 30, 2016, 10:50:10 AM
most of the time, It goes wrong when mouse pointer goes of avidemux gui: seems to me.
I'm very sorry, but I fail to follow you in this description. I'm pretty sure that the concept of the initial version of patch is correct. The redraw issue is probably a separate thing which misleadingly overlays this one. I still have no idea why you and ajschult experience the redraw problem and I can't, absolutely can't reproduce it on my system running gnome-shell.
Just a wild guess, but could repeated doubled and tripled entries/calls to HandleAction like
[edCache] Flush
[canSupportThis] Vdpau not enabled
[canSupportThis] LibVA not enabled
[lookup] No Matching Hw accel
[ADM_FFgetFormat] No Hw Accel for that
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
[HandleAction_Navigate] Scale :1407
[HandleAction_Navigate] Scale Time:1139726 ms (total=8100366 ms)
[HandleAction_Navigate] Scale Time:00:18:59,726 ms
[HandleAction_Navigate] Seeking to Time:00:18:59,346 ms
[DecodePictureUpToIntra] DecodeUpToInta 56705 ref:0
[edCache] Flush
be related to (unwanted) multithreading? I currently fail to understand autolock in
admScopedMutex autolock(&singleThread); // make sure only one thread at a time calls this
from [GUI] Use a scoped mutex to make sure the main event function is not called multiple concurrent time (https://github.com/mean00/avidemux2/commit/d73b1a84e0ad2922275347f1ca8e554f1bc2cb05) because in
class ADM_CORE6_EXPORT admScopedMutex
{
private:
admMutex *_tex;
public:
admScopedMutex( admMutex *tex);
~admScopedMutex();
uint8_t lock(void);
uint8_t unlock(void);
uint8_t isLocked(void);
};
from ADM_threads.h there is nothing like autolock (but this should be just due to my deep ignorance). Does locking work or rather fail here? My CPU has only two cores, maybe this is the clue why I can't reproduce the redraw issue?
tried to follow your thinking:
attached 2 files both with moving slider left to right, right to left.
- SliderDragLeftRight-RightLeft
2cores set in preferences.
- SliderDragLeftRight-RightLeft
MultithreadingLAVCthreads
Disabled in preferences.
both keep showing:
[edCache] Flush
[canSupportThis] [b]Vdpau[/b] not enabled
[canSupportThis] [b]LibVA[/b] not enabled
[lookup] No Matching Hw accel
[ADM_FFgetFormat] No Hw Accel for that
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
[HandleAction_Navigate] Scale :356
[HandleAction_Navigate] Scale Time:191437 ms (total=5377305 ms)
[HandleAction_Navigate] Scale Time:00:03:11,437 ms
[HandleAction_Navigate] Seeking to Time:00:03:10,975 ms
[DecodePictureUpToIntra] DecodeUpToInta 9428 ref:0is
Quote[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
not the result from revisiting every time testing [
canSupportThis]
Quote[edCache] Flush
[canSupportThis] Vdpau not enabled
[canSupportThis] LibVA not enabled
1st time you have:
QuotePaint event
[refresh] XV:refresh
[HandleAction] ************ Scale **************
[HandleAction_Navigate] Scale :71
[HandleAction_Navigate] Scale Time:38183 ms (total=5377305 ms)
[HandleAction_Navigate] Scale Time:00:00:38,183 ms
[HandleAction_Navigate] Seeking to Time:00:00:37,935 ms
[DecodePictureUpToIntra] DecodeUpToInta 1776 ref:0
2nd time and follow ups:
Quote[edCache] Flush
[canSupportThis] Vdpau not enabled
[canSupportThis] LibVA not enabled
[lookup] No Matching Hw accel
[ADM_FFgetFormat] No Hw Accel for that
[HandleAction] ************ Scale **************
[HandleAction] ************ Scale **************
clash of found hardware?
Probably should test preference settings once with loaded video and see if that works with
wanted setting and not with
possible settings.
avidemux should not visit
Vdpau nor
LibVA, the hardware is there, the settings are not set to use one of these
?the system contains
- nvidia gpu
- 4 core intel cpu with hyperthreading and gpu
system is used for building avidemux deb and has present developer libraries for intel, amd and nvidia hardware.
my idea/deduction could be wrong.
autolock, is made so that the lock is freed when exiting the function
i.e. when the destructor is called.
It is to avoid tracking every code path.
Qt events are normally only managed on one thread on linux, but no on windows if my memory is correct
*edit: typos
Thank you very much for explaining the purpose. I still fail to understand where autolock is defined (to understand why this works at all), but I'll find this out on my own.
What do you think about multiple calls to ACT_Scale in the console output of Jan's Avidemux?
If Qt GUI is always running in a single thread, it is not the GUI which is causing issues like Window not repainted after navigation (http://avidemux.org/smif/index.php/topic,17186.0.html) here. If putting admPreview::samePicture() all over the place works around the problem, maybe take this workaround now and investigate (which would be beyond my capabilities for sure) later?
Did you have a minute or two to look at the patch for ACT_Scale in http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305 (http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305) or even to test it if you deem the logic to be correct?
It looks like a double buffering problem
i.e. bufferA is updated but not displayed
If you call it a second time, bufferB is updated and bufferA is displayed, so it "looks" ok
I dont have much time atm, didnt look into that patch yet
I'd like to have the h264/h265 intel hw encoder to work to see how it fares
just tested with160927_54.app, very confusing
no double: [HandleAction] ************ Scale **************
It is made using debian Qt5, not ubuntu Qt5
Some settings are different
I'm sorry, but if we're at it, would you add the patch in http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305 (http://avidemux.org/smif/index.php/topic,17181.msg77305.html#msg77305) to the queue? That one was really difficult to narrow down :)
done
I can't keep up
Thank you very much! The redraw issues I'd prefer to address separately later.