[FFmpeg-devel] [PATCH] Detect DTS in wav (issue70) ???????+?about?ac3-in-wav
Michael Niedermayer
michaelni
Mon Aug 23 15:58:23 CEST 2010
On Fri, Aug 20, 2010 at 08:11:31PM +0300, Anssi Hannula wrote:
> On Friday 20 August 2010 02:31:33 Michael Niedermayer wrote:
> > 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
>
> The idea of that patch is that dts-in-wav is detected as raw dts, similar to
> how spdif-in-wav is detected as plain spdif (as soon as I finish that spdif
> demuxer patch).
we both talk about different things. like what vs why
I think to resolve this pointless discussion the patch should first be split
into changes to dts probe and a seperate patch in seperate thread to wav probe.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20100823/4df5b77f/attachment.pgp>
More information about the ffmpeg-devel
mailing list