[Ffmpeg-devel] [RFC/Patch] native mms code...

Michael Niedermayer michaelni
Fri Jan 5 21:23:47 CET 2007


Hi

On Fri, Jan 05, 2007 at 11:36:15AM -0600, Ryan Martell wrote:
[...]
> >all strings in ffmpeg are supposed to be utf-8 so the name  
> >convert_to_unicode
> >is wrong, it rather should be something like convert_utf8_to_utf16  
> >and should
> >use GET_UTF8() (unless you know that the input will be ASCII)
> 
> Is there an example of unicode conversion in the code base?  I really  
> didn't know how to do this (or even if there was some library  
> function), so I just punted and did it a simple way.  I didn't want  
> to get hung up on the conversion....

see ascii_to_wc() in mov.c


> 
> >>
> >>static void generate_guid(char *dst)
> >>{
> >>    char digit[]= "0123456789ABCDEF";
> >>    int ii;
> >>
> >>//    srandom(time(NULL));
> >>    for(ii= 0; ii<36; ii++)
> >>    {
> >>        switch(ii)
> >>        {
> >>            case 8:
> >>            case 13:
> >>            case 18:
> >>            case 23:
> >>                *dst++= '-';
> >>                break;
> >>
> >>            default:
> >>                *dst++= digit[random()%(sizeof(digit)/sizeof(digit 
> >>[0]))];
> >
> >random() must not be used in libraries as it changes the user  
> >applications
> >state, think of:
> >
> >thread1:
> >srandom(123);
> >A=random();
> >
> >thread2:
> >mms_demux();
> 
> The networking model in some of the games I worked on used  
> deterministic random to keep all the machines in sync, so I'm  
> definitely aware of the problem.  Should I roll my own random, or  
> maybe add an internal random to ffmpeg?

a LFG or mersenne twister based av_random() for libavutil would certainly
be welcome see the pseudeocode on http://en.wikipedia.org/wiki/Mersenne_twister
and http://svn.mplayerhq.hu/ac3/ac3_decoder.c?revision=23&view=markup


[...]

> >[...]
> >>static int mms_read_packet(AVFormatContext *s,
> >>                            AVPacket *pkt)
> >>{
> >>    MMSState *mms = s->priv_data;
> >>    int result= 0;
> >>
> >>//    fprintf(stderr, "mms_read_packet!\n");
> >>
> >>    if(mms->state==STREAMING || mms->state==STREAM_PAUSED || mms- 
> >>>state==AWAITING_STREAM_START_PACKET)
> >>    {
> >>//        result= ff_asf_read_packet(s, pkt, &mms->asf_context,  
> >>&mms->current_media_packet_context, load_packet, mms);
> >>//        result= ff_asf_read_packet(s, pkt, &mms->asf_context,  
> >>&mms->av_format_ctx->pb, load_packet, mms);
> >>        result= ff_asf_read_packet_with_load_proc(s, pkt,  
> >>load_packet, mms);
> >
> >isnt it possible that the mms AVInputFormat provides the asf  
> >AVInputFormat
> >with a valid asf stream instead of this callback to get the next  
> >packet?
> 
> I was trying to do that initially, but i ran into lots and lots of  
> url_ftell's in the asf code, that were causing it to error out.  by  
> putting the packet load as a separate call, i could make sure the  
> ftell's would be valid, and the code would continue.  The asf code is  
> really pretty dependent on it being file based.
> 
> But, I'm not the expert on working with this code base; if anyone can  
> give me any suggestions on how to further separate these, I'd  
> appreciate them.  I'm not exactly sure what you mean by providing the  
> asf AVInputFormat with a valid asf stream; all that the asf stuff  
> does is read from the ByteIOContext.

hmm, so what about providing the asf demuxer with a ByteIOContext?
a simple fixed size buffer + a read_packet function passed to
init_put_byte() might work ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070105/b2da9c6e/attachment.pgp>



More information about the ffmpeg-devel mailing list