DRM protected content should be detected

[Hendrik Schreiber]

AFAIK FFmpeg libraries contain no special code to recognize whether a file has been DRM protected e.g. by Apple's so-called "FairPlay". mp4 files are decoded and played - but the result is simply garbage.

It would be nice, if it was possible to detect whether a file is protected or not.
Please note, that I don't mean to suggest building a decoder (like ticket:1800). Instead, just knowing that we simply cannot decode a file properly is already valuable.

A possible implementation could be for avcodec_decode_audio4(...) to return an appropriate error code, if the packet is encrypted and therefore cannot be decoded properly.

For .m4p this is not hard to detect. It contains an atom called drms. If it is present, the file cannot be properly decoded. For WMA there seems to be also some sort of mechanism (see e.g. ​https://mail.kde.org/pipermail/taglib-devel/2011-March/001885.html).

Further resources for m4p are:

• ​http://atomicparsley.sourceforge.net/mpeg-4files.html
• ​http://www.cs.sjsu.edu/faculty/stamp/students/RamyaVenkataramu_CS298Report.pdf

To illustrate where to find the drms atom, here's an excerpt generated with AtomicParsely:

> AtomicParsley.exe test.m4p -T +
Atom ftyp @ 0 of size: 32, ends @ 32
Atom moov @ 32 of size: 98194, ends @ 98226
     Atom mvhd @ 40 of size: 108, ends @ 148
     Atom trak @ 148 of size: 39374, ends @ 39522
         Atom tkhd @ 156 of size: 92, ends @ 248
         Atom edts @ 248 of size: 36, ends @ 284
             Atom elst @ 256 of size: 28, ends @ 284
         Atom mdia @ 284 of size: 39238, ends @ 39522
             Atom mdhd @ 292 of size: 32, ends @ 324
             Atom hdlr @ 324 of size: 58, ends @ 382
             Atom minf @ 382 of size: 39140, ends @ 39522
                 Atom smhd @ 390 of size: 16, ends @ 406
                 Atom hdlr @ 406 of size: 57, ends @ 463
                 Atom dinf @ 463 of size: 36, ends @ 499
                     Atom dref @ 471 of size: 28, ends @ 499
                 Atom stbl @ 499 of size: 39023, ends @ 39522
                     Atom stsd @ 507 of size: 999, ends @ 1506
                         Atom drms @ 523 of size: 983, ends @ 1506
                             Atom esds @ 559 of size: 51, ends @ 610
                             Atom sinf @ 610 of size: 896, ends @ 1506
                                 Atom frma @ 618 of size: 12, ends @ 630
                                 Atom schm @ 630 of size: 20, ends @ 650
                                 Atom schi @ 650 of size: 856, ends @ 1506
                                     Atom user @ 658 of size: 12, ends @ 670
                                     Atom key  @ 670 of size: 12, ends @ 682
                                     Atom iviv @ 682 of size: 24, ends @ 706
                                     Atom righ @ 706 of size: 88, ends @ 794
                                     Atom name @ 794 of size: 264, ends @ 1058
                                     Atom priv @ 1058 of size: 448, ends @ 1506
                     Atom stts @ 1506 of size: 24, ends @ 1530
                     Atom stsc @ 1530 of size: 7756, ends @ 9286
                     Atom stsz @ 9286 of size: 27640, ends @ 36926
                     Atom stco @ 36926 of size: 2596, ends @ 39522
     Atom udta @ 39522 of size: 58704, ends @ 98226
         Atom meta @ 39530 of size: 58696, ends @ 98226
[...]

[Carl Eugen Hoyos]

Please test current FFmpeg git head and provide a command line and console output to make this a valid ticket.

[Hendrik Schreiber]

ffplay.exe output when "playing" m4p file. Sound is garbage.

[Hendrik Schreiber]

Are you suggesting, this may have been implemented already?

I've tried ffplay with today's zeranoe build (​http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20141008-git-f3296b9-win64-static.7z) and the audio output was garbage.

The textual output is attached.