The problem with that approach, as I see it, is that you’ll need to use the Programmable Realtime Units (PRUs) in the BBB, if you want any sort of predictable PWM control behavior. The Linux OS inside the BBB is not a “real time OS” in the sense that the kernel isn’t pre-emptive. So this basically means that if the kernel needs the processor and is doing something, then your code is not guaranteed to run in a predictable amount of time. The two PRUs on the BBB are what TI intends for you to use to give an independent means to “farm out” the PWM control–so that the main CPU doesn’t have to. And the problem with that, at least in my (limited) experience with the PRUS…is that they aren’t all that easy to program. LOL.
So the other option is to use a peripheral microcontroller such as the Arduino. The BBB simply sends the Arduino a message to effect some change in the PWM signal, and lets the Arduino’s processor do the work. It’s still not “real time” because it’s the same (non-preemptive) Linux kernel. However you only have to pass a few bytes of control data to the Arduino…and that shouldn’t be a big deal. The other thing is that there’s only a single processing core in the BBB’s CPU, so any time-slicing of work will still need to be run on the same processor. Contrast this with something like the new Raspberry Pi Generation 2 board, that has an ARM7-based quad-core CPU.
Anyway, it might not be as easy as you think to do what you want. You also must use a camera that encodes the video on its own–like a Logitech Pro C920, just as an example. That does h.264 encoding, so the BBB doesn’t have to–which is a good thing, as it doesn’t have a GPU (unlike the RPi which does).
Hope this information helps clarify things for you, at least to the level of understanding that I have.