On Thu, Aug 30, 2018 at 8:43 AM Jacob Trimble <modma...@google.com> wrote: > > On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > > > On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote: > > > On Wed, Aug 29, 2018 at 3:20 PM James Almer <jamr...@gmail.com> wrote: > > > > > > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > > > > >> If a packet is full-sample encrypted, then packet data can't be > > > > >> parsed > > > > >> without decrypting it. So this skips the packet parsing for those > > > > >> packets. If the packet has sub-sample encryption, it is assumed that > > > > >> the headers are in the clear and the parser will only need that info. > > > > >> > > > > >> Signed-off-by: Jacob Trimble <modma...@google.com> > > > > >> --- > > > > >> libavformat/utils.c | 21 ++++++++++++++++++++- > > > > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > Hmm, please correct me if iam wrong but IIUC > > > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a > > > > > parser > > > > > > There isn't a flag for "try parsing and ignore errors". So my choice > > > (from an app) is to either require parsing or don't do parsing at all > > > (which can result in incorrect timestamps). > > > > > > > > 2. Parsing cannot be done before decrypting > > > > > > > > > > If all this and the set values are correct, logically, the fix would > > > > > be > > > > > to decrypt the packet before the parser not to skip the parser. > > > > > > > > There are cases where the packet can't be decrypted before getting to > > > this point. > > > > Can you elaborate on these cases ? I dont think its obvious what these > > cases are, at least its not obvious to me what exactly you are thinking > > of here. And i think its not helpfull if i guess what you mean and then > > argue/comment on that because maybe you meant something entirely different > > ... > > Fair warning, I am working on a DRM solution. I know many of you may > not agree with DRM, but it is a requirement imposed by content > creators. FFmpeg doesn't have to support DRM itself, but you should > still consider its usages. > > At that point in the code, the packet can only be decrypted by the > demuxer. For example, in MP4 this can be done by passing the > -decryption_key parameter. But that requires that FFmpeg handle the > decryption. In my case, we are passing the packet to a CDM (content > decryption module) to handle the decryption and that might be a > hardware-secure decryptor. In most DRM situations, we can't get the > raw key at all, all we can do is say "decrypt this block of memory". > So the only way to have the packet decrypted before this point would > be to introduce a callback to the app to decrypt the packet. > > This is why I have been working on exposing the encryption info. My > app (or more correctly the CDM) needs to handle the decryption and we > can't just give the key to libavformat so the demuxer can decrypt the > packet. > > > > > > > > This point is between the demuxer creating the packet and > > > giving to the app. So the only way to decrypt the frame (as of now) > > > is for the demuxer to do this. There is no way for the app to handle > > > the decryption before this point. > > > > > > > > From the app's perspective, I would expect the packet to remain > > > encrypted for as long as possible. > > > > why ? > > Because the point of encryption is to ensure that nefarious parties > don't get access to the data. Even though the packet data is stored > in memory, it could still be retrieved by a malicious user. Usually > for protected media, the frames are only decrypted when needed and in > some cases are decrypted in a secure CPU and isn't even accessible to > the app. There are platforms that support what is called "direct > render" where the app gives the platform the encrypted packets and a > discrete hardware unit will decrypt the packet, decode it, and render > it directly; this happens on some smart TVs. There are also cases > which require decrypt-decode where we give the platform an encrypted > packet and it will decrypt and decode the packet, ensuring the > decrypted packet data is never in main memory. So there are cases > where we can't even see the encoded packet and decoding is handled by > the platform. > > > > > > > > My app will store the packet for a > > > while, then decrypt it right before passing it to the decoder and > > > drawing the frame. So requiring the packet to be decrypted at this > > > point is not ideal. > > > > > > > > > > > And if that can't be done, then the demuxer could perhaps set > > > > st->need_parsing to 0 and skip parsing altogether? > > > > > > I would want to still have parsing if possible. For example, a lot of > > > content has a clear lead where the first few seconds are clear. So > > > they could be used to adjust the starting timestamps (and whatever > > > parsing needs) and the encrypted content later can be deduced based on > > > that. > > > > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > Modern terrorism, a quick summary: Need oil, start war with country that > > has oil, kill hundread thousand in war. Let country fall into chaos, > > be surprised about raise of fundamantalists. Drop more bombs, kill more > > people, be surprised about them taking revenge and drop even more bombs > > and strip your own citizens of their rights and freedoms. to be continued > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Ping. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
