You're off to a good start then.
Other considerations. . .
Your router is a 3625? Unaware of such a model. Perhaps a 3725 or 3825? In any case, any ISR before the 4K series (and not even all of them) is a gig capable router, even when they have gig interfaces.
Second, if you're only using only two interfaces, both same bandwidth, it's almost impossible to congest the egress interface.
Third, if you egress port's bandwidth is actually more than what's available (like connecting to cable modems, ADSL modems, etc.), for QoS to be effective, you should shape the physical interface to the available bandwidth. One exception, if your using a multi-speed port, and you can run it at the actual available bandwidth speed, or a tad less, for QoS, that's better than using a QoS shaper. (E.g. your gig port is connected at gig to a link that only provides 100 Mbps effective bandwidth. If possible, run port at 100 Mbps.)
Two issues with using a PQ (router LLQ), it preempts all other traffic. This can starve lower priority traffic from obtaining ANY bandwidth, so to avoid that, LLQ used to offer an implicit policer. (Unsure what the later versions do, by default.)
The newer LLQ versions, I know, support two subqueues, with one having absolute priority over the other. The recommendation is to only use PQ 1 for VoIP traffic, and place stuff like real-time video into PQ 2.
PQ should be used when fully understood when it really must be used, and how to best configure it.
What you might first try is just the following:
policy-map OnlineTeaching
class class-default
fair-queue !FQ, alone, often well handles 90% of QoS needs
If you video seems to suffer, then you might try:
policy-map OnlineTeaching
class Try2
bandwidth percent 99
fair-queue
class class-default
bandwidth percent 1
fair-queue
The latter using your Try2 class-map. Why the latter, rather than what you have now? I can use FQ for multiple streams, yet can still give it, up to, almost full pre-emption priority (the 99 vs 1 %). Also what PQ/LLQ does with overrate traffic, it's policed, i.e. dropped, by the latter policy will queue overrate traffic, which I believe is slightly better for video.
Depending on your QoS stats, other QoS setting might be needed, like increased the 64 packet class queue limits. (64 is often "shallow" for gig or even 100 Mbps.)
Also, on the QoS egress interface, you might add "tx-ring-limit 3".
Lastly, keep in mind, ideally, you want QoS at every interface, but the one where it's most critical is the one that's a bottleneck for the end-to-end path.
