[FFmpeg-devel] [PATCH] Detect DTS in wav (issue70) ??????+?about?ac3-in-wav

[Michael Niedermayer]

On Thu, Aug 19, 2010 at 04:51:02PM +0300, Anssi Hannula wrote:
> On Thursday 19 August 2010 13:03:03 Michael Niedermayer wrote:
> > On Thu, Aug 19, 2010 at 05:48:47AM +0300, Anssi Hannula wrote:
> > > On Wednesday 18 August 2010 20:55:30 Michael Niedermayer wrote:
> > > > On Wed, Aug 18, 2010 at 04:19:40PM +0300, Anssi Hannula wrote:
> > > > > On Wednesday 18 August 2010 13:33:11 Michael Niedermayer wrote:
> > > > > > On Wed, Aug 18, 2010 at 08:24:58AM +0300, Anssi Hannula wrote:
> > > > > > > On Wednesday 18 August 2010 07:29:15 Anssi Hannula wrote:
> > > > > > > > On Tuesday 17 August 2010 15:26:52 Michael Niedermayer wrote:
> > > > > > > > > i meant that the code is a mess and id like it to be simpler.
> > > > > > > > 
> > > > > > > > Attached is a completely different simpler approach, then.
> > > > > > > > Since we are about to do the
> > > > > > > > lower-wav-score-for-s16le-files-if-small-buffer trick anyway
> > > > > > > > for the spdif-in-wav files, attached patch does the same for
> > > > > > > > dts- in-wav, marking such files as raw dts.
> > > > > > > > 
> > > > > > > > Better?
> > > > > > 
> > > > > > no, its still a mess
> > > > > 
> > > > > So it is worse than the fallback_id one?
> > > > 
> > > > i dont know, ive not seen a clean implementation of either solution yet
> > > > 
> > > > > > everything looks much more complex than it should be and its not
> > > > > > clear at all why the changes are done.
> > > > > 
> > > > > Ok.
> > > > > 
> > > > > > a patch touching probe functions from 2 seperate formats is already
> > > > > > quite suspect.
> > > > > > if dts detection is not good enough it can be improved in a
> > > > > > seperate patch
> > > > > > and each improvement should be seperate and be justified
> > > > > > for example why do you add such huge amounts of code, is the dts
> > > > > > detection failing for you?
> > > > > 
> > > > > The current dts detection returns AVPROBE_SCORE_MAX/2+1 on match,
> > > > > which won't be enough to top wav's AVPROBE_SCORE_MAX-1.
> > > > 
> > > > but your patch reduced wavs score IIRC
> > > 
> > > Only for small probe buffers. If the probe buffer is large enough, wav
> > > still returns AVPROBE_SCORE_MAX-1 (otherwise wav probe would need
> > > maximum probe buffer, which we obviously do not want).
> > > 
> > > > > The added code allows dts probe to return AVPROBE_SCORE_MAX when dts
> > > > > markers are found with intervals which makes the stream bitrate match
> > > > > PCM bitrate (and thus transmittable in standard pcm wav / audiocd).
> > > > 
> > > > what does a pcm wav bitrate have to do with dts detection?
> > > 
> > > Well, I think it is more likely to be a dts file if there are a couple of
> > > dts marks found at a regular intervals (that make it match pcm bitrate)
> > > than if there are a couple of dts marks randomly there, no?
> > 
> > again what does pcm bitrate has to do with this or what even is pcm bitrate
> > in the context of dts?
> 
> It is the bitrate of a 16-bit stereo PCM stream. The effective stream bitrate 
> of a DTS stream placed in cd/wav has to match this, as the intent is that e.g. 
> a dumb standard CD player can play the DTS track at normal speed and then 
> directly feed the audio via s/pdif to an A/V receiver that then decodes the 
> DTS stream.
> The bitrate can't be higher or lower as the CD player reads data at a constant 
> speed.
> 
> (this is practically the same as iec61937 encapsulation (our "spdif" 
> muxer/demuxer), just without the iec61937 headers)

so if the dts bitrate matches that pcm wav bitrate the score returned by
dts_probe should be decreased as its possible to be wav instead of dts
i dont remember the patch doing that though

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100820/5a4e156a/attachment.pgp>