[FFmpeg-user] Failure: No wav codec tag found

[Carl Eugen Hoyos]

Am Sa., 18. Apr. 2020 um 18:15 Uhr schrieb Carl Zwanzig <cpz at tuunq.com>:
>
> On 4/18/2020 3:30 AM, Carl Eugen Hoyos wrote:
> > Am Sa., 18. Apr. 2020 um 02:07 Uhr schrieb Mark Filipak
> > <markfilipak.windows+ffmpeg at gmail.com>:
> >>
> >> Never mind. MPV was able to tell me that the pcm_bluray is big endian.
> >
> > While this is technically true, note that it has absolutely no relevance
> > for users of FFmpeg (including library users).
>
> That info -is- potentially useful to ffmpeg users and was something at least
> I did not know yesterday. And the thread is relevant because it tells me
> something that ffmpeg does not do, so I won't ask it to.

Again: It is technically true that pcm_bluray stores data big-endian-wise.
This information was (very) important ten years for the developer who
implemented pcm_bluray support in FFmpeg, it may still be interesting
to curious people (and there is nothing wrong asking about it).
The fact that pcm_bluray stores data big-endian-wise is completely
irrelevant when you use FFmpeg, neither when you use the command
line application "ffmpeg" nor when you use libavcodec.
(The big-endian fact has no relevant effect, no matter the hardware
you are using nor the output format. The only effect is that the
extremely fast "decoding" of pcm_bluray is in theory for some input
files faster on big-endian hardware than on little-endian hardware,
this will be difficult to prove because of the very high decoding speed
of pcm codecs in general.)

And since there were indications in this mailing list thread that the
following is not completely obvious: From FFmpeg's pov, the pcm
codecs are audio codecs just like mp3, aac or alac. The fact that the
pcm codecs are not compressing data made implementing them
(much) easier but when you are using a pcm codec (for decoding or
encoding), the usage is exactly the same as if the codec would
compress data.

Carl Eugen