On Tue, Oct 17, 2017 at 08:38:21PM +0300, Александр Слободенюк wrote: > Hello again! > > I have checked (updated and fixed) the patch on BE machine (qemu-mips with > BE linux kernel, lscpu shows big endian): the CRCs of the sound are the > same: > > (first link was get directly from > http://www.mediafire.com/file/8agcdgs2f9kqlbi/submarine.dv) > wget > http://download1643.mediafireuserdownload.com/h3we3e4t26tg/8agcdgs2f9kqlbi/submarine.dv > wget https://trac.ffmpeg.org/raw-attachment/ticket/1589/A1590.dv > > ./ffmpeg -i submarine.dv audio-submarine.wav > ./ffmpeg -i A1589.dv audio-12bit.wav > > (I had to extract the audio out because with video CRCs are not the > same on BE and LE machines on master version of ffmpeg) > > ./ffmpeg -i audio-submarine.wav -f crc - 2>/dev/null > CRC=0x96b2ce8c > > ./ffmpeg -i audio-12bit.wav -f crc - 2>/dev/null > CRC=0x01c9318a > > ---------- > So, this CRCs are the same for all of the variants: > > - not patched ffmpeg on LE machine > - patched ffmpeg on LE machine > - not patched ffmpeg on BE machine > - patched ffmpeg on BE machine > ---------- > > Attaching the updated to current master patch.
> dv.c | 30 ++++++++++-------------------- > dvenc.c | 9 ++++----- > mov.c | 2 +- > version.h | 2 +- > 4 files changed, 16 insertions(+), 27 deletions(-) > 9e8192ee964aaf97bc14ab13f10718cf6bfd1e45 > 0001-avformat-dv-change-audio-format-endianess-to-BE.patch > From 4cdb0d8b79d91c94480c292847311e51f1b25704 Mon Sep 17 00:00:00 2001 > From: Aleksandr Slobodeniuk <alen...@yandex.ru> > Date: Tue, 17 Oct 2017 17:59:30 +0300 > Subject: [PATCH] avformat/dv : change audio format endianess to BE This does not explain why this change is done. does it fix a bug? does it make the code faster? The commit message should explain this > > --- > libavformat/dv.c | 30 ++++++++++-------------------- > libavformat/dvenc.c | 9 ++++----- > libavformat/mov.c | 2 +- > libavformat/version.h | 2 +- > 4 files changed, 16 insertions(+), 27 deletions(-) > > diff --git a/libavformat/dv.c b/libavformat/dv.c > index 06de044..df5fec0 100644 > --- a/libavformat/dv.c > +++ b/libavformat/dv.c > @@ -116,13 +116,13 @@ static const int dv_audio_frequency[3] = { > * 3. Audio is always returned as 16-bit linear samples: 12-bit nonlinear > samples > * are converted into 16-bit linear ones. > */ > -static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm, > +static int dv_extract_audio(const uint8_t *frame, uint16_t **ppcm, > const AVDVProfile *sys) > { > int size, chan, i, j, d, of, smpls, freq, quant, half_ch; > - uint16_t lc, rc; > + uint16_t lc, rc, *pcm; > const uint8_t *as_pack; > - uint8_t *pcm, ipcm; > + uint8_t ipcm; > > as_pack = dv_extract_pack(frame, dv_audio_source); > if (!as_pack) /* No audio ? */ > @@ -177,13 +177,9 @@ static int dv_extract_audio(const uint8_t *frame, > uint8_t **ppcm, > if (of * 2 >= size) > continue; > > - /* FIXME: maybe we have to admit that DV is a > - * big-endian PCM */ > - pcm[of * 2] = frame[d + 1]; > - pcm[of * 2 + 1] = frame[d]; > - > - if (pcm[of * 2 + 1] == 0x80 && pcm[of * 2] == 0x00) > - pcm[of * 2 + 1] = 0; > + pcm[of] = ((uint16_t*)frame)[d/2]; Divisions should be avoided in the inner loops as they can be slow [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel