In testing iOS Posterframes with NGRP playlists, I have found that these do not work as I would expect them to. Not sure if this is by design, or just a bug, and I was hoping to have some light shed on the behavior. I expected that while using an NGRP playlist, when my mediaplayer recognized that there was insufficient bandwidth, it will jump down to the 50K audio only stream and display the iOS Posterframe image. I tested this by dowloading the ts chunk from a live playlist and running it through hexdump. thets chuck that I receive when I curl something like:

http://streamingserver.com:1935/app0...wowzaaudioonly

I can see the JFIF header in the hexdump of a chunk from the above playlist:

calvin:~ gcard$ hexdump -C wowza.aac.works | less
00000000  49 44 33 04 00 00 00 00  00 3f 50 52 49 56 00 00  |ID3......?PRIV..|
00000010  00 35 00 00 63 6f 6d 2e  61 70 70 6c 65 2e 73 74  |.5..com.apple.st|
00000020  72 65 61 6d 69 6e 67 2e  74 72 61 6e 73 70 6f 72  |reaming.transpor|
00000030  74 53 74 72 65 61 6d 54  69 6d 65 73 74 61 6d 70  |tStreamTimestamp|
00000040  00 00 00 00 01 7b 96 f9  20 49 44 33 04 00 10 00  |.....{.. ID3....|
00000050  00 6e 34 41 50 49 43 00  00 6e 2a 00 00 03 69 6d  |.n4APIC..n*...im|
00000060  61 67 65 2f 6a 70 65 67  00 10 00 ff d8 ff e0 00  |age/jpeg........|
00000070  10 4a 46 49 46 00 01 02  00 00 64 00 64 00 00 ff  |.JFIF.....d.d...|
00000080  ec 00 11 44 75 63 6b 79  00 01 00 04 00 00 00 32  |...Ducky.......2|
00000090  00 00 ff ee 00 0e 41 64  6f 62 65 00 64 c0 00 00  |......Adobe.d...|
000000a0  00 01 ff db 00 84 00 08  06 06 06 06 06 08 06 06  |................|
000000b0  08 0c 08 07 08 0c 0e 0a  08 08 0a 0e 10 0d 0d 0e  |................|
000000c0  0d 0d 10 11 0c 0e 0d 0d  0e 0c 11 0f 12 13 14 13  |................|
000000d0  12 0f 18 18 1a 1a 18 18  23 22 22 22 23 27 27 27  |........#"""#'''|
When I look at the ts chunk from the NGRP playlist, even with audioonly specified, http://streamingserver.com:1935/app0...wowzaaudioonly

calvin:~ gcard$ hexdump -C wowza.aac | less
00000000  49 44 33 04 00 00 00 00  00 3f 50 52 49 56 00 00  |ID3......?PRIV..|
00000010  00 35 00 00 63 6f 6d 2e  61 70 70 6c 65 2e 73 74  |.5..com.apple.st|
00000020  72 65 61 6d 69 6e 67 2e  74 72 61 6e 73 70 6f 72  |reaming.transpor|
00000030  74 53 74 72 65 61 6d 54  69 6d 65 73 74 61 6d 70  |tStreamTimestamp|
00000040  00 00 00 00 01 7a 76 56  c6 ff f1 4c 80 0f 5f fc  |.....zvV...L.._.|
00000050  21 08 15 34 0d a2 e8 32  2e 21 04 12 d1 25 5c 81  |!..4...2.!...%\.|
00000060  40 ec 03 b1 f3 8e 29 41  8b 20 c2 6e d2 2f bf e8  |@.....)A. .n./..|
00000070  86 2f 13 c1 91 5d 6c 2d  8b 79 cb 67 b4 0e aa af  |./...]l-.y.g....|
00000080  59 f4 77 b3 65 bc 8c 0c  6c bf d4 0b 9d 60 81 2b  |Y.w.e...l....`.+|
00000090  bc c5 71 3c 2d a1 14 5b  09 9a fb 7a dc 95 e1 36  |..q<-..[...z...6|
000000a0  4b 38 2f 47 aa ca a0 c3  81 aa 09 d4 e4 f1 f5 80  |K8/G............|
000000b0  5d f6 ed 1c 40 9f 4e 8d  01 e0 7e 8b d3 f9 a0 00  |]...@.N...~.....|
000000c0  00 f8 47 ff f1 4c 80 10  df fc 21 08 15 14 52 82  |..G..L....!...R.|
000000d0  83 73 80 57 01 52 a0 92  49 20 8a 55 07 6f 68 be  |.s.W.R..I .U.oh.|
000000e0  1c 80 26 9b cb 50 89 59  d5 04 c3 ab af 7c ee 69  |..&..P.Y.....|.i|
000000f0  c2 1b 8b 02 c1 81 10 d1  21 d0 3f 80 a5 08 0a 5d  |........!.?....]|
00000100  55 3a 02 60 64 a7 7a 7c  d3 62 b4 9f 48 91 4e 6b  |U:.`d.z|.b..H.Nk|
00000110  64 9e 88 48 48 a3 8e 1f  ff ff 6c ac e9 16 bc 5d  |d..HH.....l....]|
As a side note, I had issue's with EXIF JPG's, they don't seem to work with the Wowza Server as an iOS Posterframe , at all. I did the same hexdump of the ts chunks while attempting to use a EXIF format JPG, and I don't see the EXIF headers in the chunks from either of the two above URL variants. As I said, I'm unclear whether or not both sets of behavior are expected, or if this is a bug and no one else happened to run across it. I appreciate any insight on this issue.

Thanks

Geoff