[FFmpeg-devel] [PATCH] RTSP-MS 14/15: ASF packet parsing
Sat Apr 18 02:35:32 CEST 2009
On Fri, Apr 17, 2009 at 06:59:50PM -0400, Ronald S. Bultje wrote:
> On Fri, Apr 17, 2009 at 5:43 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Fri, Apr 17, 2009 at 05:25:28PM -0400, Ronald S. Bultje wrote:
> >> On Fri, Apr 17, 2009 at 5:10 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > we should undo the exporting of ff_asf_get_packet()
> >> I sort of expected that.
> > good, so if you are aware of it being a bad idea why did you even start
> > on that path?
> I didn't say that. I think it's the right way. I could see it coming
> that you don't.
Its not the right way, and that simply is because parts should be seperated
by clear and simple APIs not random parts calling internal functions from
One could make exceptions if there is some advantage in speed or otherwise
but thats all not the case here.
> >> Over the past few emails, you've been telling me that:
> >> 1) ASF over RTP is not "ASF" compliant, similar to h263, and you're
> >> rejecting my code that makes the ASF demuxer handle this "stream"
> > your patches made clear that the min packet size is not honored in these
> > streams.
> > there are many solutions, but bypassing the common api or randomly placing
> > if(rtp) or if(eof which is equivalent top rtp) somewhere is not acceptable
> > let me explain it that way, if you dump the stream that you feed to the asf
> > demuxer to a single file and this cannot be subsequently demuxed with full
> > seeking and error recovery then you did something wrong.
> > a h263 rtp demuxer also MUST fix the stream before passing it to a h263
> > decoder. it cant just call the decode_block() bypassing the decode_header()
> > that would fail due to a misplaced byte.
> So you want an ASF "interpreter" in rtp_asf.c? Or you want me to read
> the min_pktsize from ASFDemuxContext and fill an extra buffer with
> zeroes after every packet end to conform min_pktsize?
I dont want a rtp demuxer in asfdec.c
if you have a asf file and want to send that over rtp, you have to change
things to conform to the recommanditions of the specs.
the rtp-asf demuxer must do the reverse you cant just put half of the code
if zero padding has to be added or not depends primarely on one question
and that is if our asf demuxer supports non padded packets or not.
If it does not you of course can change the asf demuxer to support such
packets instead of adding the padding if you prefer.
But i repeat to the 3rd (i think) time that you cannot add a
if(rtp) check in the asf demuxer, this bypasses the public API and
results in an entangled and unmaintainable mess.
> >> Just FYI, if I dump the RTP payload data to a file, as mentioned
> >> before, it does _not_ play back with the current ASF demuxer, because
> > as expected but does it play with the official demuxer from M$ ?
> > or mplaye/vlc/xine?
> They don't even open it, I have no idea why,
ahh, but i have one, its not a valid asf file.
> there's no stdout/err
> output or error message. I tried VLC, WMP and Quicktime with the
> flip4mac (WMV for Quicktime, recommended by MS) plugin. No messages on
> the commandline, nothing, for none of them, they all have an empty
> playlist although they load the metadata of the stream. Like I said,
> no idea why.
> Mplayer is slightly more verbose and claims there's PCM data in the file:
mplayer still can play everyting :))
> Playing /tmp/strm.asf.
> ASF file format detected.
> [asfheader] Audio stream found, -aid 1
> [asfheader] Audio stream found, -aid 2
> [asfheader] Audio stream found, -aid 3
> [asfheader] Audio stream found, -aid 4
> ASF: No audio stream found -> no sound.
> Clip info:
> name: Absolute Radio - LIVE from London, UK
> author: Virgin Radio
> copyright: TIML Radio Ltd
> comments: Absolute Radio - LIVE from London, UK
> Opening audio decoder: [pcm] Uncompressed PCM audio decoder
> AUDIO: 44100 Hz, 2 ch, s16le, 96.0 kbit/6.80% (ratio: 12003->176400)
> Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
> Which is totally ridiculous. So let's disregard mplayer for now...
> > anyway could you elaborate on what is needed to convert RDT/SDP to RM?
> Let's do that in a separate thread, this'll be a long one.
perfectly fine with me
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel