[FFmpeg-devel] [PATCH] RTSP-MS 14/15: ASF packet parsing

[Michael Niedermayer]

On Fri, Apr 17, 2009 at 05:25:28PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> 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?


> 
> It's fine, _but_ I would like to request you to be more helpful to get
> this working.

id love to but i dont know asf over rtp and only remember 2/3 of the
asf format


> 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.


> 2) However, I should handle it with the common API which requires that
> it is compliant
> 
> I've sent several patches that either use internal API to get it
> correct, or that fix the demuxer to handle this non-compliant stream.
> I need help from you in implementing an approach that works and that
> is acceptable for you to commit.

good so lets work together on this


> 
> 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?


[...]
> > Am i right in the assumtation that rm like asf could have been implemented
> > through the common AVInputFormat API ?
> 
> No.
> 
> It lacks most global and all packet headers and can thus not be parsed
> with common AVInputFormat API. (I remember having this discussion with
> you before...). RDT over RTSP is incomparable to to .RM files;
> however, the packet layout is similar between RDT/RTSP and .RM, which
> is why I share one function to descramble packet data, plus a caching
> function for the case where a descrambled packet contains multiple
> output packets. Also, the stream header in .RM files (part of the full
> .RM header) is similar to the private data in the SDP of RDT/RTSP
> streams, so that function is shared as well (parse_mdpr). In order to
> generate a .RM file from RDT/RTSP streams, I'd need to implement a
> complete .RM muxer in the RDT parser (see also mplayer, it takes this
> approach and is ugly)...

mplayers rm demuxer is IIRC one of the more nasty parts.

anyway could you elaborate on what is needed to convert RDT/SDP to RM?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

GMX, the mailprovider that uses RBL lists to reject mails from your friends
running their own mailserver at home. The mailprovider that obscures the
origin of mails (mis)identified as viruses. The mailprovider that improves
security my disallowing more secure forms of authentication.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090417/042ec755/attachment.pgp>