DV stream: PCM audio shown as BIG Endian (but ffprobe/vlc say LITTLE)

[pjotrek-b]

For raw DV streams (captured over firewire), I've noticed that MediaInfo shows the PCM audio byte-order as "Big Endian", whereas ffprobe or VLC say "Little Endian" (MPV says "pcm_s16le" too, but output seems to be 1:1 from ffmpeg).

I usually believe MediaInfo to be the main authority of "AV Tech-MD truth", so who's right in this case? 😁

I've tried with several different DV samples (captured even years apart on different systems).
Here's a sample output from an identical file, on Mediainfo, ffprobe and VLC.

Mediainfo (v24.01)

Audio #1
ID                                       : 0
Format                                   : PCM
Format settings                          : Big / Signed
Duration                                 : 9 s 360 ms
Bit rate mode                            : Constant
Bit rate                                 : 768 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 32.0 kHz
Bit depth                                : 12 bits
Stream size                              : 878 KiB (3%)

ffprobe (git main today)

  Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 28800 kb/s, 60k fps, 25 tbr, 60k tbn
  Stream #0:1: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
  Stream #0:2: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s

VLC

Stream 1:
  Codec: PCM S16 LE (s16l)

[JeromeMartinez]

It is hardcoded as Big Endian for DV, I don't remind well why. @dericed do you know more about that? Else I check the spec and/or do some tests about endianess of DV.

[pjotrek-b]

I couldn't find anything about the endianess of DV itself (quickly), and neither of the following articles mentions anything about endianess too (just "PCM"):

https://www.ietf.org/rfc/rfc3189.txt
https://www.loc.gov/preservation/digital/formats/fdd/fdd000183.shtml
https://en.wikipedia.org/wiki/DV_(video_format)

[dericed]

It's in the specification at http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf. It's probably in the 61883 spec to but I don't have it on hand. For s314m see section 4.6.2.2 in particular and the table 8. It can also be inferred from the examples in 4.6.2.1.3.

I suspect that libavcodec is reporting on how it handles it rather than how it is. For instance the audio you cite is not 16 bit in addition to not being little endian, but that's how it comes out of the decoder. Similarly ffmpeg will give v210 a pixel format of yuv422p10le, when it's not planar, rather than call it UYVYVYVYUYUY10le.

[pjotrek-b]

Roger that.
So generally, MediaInfo is actually the only tool right now that knows DV-audio endianess spec-correctly?
And ffmpeg doesn't even show the bits-per-sample right (for 12bit 32kHz for example)?

[dericed]

On Feb 5, 2024, at 4:53 AM, Peter B. ***@***.***> wrote: Roger that. So generally, MediaInfo is actually the only tool right now that knows DV-audio endianess spec-correctly? And ffmpeg doesn't even show the bits-per-sample right (for 12bit 32kHz for example)?

I think ffmpeg is trying to say what is coming out of the decoder, rather than what goes in. There’s no 12 bit sample formats defined, so the 16 bits is the closest. Also the 12 bit audio there isn’t just like the first 12 bits of what would be a 16 value but it’s a mapping of the 12 bit values to some 16 bit values.