2016-12-14, 02:49 PM
A suggestion I'll make for NextPVR and VLC:
One suggestion I'd make for an enhancement: skipping to a point in a video that is not accurately known is a nuisance (an example is advertisement skipping). If you take small jumps there have to be many; if large jumps, they go too far. So you set up jumps of various sizes; if you remember the keys you start with big ones, and make them smaller as you home in; you would typically have 6 keys, small, medium, and large jumps forwards and backwards. Alternatively, you could use fast-forwards/backwards, which is slow and a nuisance.
A much more convenient and faster method is to use a binary chop: you start with a large jump, and the size progressively and automatically gets smaller (halved) as you approach, until you reach the right spot. I have a hardware video recorder with a software plugin supporting this; it is extremely useful. Your first jump is fixed size, and can be repeated in the same direction; once you change direction, you halve the length of each successive jump. So, if your first jump is 4 minutes (240 seconds) and your destination (which you don't know) is 5'23" (323") ahead, you quickly press r (right arrow; takes you 240" ahead) r (jump +240", position 480") l (-120", 360") l (-60", 300") r (+30", 330"), l (-15", 315", close enough, or we can go +7.5" to 322.5"). You obviously don't have to do these sums, just watch the result as you quickly do r r l l r l. You never require more than 7 jumps after the first reversal to get within 7.5", with just 2 keys, and no need to change from bigger to smaller jumps. If you make a mistake and find you're making small steps from too far away, wait 5" and start again - this shouldn't happen often.
The algorithm has 3 parameters, which should be user-configurable, and uses two keys (left and right keyboard or remote controller arrows are the obvious allocations). The parameters are: initial jump, could default to 4 minutes; smallest jump (so we don't end up with millisecond jumps), which could be 5"; and timeout, say 5 seconds. The binary chop continues until no key is pressed during the timeout period, then reinitialises.
On pressing an arrow key, we initially jump 4'. Every press of the same key is 4' in the same direction. When we press the opposite key, the binary chop starts; the jump is halved at every keypress in either direction, until it reaches the configured smallest value of 5" or whatever. Subsequent jumps are all by this smallest value. When we're near enough we stop; there's no need to get closer than a few seconds before.
This technique was implemented by Simon Capewell in the QuickJump 1.7 TAP (software add-on) for the discontinued Topfield TF5800 PVR, and very useful it is.
One suggestion I'd make for an enhancement: skipping to a point in a video that is not accurately known is a nuisance (an example is advertisement skipping). If you take small jumps there have to be many; if large jumps, they go too far. So you set up jumps of various sizes; if you remember the keys you start with big ones, and make them smaller as you home in; you would typically have 6 keys, small, medium, and large jumps forwards and backwards. Alternatively, you could use fast-forwards/backwards, which is slow and a nuisance.
A much more convenient and faster method is to use a binary chop: you start with a large jump, and the size progressively and automatically gets smaller (halved) as you approach, until you reach the right spot. I have a hardware video recorder with a software plugin supporting this; it is extremely useful. Your first jump is fixed size, and can be repeated in the same direction; once you change direction, you halve the length of each successive jump. So, if your first jump is 4 minutes (240 seconds) and your destination (which you don't know) is 5'23" (323") ahead, you quickly press r (right arrow; takes you 240" ahead) r (jump +240", position 480") l (-120", 360") l (-60", 300") r (+30", 330"), l (-15", 315", close enough, or we can go +7.5" to 322.5"). You obviously don't have to do these sums, just watch the result as you quickly do r r l l r l. You never require more than 7 jumps after the first reversal to get within 7.5", with just 2 keys, and no need to change from bigger to smaller jumps. If you make a mistake and find you're making small steps from too far away, wait 5" and start again - this shouldn't happen often.
The algorithm has 3 parameters, which should be user-configurable, and uses two keys (left and right keyboard or remote controller arrows are the obvious allocations). The parameters are: initial jump, could default to 4 minutes; smallest jump (so we don't end up with millisecond jumps), which could be 5"; and timeout, say 5 seconds. The binary chop continues until no key is pressed during the timeout period, then reinitialises.
On pressing an arrow key, we initially jump 4'. Every press of the same key is 4' in the same direction. When we press the opposite key, the binary chop starts; the jump is halved at every keypress in either direction, until it reaches the configured smallest value of 5" or whatever. Subsequent jumps are all by this smallest value. When we're near enough we stop; there's no need to get closer than a few seconds before.
This technique was implemented by Simon Capewell in the QuickJump 1.7 TAP (software add-on) for the discontinued Topfield TF5800 PVR, and very useful it is.
It isn't perfect, but it does a great job most of the time. My wimpy Core2Duo can process a 1 hour show in about 10 minutes, using the donator version of Comskip. I've never messed with parallel processing as we seldom watch shows until the next day or later.