Hello, On Wed, Jan 10, 2007 at 01:45:55PM +0100, Baptiste Coudurier wrote: > Reimar D?ffinger wrote: > > attached patch would at least allow dumping of encrypted streams with > > MPlayer's -dumpvideo/-dumpaudio. > > This is not too useful and a bit hackish (since there is no indication > > whether we have an encrypted stream or not), but on the other hand it > > still seems like an improvement over the current treatment (mxf_read_header > > parses the file until EOF). > > > > Greetings, > > Reimar D?ffinger > > > > [...] > > > > @@ -1062,7 +1065,8 @@ > > seconds = av_rescale(sample_time, st->time_base.num, st->time_base.den); > > url_fseek(&s->pb, (s->bit_rate * seconds) >> 3, SEEK_SET); > > if (!mxf_read_sync(&s->pb, mxf_essence_element_key, 12)) > > - return -1; > > + if (!mxf_read_sync(&s->pb, mxf_enc_essence_element_key, 12)) > > + return -1; > > > > /* found KLV key */ > > url_fseek(&s->pb, -12, SEEK_CUR); > > > > That won't work since mxf_read_sync will always match essence element > key since it is present within encrypted triplet, and mxf_read_sync will > read until EOF is reached, so you need to seek back (yes that's a bit ugly). Hmmm... I had the impression that my sample does not use the encrypted-tripled encryption as specified by SMPTE-429-6... I will look again though. > I would prefer to use mxf_encrypted_triplet_key like in specs, and it is > a complete key (16 bytes) according to specs. I'll search if the file contains any such key, but at least the dumped track does not contain any of the keys in that spec, I searched for them. If there is a mxf_encrypted_triplet_key somewhere I'll try to use that though. Greetings, Reimar D?ffinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4