I was able to reproduce this and determine which thread is spinning.

New project, add one clip (AVCHD H.264 MPEG-TS 24mbps from Canon HF11). Put clip in Track #1. Drag time-cursor back and forth in the time-line until one core of the CPU hits 100% and stays there.

This happens whether or not audio is muted.

At the same time in a terminal I ran:

ps -em -o pcpu,lwp,stat,pid,tid,class,psr,wchan,args

The output related to openshot is:

62.0     - -    13243     - -     - -      /usr/bin/python -m pdb /usr/bin/openshot
 0.4 13243 Sl+      - 13243 TS    0 futex_ -
 0.0 13252 Sl+      - 13252 TS    0 futex_ -
 0.0 13254 Sl+      - 13254 TS    0 futex_ -
 0.0 13255 Sl+      - 13255 TS    0 futex_ -
 0.0 13453 Sl+      - 13453 TS    1 futex_ -
 0.2 13454 Sl+      - 13454 TS    0 futex_ -
 0.0 13455 Sl+      - 13455 TS    0 poll   -
63.0 13456 Rl+      - 13456 TS    0 -      -
 0.0 13457 Sl+      - 13457 TS    0 futex_ -

Note lightweight thread #13456 at 63% (2 cores =100% so that's 1 core at least)

With openshot running under gdb debugging I then interrupted the process (Ctrl+C) and listed the threads and compared that output:

(gdb) infor threads

(gdb) info threads
  59 Thread 0x7f29971b6950 (LWP 13457)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  58 Thread 0x7f29a2ff0950 (LWP 13456)  0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
  57 Thread 0x7f29a11e6950 (LWP 13455)  0x00007f29bce76496 in *__GI___poll (fds=0x346a890, nfds=2, timeout=332)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  56 Thread 0x7f29a1bec950 (LWP 13454)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  55 Thread 0x7f29979b7950 (LWP 13453)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  4 Thread 0x7f29a39f8950 (LWP 13255)  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  3 Thread 0x7f29a41f9950 (LWP 13254)  0x00007f29bd9b7c95 in pthread_join (threadid=139816613935440, thread_return=0x0)
    at pthread_join.c:89
  2 Thread 0x7f29b11ae950 (LWP 13252)  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
* 1 Thread 0x7f29bddc26f0 (LWP 13243)  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85

Thread 58 in this case, so let's see where its at:

(gdb) thread 58
[Switching to thread 58 (Thread 0x7f29a2ff0950 (LWP 13456))]#0  0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
(gdb) bt
#0  0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
#1  0x00007f29ac5ff5c1 in ?? () from /usr/lib/libasound.so.2
#2  0x00007f29ac5ff9b7 in ?? () from /usr/lib/libasound.so.2
#3  0x00007f29ac63eb4a in ?? () from /usr/lib/libasound.so.2
#4  0x00007f29ac8c654c in ?? () from /usr/lib/libSDL-1.2.so.0
#5  0x00007f29ac89908e in ?? () from /usr/lib/libSDL-1.2.so.0
#6  0x00007f29ac8a0b77 in ?? () from /usr/lib/libSDL-1.2.so.0
#7  0x00007f29ac8e9e59 in ?? () from /usr/lib/libSDL-1.2.so.0
#8  0x00007f29bd9b73ba in start_thread (arg=<value optimized out>) at pthread_create.c:297
#9  0x00007f29bce7ffcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

So this looks like an audio renderer issue.

As this happens with audio muted too that suggests an additional 'bug':  maybe the "mute" side could do with optimising so it doesn't bother rendering muted audio.