AES-128 decryption in a separate worker

[mangui]

makes the decryption on a separate worker should decrease the CPU usage and improve the overall performance.

https://github.com/jcward/AS3-Worker-Compat

[mangui]

another optimization that should help playback on low-end platforms: c0284ea

[flavioribeiro]

Hi,

I've been working on this issue and have some results. I couldn't handle progressive downloading so I keep the segment and wait the download to be finished before move from side to side. I'm also facing a strange sync loss on the first bytes of the chunk (WARN:TS: lost sync between offsets:0/188) but it seems this doesn't affect user experience. @mangui , can you help on this?

The commit is here and it's possible to see it working on http://bem.tv/flashls

I'm planning to define a CONFIG::Worker to avoid size impacts on the current builds before I suggest a pull request. I'll make some Scout benchmarks also.

[mangui]

great !
most probably you have an issue with IV,refer to http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29

Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct. This is because a plaintext block can be recovered from two adjacent blocks of ciphertext.

[flavioribeiro]

I could reproduce the sync loss with HEAD so I think isn't a problem with the worker. Can you try to reproduce also with http://dev.movingbits.nl/playlist/testing/encrypted/index.m3u8?player_id=Testing123456789&public=true source?

[mangui]

indeed the sync loss issue is reproduced with flashls/master, but not with flashls/v0.1.1
I will check what is going on here.

[mangui]

Hi @flavioribeiro
I decrypted same playlist with an external tool, and I got same decrypted content.
in fact there is no IV referenced in http://dev.movingbits.nl/playlist/testing/encrypted/index.m3u8?player_id=Testing123456789&public=true. by default, IV is then assigned to be the fragment sequence number, according to http://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-5.2

If an EXT-X-KEY tag with a KEYFORMAT of "identity" does not have the
IV attribute, implementations MUST use the sequence number of the
media segment as the IV when encrypting or decrypting that media
segment. The big-endian binary representation of the sequence number
SHALL be placed in a 16-octet buffer and padded (on the left) with
zeros.

bad IV is affecting the decryption of the first 16 bytes. and the warning msg to be printed:
WARN:TS: lost sync between offsets:0/188

now why these warning traces are appearing now and not in previous releases ?

it is related to this commit 47d2efd: flashls now reuses demux instance when loading continuous segments of same level. as a consequence continuity counter issue at begining of TS fragment are now detected ;-) previously this was skipped by the probe() function.

and why it has no impact on playback ? usually first TS packet is PAT. PAT is repeated multiple times in the fragment. once PAT is subsequently found, parsing restart @ beginning of TS fragment ... so nothing is lost.

[flavioribeiro]

Awesome. Thank you for sharing all this information. Since #103 was opened, I'm curious about FlasCC and I will wait for the PR before continue on the refactory of AES.as as we talked few days ago.

[mangui]

no issue, I will do some refactoring in AES.as and try to incorporate your changes

[flavioribeiro]

hi @tecteun, do you have plans to integrate your tecteun/faest here? If not so, I can try to work on that.

[tecteun]

:) why workers? The lib is so fast, 60 mb/s on an older q6600 Intel. Single thread...
On Flávio Ribeiro [email protected], 21 Aug 2014 17:39 wrote:hi @tecteun, do you have plans to integrate your tecteun/faest here? If not so, I can try to work on that.

—Reply to this email directly or view it on GitHub.

[flavioribeiro]

@tecteun yeah, what I mean is if you're planning to integrate faest on flashls by yourself or you need some help on this.

[tecteun]

I think most of the work is already done, but I am also short on time, so if you can pick up some work, please do!
On Flávio Ribeiro [email protected], 21 Aug 2014 22:47 wrote:@tecteun yeah, what I mean is if you're planning to integrate faest on flashls by yourself or you need some help on this.

—Reply to this email directly or view it on GitHub.

[tecteun]

Owww. I see, this is a different codebase...
I guess you only need to implement Faest.swc and the HTTPStreamingDecoder class.

[tecteun]

In my branch AES decryption isnt the bottleneck, instead it is the video PES/NAL parsing. So it makes more sense to implement PES/NAL parsing in FlasCC too.