Support "twos" codec (big endian PCM)

[tuesda]

[REQUIRED] Content description

got from ffprobe:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/zhanglei/Downloads/C0009.MP4':
Metadata:
major_brand : XAVC
minor_version : 16785407
compatible_brands: XAVCmp42iso2
creation_time : 2019-04-19T13:58:09.000000Z
Duration: 00:00:04.80, start: 0.000000, bitrate: 55933 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/iec61966-2-4), 1920x1080 [SAR 1:1 DAR 16:9], 51451 kb/s, 50 fps, 50 tbr, 50k tbn, 100 tbc (default)
Metadata:
creation_time : 2019-04-19T13:58:09.000000Z
handler_name : Video Media Handler
encoder : AVC Coding
Stream #0:1(und): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, 2 channels, s16, 1536 kb/s (default)
Metadata:
creation_time : 2019-04-19T13:58:09.000000Z
handler_name : Sound Media Handler
Stream #0:2(und): Data: none (rtmd / 0x646D7472), 409 kb/s (default)
Metadata:
creation_time : 2019-04-19T13:58:09.000000Z
handler_name : Timed Metadata Media Handler
timecode : 00:06:13:46

[REQUIRED] Link to test content

send to dev.exoplayer@gmail.com

[REQUIRED] Version of ExoPlayer being used

2.9.6

[REQUIRED] Device(s) and version(s) of Android being used

multi devices can reproduce this issue

[ojw28]

Samples are 16 bit PCM, but with big endian byte order. This means it's necessary to swizzle the bytes in each sample. E.g.

[1,2,3,4,5,6] -> [2,1,4,3,6,5]

Is there any way to get this swizzling done in the platform. For example under AudioTrack (I guess it could also be done in the raw decoder, but I think there's a separate plan to bypass it so maybe that doesn't help?). If not, would it be worth suggesting this as an enhancement to the platform team, so we don't have to swizzle in Java?

If there's no existing way to swizzle in the platform, feel free to assign this back and I can take a look at the Java level swizzle. Or take a look directly. If assigning back, some guidance on where this would be best done would be appreciated!

[andrewlewis]

I think the best way to handle this is to integrate support for swizzling into ResamplingAudioProcessor. We'd need to add additional ExoPlayer-side PCM audio format constants for big endian input and set those as appropriate in the WavExtractor.

Swizzling can probably be done quite easily by copying between ByteBuffers with the relevant byte orders set (though I'm unsure whether this can be done without instantiating a new byte buffer view on each call to queue input, which might be a concern for GC on older Android versions).

I think the ByteBuffer operations are implemented efficiently, and, compared to option of supporting big endian input with AudioTrack, this seems preferable because we can handle all API versions, we don't need to complexity of handling an additional output format and existing audio processing (like speed adjustment) will just work without any changes.

Longer term, adding support to AudioTrack may be useful to other apps but IMO it seems like it'd be a lot of work for a niche feature.

[ojw28]

Fixed in dev-v2.