Due to the poor user response, it seems that Channel 7 has, as I had predicted it would, partially done a backflip with 7flix’s audio.
That being said, if they were really nice, they should probably split out another 128kbit/s from the video stream and just change over to 192kbit/s MPEG-1 Joint-Stereo just to make sure everyone can hear it because there are quite a few sets which can deal with H.264 but not AAC-HEv2.
Gough Lui (February 29, 2016 at 8:47 pm)
As noted by some others who have found that they are now receiving audio on the service, there is now a second audio stream attached to 7flix which runs MPEG-1 Audio (PID 595) at 128kbit/s Joint-Stereo mode. The original AAC-HEv2 audio still continues on PID 594, but with reduced payload bitrate to ~48kbit/s from the original 64kbit/s.
The dump of the PMT from TSReader clearly shows this is the case:
Program Number: 76/1317 PCR on PID 593 (0x0251) PMT Version: 20 Service name: 7flix Logical channel number: 76 Stream Type: 0x05 ISO/IEC 13818-1 private_sections Elementary Stream PID 518 (0x0206) Stream Type: 0x1b H.264 Video Elementary Stream PID 593 (0x0251) Stream Type: 0x11 MPEG-4 Audio Elementary Stream PID 594 (0x0252) Stream Type: 0x03 MPEG-1 Audio Elementary Stream PID 595 (0x0253) Stream Type: 0x06 Teletext/VBI Elementary Stream PID 596 (0x0254) Stream Type: 0x0b ISO/IEC 13818-6 type B Elementary Stream PID 665 (0x0299)
… when combined with the “spot” bitrates, as I haven’t the time to spend on a full analysis:
On the whole, bitrate allocation seems fairly similar, although it seems 7mate may have lost a tiny amount to make this happen, rather than 7flix shaving its generous H.264 video bitrate.