Decryptor Element Seeking

[Nicolas Dufresne]

Le lundi 03 mars 2014 à 08:13 -0800, MartinK a écrit :

> Hi. I have written an element that decrypts an encrypted video file.
> The encrypted file consist of a header block followed by an encrypted
> version of the original unencrypted file. The difference in size
> between the original file and the encrypted file is just the size of
> the header block. The decryptor element strips the header from its
> first buffer and pushes a new buffer out to its src pad. The new
> buffer is smaller than the input buffer by the size of the header
> block. All remaining output buffers are the same size as the input
> buffer. The input buffer is unreffed (discarded). The element works
> fine when playing the encrypted file right through. However, when
> seeking (using totem), the pipeline doesn't work (decoding errors). I
> tried handling the seek event and incrementing the Start field of the
> seek event by the header block size and then passing the event
> upstream to the source element. This didn't work though. Does anyone
> have any idea what I should do to get seeking to work properly for my
> decryptor element? Regards, Martin


It's an interesting problem. So I guess the demuxer has an index in
bytes, that is as if the stream is not encrypted. So it probably make
few assumptions that the data that comes back in after a seek is well
aligned. I would check the code where you translate the seek event
(through you need to translate both start and end). Obviously, make sure
you get seeks in bytes, otherwise all what I'm saying does not make
sense.

But I think translating the seeks is the right thing to do, but you
might not be doing it well enough, and you might not be using a parser
that could save you if you get it wrong.  The translation is dependent
on the way your stream is encrypted. So to give you more help, you'd
have to share more details. Information like if the encrypted blocks are
fixed size or per frame. If the encrypted blocks are fixed size the
offset would be offset + start / blocksize * header_size (opposite for
reverse playback). If it was frame base you need another solution.
Timestamp and framerate could do, since you could ask the demuxer to
convert the bytes start (or stop) to timestamp, calculate the number of
frames and then you'd know how many headers you'll have to add. If you
have to make a guess, then make sure you always seek before the point
you want to reach, and make sure you have parsers installed
(gst-plugins-bad).

If you already do that properly, then look for corruption after
decrypter. That could also be a problem.

cheers,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140303/8e92eac3/attachment.html>