<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY> Le lundi 03 mars 2014 à 08:13 -0800, MartinK a écrit : <BLOCKQUOTE TYPE=CITE> 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 </BLOCKQUOTE> 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 </BODY> </HTML>