[FFmpeg-devel] [PATCH]Do not detect mpegts-in-mov as mov

[Michael Niedermayer]

On Mon, Oct 22, 2012 at 11:19:44PM +0200, Carl Eugen Hoyos wrote:
> On Monday 22 October 2012 05:07:19 pm Michael Niedermayer wrote:
> > On Mon, Oct 22, 2012 at 02:36:34PM +0000, Carl Eugen Hoyos wrote:
> > > Michael Niedermayer <michaelni <at> gmx.at> writes:
> > > > On Mon, Oct 22, 2012 at 11:11:53AM +0200, Carl Eugen Hoyos wrote:
> > > > > Hi!
> > > > >
> > > > > Attached patch fixes ticket #987 for me.
> > > >
> > > > please check for mpegts like its done for mpegps OR remove the mpegps
> > > > code and adjust the scores if this is possible. But dont mix the 2
> > > > approuches
> > >
> > > mpeg-ts in mov start with a mdat atom, apart from that there is nothing
> > > that reminds me of a mov (no other atom iirc). Both sample files we have
> > > are detected by the mpegts probe code with a score of 100 when testing
> > > 2048 bytes. But the mov detection is "quicker" although the files cannot
> > > be read at all, only an error message is shown on ffmpeg -i input
> > >
> > > mpeg-ps in mov are real mov files with all kinds of atoms describing the
> > > files and the mov demuxer was always able to read the files (it just
> > > couldn't actually decode them).
> > >
> > > I don't think the same approach can be used for both type of strams.
> >
> > mdat is the only atom you can depend on in some movs,
> > fate-suite/iv32/cubes.mov is one example (if you assume its bigger
> > so its end is unavailable in the probe buffer)
> >
> > but the mdat atom is quite invalid, its size for example looks quite
> > impossible. skiping such invalid atoms in building the score is fine
> > and should i think fix the tciket too
> 
> New patch attached.
> 
> Please comment, Carl Eugen

>  mov.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 8485aaae48ee072ed79cd83f4edfa25a325f29ae  patchmovsize.diff
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ce4865d..f3ba59c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2879,7 +2879,11 @@ static int mov_probe(AVProbeData *p)
>          case MKTAG('p','n','o','t'): /* detect movs with preview pics like ew.mov and april.mov */
>          case MKTAG('u','d','t','a'): /* Packet Video PVAuthor adds this and a lot of more junk */
>          case MKTAG('f','t','y','p'):
> -            score  = AVPROBE_SCORE_MAX;
> +            if (AV_RB32(p->buf+offset) >= 8) {
> +                score = AVPROBE_SCORE_MAX;
> +            } else {
> +                score = FFMAX(score, AVPROBE_SCORE_MAX - 50);
> +            }

size == 1 indicates a 64bit sized atom
the 64bit size has to be checked too in that case

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121023/6c601431/attachment.asc>