Looks like what you've got is the best bet for now. You want to keep your links to a minimum, but there needs to be a connection between the progress bar and the video player, so at least one needs a reference to the other. Having all the connections in one controller means more work when one element wants to talk to another.
Events won't save you. If a dozen (or even two) different elements, unknown to the player, needed regular updates on progress, an event would be just the thing. Note that the player would now be setting off the event rather than calling a progress bar method, so you're pretty much breaking even in complexity. (But now it's harder to figure out who's being informed.) Here, I think a simple method call is better.
The elegant solution--the one probably floating around in the back of your head that led you to ask this question--would be to reverse the responsibilty and have the progress bar ask the player what the progress is. This takes a load off the player--it doesn't have to worry about when to make the calls--though it does have to have progress information always ready. There are no fancy events, just a simple method that someone else calls. And the player doesn't care how many other elements call the method, or when, or why.
The down side is the progress bar needs to run a timer to keep things going. But the player would have needed to do something similar: the work and the responsibility are now concentrated where they belong.
I'm not sure you need this "elegant" solution quite yet, but I think that's the direction you'll want to move in later.
(If you use it, be sure to run everything on the EventQueue, or UI queue, or whatever your language calls it--at any rate, keep everything on one thread. Multithreading is very tricky, and in most cases UI's only work on their own thread anyway.)