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

[Stefano Sabatini]

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.

Regards.
-- 
FFmpeg = Faboulous and Friendly Mega Purposeless Eccentric Genius