[FFmpeg-devel] [PATCH] Implement an option in ffmpeg to make it print the output SDP and exit

[Michael Niedermayer]

On Tue, Jul 22, 2008 at 01:49:02AM +0200, Stefano Sabatini wrote:
> On date Sunday 2008-07-20 01:27:03 +0200, Stefano Sabatini encoded:
> > On date Saturday 2008-07-19 20:35:40 +0200, Michael Niedermayer encoded:
> > > On Sat, Jul 19, 2008 at 12:49:41AM +0200, Stefano Sabatini wrote:
> > > > On date Thursday 2008-07-17 20:57:09 +0200, Stefano Sabatini encoded:
> > > > > On date Wednesday 2008-07-16 18:46:50 +0200, Michael Niedermayer encoded:
> > > > > > On Wed, Jul 16, 2008 at 10:38:55AM +0200, Stefano Sabatini wrote:
> > > > > > > On date Wednesday 2008-07-16 08:38:54 +0200, Luca Abeni encoded:
> > > > > > > > Hi Stefano,
> > > > > > > > 
> > > > > > > > Stefano Sabatini wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > this patch changes the current behavious of ffmpeg which currently
> > > > > > > > > print if needed the SDP of the output streams.
> > > > > > > > 
> > > > > > > > Michael is ffmpeg.c maintainer, but since I am the one who
> > > > > > > > implemented SDP output I have some comments.
> > > > > > > > 
> > > > > > > > First of all, thanks for the patch: I believe the "-sdp" option is
> > > > > > > > needed (and I've been lazy not implementing it :).
> > > > > > > > 
> > > > > > > > > This patch implements a behaviour which could result useful when
> > > > > > > > > scripting things like this:
> > > > > > > > > 
> > > > > > > > > ffmpeg  -i ~/test.avi -vn -sdp -f rtp rtp://localhost:5004 > test.sdp
> > > > > > > > > ffplay test.sdp
> > > > > > > > > ffmpeg  -i ~/test.avi -vn -f rtp rtp://localhost:5004 > test.sdp
> > > > > > > > > 
> > > > > > > > > Since I think this is the assumed use for the SDP output then I think
> > > > > > > > > this behaviour is preferable since it doesn't require the user to
> > > > > > > > > invoke a transcoding just to print out the SDP.
> > > > > > > > 
> > > > > > > > I generally use "-t 0.001" if I want to generate the SDP without actually
> > > > > > > > streaming anything.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > Note that this breaks compatibility with the previous behaviour, now
> > > > > > > > > when ffmpeg is invoked without -sdp it won't print the SDP anymore.
> > > > > > > > 
> > > > > > > > I think this is ok.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > Also the SDP printed won't be prefixed by "SDP:\n" as before.
> > > > > > > > 
> > > > > > > > I believe this is ok too.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > Comments/suggestions are welcome as always.
> > > > > > > > 
> > > > > > > > In my opinion, it would be more useful to have a "-sdp" option that
> > > > > > > > prints the SDP without exiting (if the user wants ffmpeg to exit
> > > > > > > > immediately after printing the SDP, he can use "-t 0.001").
> > > > > > > > But I have no strong opinions about this: if other people think that
> > > > > > > > "-sdp" should exit, I am ok with it.
> > > > > > > 
> > > > > > > What I want to achieve is to give the user the possibility to
> > > > > > > understand if the SDP has been written, if for example the output
> > > > > > > stream doesn't support an SDP (e.g. ffmpeg -i foo.mpeg -sdp foo.avi)
> > > > > > > then ffmpeg should exit with an error code.
> > > > > > > 
> > > > > > > This is achievable also without to exit, the only problem is for
> > > > > > > example when the outgoing stream *may* be described by an SDP but the
> > > > > > > transcoding occurred in the firtst 0.01 seconds is broken and ffmpeg
> > > > > > > exits with 1, in this case the user cannot distinguish the two cases.
> > > > > > 
> > > > > > What would -sdp output on stdout in case of an error? if nothing then
> > > > > > this should be enough to distinguish it.
> > > > > 
> > > > > What I want to avoid is to require the user to perform that check,
> > > > > simply performing a check on the return code is way simpler, I
> > > > > couldn't even take out from the top of my head a simple way to check
> > > > > for the emptiness of a file.
> > > > > 
> > > > > But if we can avoid *at all* to transcode then I'm fine, ideally a:
> > > > > ffmpeg -t 0 -i test.avi -sdp -f rtp -an rtp://test.mpeg > test.sdp
> > > > > 
> > > > > should be fine, if *no* transcoding is performed then the return code
> > > > > tells if we wrote that SDP or not, which isn't guaranteed if we have
> > > > > to set t > 0.
> > > > 
> > > > Now that this is implemented here it is the patch.
> > > 
> > > after a few seconds of thinking ..
> > > i think sdp should be a muxer that outputs a file containing that stuff
> > > that is printed to stdout. Much cleaner and needs no changes to ffmpeg.c
> > 
> > Very nice idea, I'll try to implement it.
> 
> On the other hand I'm not sure it is possible to implement an SDP
> muxer.
> Indeed the SDP issued by ffmpeg has to know *all* the RTP output
> streams:
> 
> stefano at geppetto ~/s/ffmpeg> 
> ffmpeg -t 0 -i ~/test.flv -sdp -f rtp rtp://localhost:5008 -f rtp -acodec libmp3lame rtp://localhost:5004 2> /dev/null
> v=0
> o=- 0 0 IN IPV4 127.0.0.1
> t=0 0
> s=No Name
> a=tool:libavformat 52.17.0
> m=audio 5008 RTP/AVP 0
> c=IN IP4 localhost
> b=AS:64
> m=audio 5004 RTP/AVP 14
> c=IN IP4 localhost
> b=AS:64
> 
> so it's not possible to write a muxer, because this for definition
> only knows one output file.
> 
> Any idea? Otherwise I propose to implement the already proposed -sdp
> option.

make rtp support multiple streams

something like:
-f rtp rtp://localhost:5008,localhost:5004


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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/20080722/cab73351/attachment.pgp>