Trackbar behavior in DGIndexNV

[Blue_MiSfit]

A little bug report, the scrub behavior inside DGIndexNV is a little strange. If I click on the timeline I get a clean seek with no problems. If I scrub the playhead, I get inconsistent results. I'm using the latest 2022, a QuadroFX 2800 GPU, and Windows 7 x64. I'm running 257.24 drivers from nVidia, probably not the most bleeding edge but meh... :)

This is with the Avatar BluRay stream (H.264), muxed to an MKV file.

Derek

[neuron2]

I don't know what you mean by "inconsistent results". And, as always, I need a stream to reproduce the issue.

[stax76]

I think he means with mouse click he gets the correct position but with mouse move the position is sometimes off so minor message processing or cuda issue and probably with any or most streams. I could reproduce it with the first AVC stream I tried.

[neuron2]

Please post a link to a stream to reproduce it.

I do not see any issues with scrubbing.

Standing by for your test stream...

[stax76]

When you seek with mouse move, after you release, the seek bar and video position isn't always at the mouse position but behind, the seek bar position jumps back when you stop moving. I can reproduce it with different streams and codecs. Hard to guess what possibly could help without seeing some code. Not much to worry anyway.

[neuron2]

Of course not, it positions to the GOP start location.

Cuda issue I would guess. You have no idea what you are talking about.

[Blue_MiSfit]

@neuron2:
stax76 described the issue perfectly. I've seen it with almost every stream. You do have to move the mouse rather willy nilly to do this - granted :)

You can use my test files from the MPEG-4 AVC forum. Those files (while generated for a different purpose) will display the issue if you play with it for awhile.

http://www.mediafire.com/?535bc4iwhj8x9t5
http://www.mediafire.com/?e2l34cpyuk29jtw

Derek

[stax76]

It jumps back up to 10% of the overall length in full movies both H264 and VC-1, of course there are only like 10 GOPs...

[neuron2]

You guys aren't listening to me.

When you move the mouse and let go, or you click and drag and then pause without releasing the click, it starts decoding from that point, displays the first decodable frame (at the start of the next GOP), and then positions to that point. That may not be the place where you let go, and this will be obvious when there are just a few GOPs on the timeline. This is by design. The idea is that the bar should be positioned at the start of the GOP on display.

If you see behavior that is not like that then please provide a stream.

I hope the behavior is clear to you now. It's been that way since DVD2AVI!

[neuron2]

It jumps back up to 10% of the overall length in full movies both H264 and VC-1, of course there are only like 10 GOPs... More nonsense (13000 frame GOPs).

[neuron2]

You can use my test files from the MPEG-4 AVC forum. Those files (while generated for a different purpose) will display the issue if you play with it for awhile. I see nothing unexpected or problematic with them. Of course 5Mbps for full sized Avatar is way too low; there is bad macroblocking in high motion scenes. :)

Is there something here that impacts your ability to use the tool?

[neuron2]

I can make the cursor a little less jittery by only displaying it at the decode positions and not the mouse positions.

The cursor does not jump back behind the mouse position. I challenge you to demonstrate that. It can be momentarily behind if you move the mouse forward. Wait for the trackbar event and decode to finish and that will change. Of course with 13000 frame GOPs like stax describes (full movie made up of only 10 GOPs!) the decode will take so long that you may think it is stuck back there. :)

[Audionut]

Hi Don,

The way I read this thread, was that it was stepping back 10 gops. Not that there was only 10 gops in the entire stream.
edit: but you've described how it works anyway.

This is neither here nor their for me as seek is the last thing I use the indexer for, however, I could see how it would be beneficial to have the indexer decode to the mouse position where the user released rather than the cursor jumping back to the start of the last decoded gop.

edit: I am rather tired though and could be reading things wrongly. In which case, be kind. :)

Regards,

[neuron2]

The way I read this thread, was that it was stepping back 10 gops. Not that there was only 10 gops in the entire stream. He clearly says the stream has only 10 GOPs. Please read it again.

I could see how it would be beneficial to have the indexer decode to the mouse position where the user released rather than the cursor jumping back to the start of the last decoded gop. No can do. The cursor would then be out of sync because only the GOP starts can be displayed.

The cursor does not jump backward! It jumps forward. If you have a 13000 frame GOP then it may take a while as I explained.

I think when I remove the jitter as I described you all will be able to more clearly see what the behavior really is and how it is appropriate given that only GOP starts are displayed.

I wish the OP had simply said "the cursor looks jittery". It's this claimed backward jumping that has put a bee in my bonnet.

[neuron2]

Here's the less jittery version (32 bit):

http://neuron2.net/dgdecnv/less_jittery.zip

Please remember, as I have explained, if you have long GOPs and move the cursor forward, it make take a while for the cursor to locate forward.

This behavior looks cleaner but is not fundamentally different. So something positive has come out of this. I love happy endings. :)

[stax76]

The 10 GOP comment was irony and yes, I'm sorry about that.

[neuron2]

Sorry for not recognizing that it was not serious. Here, smoke this peace pipe with me.

[stax76]

Alright, I'll check your test built.

[neuron2]

Alright, I'll check your test built. Thank you. I'd like to release it tonight, so if you think of anything else that might be improved (within the constraints of positioning only to GOP starts when in GOP step mode), please let me know.