[MPlayer-dev-eng] [PATCH] Zattoo

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Sat Mar 10 14:16:16 CET 2007


Hello,
On Sat, Mar 10, 2007 at 01:30:57PM +0100, Vladimir Serbinenko wrote:
> Nico Sabbi a écrit :
> > Vladimir Serbinenko wrote:
> >>
> >>> I also have some questions:
> >>> - what demuxer does this stream require?
> >>
> >> They use their own demuxer incorporating some ciphering (RSA+AES) and to
> >> ask the key it requires side query and you can't decipher without
> >> demuxing so I create matroska on the fly
> >>
> >>> - what's the content of this stream? matroska with some fixed codecs?
> >>>
> >>
> >> It's h264 and aac incapsulated in some kind of their own encapsulation
> >> and encryption format but when you do -dumpstream you receive matroska.
> >>
> >
> > stream readers may not demux, instead they should return stream data.
> > If you need to process the stream payload you should write an
> > appropriate demuxer (eventually a piped demuxer feeding its data to
> > DEMUXER_TYPE_MATROSKA/LAVF, but since you already know the format
> > I bet you can go on without this pipe) and in open() set
> > *file_format=DEMUXER_TYPE_ZATTOO
> 
> The point is that I don't like all the mess it would create because the
> big part of code is shared between stream parsing and login/address
> sessions+the need to transfer the keys. In such way I keep all the
> deciphering in one place

The login encryption and the data encryption keys do not seem to be in
any way related to me, so what exactly would make it so ugly to move all
that ztv_http_dispatch_packet does into the demuxer?

Greetings,
Reimar Döffinger

P.S.: __attribute__ ((packed)) is not portable.



More information about the MPlayer-dev-eng mailing list