No messages indicating ongoing activity and progress

[eyalroz]

Description of the feature or enhancement you'd like to see in HandBrake

The problem

When you start an encoding task using the GUI, it's possible for you to have the bottom message bar say something like:

Encoding: Pass 2 of 2, 100.0% 0 encodings pending

even though the work has just started. You would see the "Stop" instead of "Start" button, but no other indication of activity. Even if you open the so-called "activity log" - you will again see absolutely no indication of ongoing activity beyond some initial messages! A half hour, and perhaps even hours, can go by with no message whatsoever beyond the initial blurb.

And even that could say something like "starting whatever-phase-of-encoding, this may take a while..." - and then I'd be patient. But what I see is:

[23:44:22] sync: first pts video is 0
[23:44:22] sync: first pts audio 0x8000bd is 0
[23:44:22] sync: first pts audio 0x8000bd is 0

which tells me nothing.

The solution:

1. A message in the activity log every X seconds, indicating ongoing work.
2. A better indication that you'll need to wait a long time
3. A clearer indication that work is ongoing, in the main GUI window.
4. A progress bar in the main GUI window - using some kind of indication, even if it's inexact.

All of these together would be great, but any of these would be an improvement.

What Operating System are you running?

Devuan GNU/Linux Chimaera

What version of HandBrake are you running?

1.5.1

Where did you download HandBrake from?

handbrake.fr

Activity Log, Crash Log or any other details

No response

[sr55]

So, to be clear, you've managed to successfully compile this?

The GUI already contains real-time progress updates, progress bar and ETA and FPS read-out along the bottom. If it's not progressing, the app is likely hung and we'd need a full encode log to have any clue as to what's going on.

[eyalroz]

So, to be clear, you've managed to successfully compile this?

I linked manually with the extra -L to locate libudfread.

The GUI already contains real-time progress updates, progress bar and ETA and FPS read-out along the bottom. If it's not progressing, the app is likely hung and we'd need a full encode log to have any clue as to what's going on.

Actually, after... 25 minutes or so, more log messages were printed and, supposedly, the operation was done. I can't provide the entire log, for reasons, but here's the tail of it:

[23:44:22] file is MPEG Program Stream
[23:44:22] Probing 1 unknown stream
[23:44:22]     Probe: Found stream mpegvideo. stream id 0xe0-0x0
[23:44:22] sync: expecting 0 video frames
[23:44:22] encx264: encoding at constant RF 16.000000
[23:44:22] encx264: unparsed options: ref=5:bframes=5:level=3.1:b-adapt=2:direct=auto:analyse=all:me=umh:merange=24:subme=10:trellis=2:vbv-bufsize=17500:vbv-maxrate=17500:rc-lookahead=60
x264 [info]: using SAR=16/15
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile High, level 3.1, 4:2:0, 8-bit
[23:44:22] sync: first pts video is 0
[23:44:22] sync: first pts audio 0x8000bd is 0
[23:44:22] sync: first pts audio 0x8000bd is 0
[00:10:42] reader: done. 1 scr changes
[00:10:45] work: average encoding speed for job is 40.674549 fps
[00:10:45] comb detect: heavy 5287 | light 5887 | uncombed 53135 | total 64309
[00:10:45] decomb: deinterlaced 5287 | blended 5887 | unfiltered 53135 | total 64309
[00:10:45] vfr: 64309 frames output, 0 dropped and 0 duped for CFR/PFR
[00:10:45] vfr: lost time: 0 (0 frames)
[00:10:45] vfr: gained time: 0 (0 frames) (0 not accounted for)
[00:10:45] stream: 453319 good frames, 0 errors (0%)
[00:10:45] ac3-decoder done: 80378 frames, 0 decoder errors
[00:10:45] ac3-decoder done: 80378 frames, 0 decoder errors
[00:10:45] mpeg2video-decoder done: 64302 frames, 0 decoder errors
[00:10:45] sync: got 64309 frames, 0 expected
[00:10:45] sync: framerate min 17.857 fps, max 25.000 fps, avg 25.000 fps
x264 [info]: frame I:469   Avg QP: 9.41  size: 48237
x264 [info]: frame P:15479 Avg QP:15.09  size: 25253
x264 [info]: frame B:48361 Avg QP:19.70  size:  6372
x264 [info]: consecutive B-frames:  2.3%  4.2% 22.1% 10.7%  8.4% 52.4%
x264 [info]: mb I  I16..4: 37.8% 51.8% 10.4%
x264 [info]: mb P  I16..4:  1.2% 12.4%  1.4%  P16..4: 20.9% 13.2% 11.6%  0.5%  0.1%    skip:38.7%
x264 [info]: mb B  I16..4:  0.4%  2.0%  0.2%  B16..8: 30.8%  7.0%  1.9%  direct: 5.3%  skip:52.4%  L0:38.1% L1:25.3% BI:36.6%
x264 [info]: 8x8 transform intra:77.4% inter:82.1%
x264 [info]: direct mvs  spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 73.8% 77.8% 46.0% inter: 23.8% 23.0% 6.0%
x264 [info]: i16 v,h,dc,p: 45% 29% 17%  9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 14% 33%  5%  5%  6%  6%  6%  8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 21% 12%  6%  9%  9%  9%  8%  9%
x264 [info]: i8c dc,h,v,p: 35% 31% 23% 11%
x264 [info]: Weighted P-Frames: Y:3.9% UV:1.6%
x264 [info]: ref P L0: 54.0% 16.7% 15.0%  6.5%  7.3%  0.5%  0.0%
x264 [info]: ref B L0: 85.3% 11.0%  2.8%  0.9%
x264 [info]: ref B L1: 97.2%  2.8%
x264 [info]: kb/s:2244.36
[00:10:45] mux: track 0, 64309 frames, 721647776 bytes, 2244.28 kbps, fifo 2048
[00:10:45] mux: track 1, 120568 frames, 51606069 bytes, 160.49 kbps, fifo 4096
[00:10:45] mux: track 2, 80378 frames, 61729724 bytes, 191.98 kbps, fifo 2048
[00:10:45] Finished work at: Thu Feb 10 00:10:45 2022
[00:10:46] libhb: work result = 0

[galad87]

There is already a progress message bar. Maybe the windows is too big for your screen or some kind of dependencies issue hides it.
Can you post a screenshot of the windows while encoding?

[eyalroz]

@galad87 : Unfortunately, I cannot, since the window changed after this happened.

[galad87]

Changed how? Is the progress info it still missing if you start another encode?

[eyalroz]

@galad87 : With another encoding, I see progress on what I now realize is a progress bad (it was just, well, a bar, in the previous run).

[sr55]

Doesn't look like there was anything wrong with the encode, so it could just be the GTK version on your system being glitchy if the UI isn't updating correctly. Seems to be quite common unfortunately. Styling of controls can vary a bit from distro to distro and depending on what customisations folks have done to their system.

I'm not sure if your distro supports flatpak or not but it may be better going that route as we provide builds for it, with known good environment.

[eyalroz]

@sr55 : I try to avoid flatpak... and building from source should work :-(

At any rate, even regardless of the progress bar, it would be nice to see occasional notices in the textual log about the work continuing.

[sr55]

and building from source should work :-(
In theory yes but in reality there is an impossible number of dependencies, versions to test against multiplied by the number of distro and distro versions. That's before we start accounting for mistakes that get made by distros in their "patching" or "customising" of libraries. Flatpak mostly solves this and as a benefit, runs the app within a security container.

With regards to the log, beyond what may be logged in terms of chapters and other debug information, I'd not want to pollute it with progress information.

Everything you need to tell progress is already present on the UI:

[eyalroz]

Well, it's present on the UI as long as you have a functioning UI, but... it's your app, you decide I guess.