we analyzed the last two days a very strange flash access problem with the latest Flashplayer 11.2 (final release web version, not mobile yet).
I would like to share this debug session with the flash access developers. I build an complete szenario where you can reproduce the problem.
Mac OSX Snow Leopard 10.7
Testfile (encrypted f4v file) packed with Auth in DRM Packager
http://onlinelib.de/tmp/output1.f4v (the same file as .mp4, but with file extension .f4v)
It seems that Flashplayer installed on OSX Safari and Windows IE8 and IE9 sees the http://onlinelib.de/tmp/output1.f4v as an FLV, the DRM flash access result code is 3309, this code means it is an corrupted flv. This is wrong, cause .f4v is an subset of mp4.
How to produce?
2) Enter as URL: http://onlinelib.de/tmp/output1.f4v
You will see that the result code is 3309 (in Safari OSX, IE 8 an 9)
You will see that the result code in Firefox is "File has invalid structure"
THE FILE IS NOT CORRUPT, ITS AN VALID MP4 FILE, ALL ATOMS AND FRAMES ARE CORRECT. THE FILE PLAYS FINE WITHOUT ANY ENCRYPTING IN FLASH.
When you now rename the .f4v to mp4 and try again this way:
2) Enter as URL: http://onlinelib.de/tmp/output1.mp4
Now everything works fine in all browsers and operating systems. The output1.mp4 file is the same file as .f4v, only reanme to from .f4v to .mp4.
I can fix the flash access packager where i insert an rename method from .f4v to mp4. Would you think?
the problem seems only when you work in HTTP CDN caching nodes. When the flashplayer connects to an big .f4v DRM protected file, it tries to read the DRM licenses out of the header. After some seconds the flash player disconnects the connection between the client and the HTTP caching node.
It seems when a http caching node takes to long btw. has too high latency then the flashplayer cant process the hole DRM license out of the header. I dont know this exactly and i dont know if there is maybe a too small timeout in the flashplayer.
To fix this, it might be usefull when you work with the DRM metadata instead of the hole .f4v. When you work with the .metadata, you have complete control over the loading state of the metadata DRM file. You can use an URLLoader for loading the .metadata and parse the result in a bytearray and from the bytearray the DRM Manager of the flashplayer to authenticate. It works quite well.
On the other side, i like this method from the point of security much better then the flashplayer is connecting to the hole .f4v / connect / disconnect.
You can store the metadata on server1, and the real .f4v on server XX / caching nodes. After sucess full authentication of the metadata drm file, you can then check in your database user,pass and geoIP and then transmitt the real URL of the original .f4v over an SSL connection.
The issue doesnt exists when you work in a RTMP CDN bye the way.
Hope this is usefull for some other flash access developer.
yes..thats also right, and not changeable cause the http caching nodes has fixed mine-types.
anyway..it was very easy to fix...everything works well now..i prefer the .metadata method instead of reading the DRM license from the .f4v header.