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

Stefano Sabatini stefano.sabatini-lala
Sat Jul 19 00:49:41 CEST 2008


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.

Behaviour:
stefano at geppetto ~/s/ffmpeg> 
ffmpeg -t 0 -sdp -i ~/test.flv -f rtp rtp://localhost:5008 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
c=IN IP4 localhost
m=audio 5008 RTP/AVP 0
b=AS:64
stefano at geppetto ~/s/ffmpeg> 
ffmpeg -t 1 -sdp -i ~/test.flv -f rtp rtp://localhost:5008 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
c=IN IP4 localhost
m=audio 5008 RTP/AVP 0
b=AS:64
stefano at geppetto ~/s/ffmpeg> 
ffmpeg -t 0 -sdp -i ~/test.flv -f avi rtp://localhost:5008
FFmpeg version SVN-r14284, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --prefix=/home/stefano --disable-shared --enable-libschroedinger --enable-libx264 --enable-pthreads --enable-gpl --enable-debug=3 --enable-libtheora --enable-libvorbis --enable-avfilter --enable-libamr-nb --enable-libamr-wb --enable-nonfree --enable-libfaad --enable-libfaac --enable-x11grab --enable-libmp3lame --disable-optimizations --disable-mmx
  libavutil version: 49.7.0
  libavcodec version: 51.60.0
  libavformat version: 52.17.0
  libavdevice version: 52.0.0
  libavfilter version: 0.0.0
  built on Jul 19 2008 00:06:02, gcc: 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)

Seems stream 0 codec frame rate differs from container frame rate: 1000.00 (1000/1) -> 25.00 (25/1)
Input #0, flv, from '/home/stefano/test.flv':
  Duration: 00:00:30.01, start: 0.000000, bitrate: 96 kb/s
    Stream #0.0: Video: vp6f, yuv420p, 320x240, 25.00 tb(r)
    Stream #0.1: Audio: mp3, 44100 Hz, mono, 96 kb/s
Output #0, avi, to 'rtp://localhost:5008':
    Stream #0.0: Video: mpeg4, yuv420p, 320x240, q=2-31, 200 kb/s, 25.00 tb(c)
    Stream #0.1: Audio: mp2, 44100 Hz, mono, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Output cannot be described by an SDP

My only doubt is now about the behaviour when the output stream cannot
be described by an SDP, I think the best solution is to exit with an
error code as soon as possible, in this way the user can check the
return code, slighly simpler than to check for the emptiness of the
output file.

Regards.
-- 
FFmpeg = Free and Fiendish Mastering Pitiless Erotic Gem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-ffmpeg-sdp-00.patch
Type: text/x-diff
Size: 1977 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080719/98a9be7a/attachment.patch>



More information about the ffmpeg-devel mailing list