[FFmpeg-user] ffmpeg read from UDP/Port

Maziar Mehrabi mmehrabi at abo.fi
Tue Sep 23 20:16:26 CEST 2014 

Hi,

No problem, it was yourself who figured it out after all.
I have a question still though. How do you transmit the SDP file to the
client? I mean apparently for every stream you should have an SDP file
generated and sent to the client before the client is able to play it.
This problem is a major challenge if the client if going to play the stream
in a browser using html5.
So how do you manage this? Or do you think what solutions are there?

Thank you,
Maziar


--
Hälsningar,
Maziar Mehrabi

On Tue, Sep 23, 2014 at 8:19 PM, Alex Lin <op1031 at gmail.com> wrote:

> Hi Maziar,
>
> I finally figured it out. Instead of using udp stream as input, I generated
> a SDP file and use it as the input.
> Prior to receiving the audio packets, I receive a SIP packet with SDP
> payload. The SDP payload describes the IP/port of the video packet as well
> as the format. I just created a SDP file with the content of the payload,
> and FFmpeg was able to use it to receive and save the packets into a mpeg
> file. (or play it)
>
> Thank you for your help!
> AL
>
> On Mon, Sep 22, 2014 at 10:05 PM, Maziar Mehrabi <mmehrabi at abo.fi> wrote:
>
> > Hi,
> >
> > Try testing it over http first, rather than UDP or RTP. What I understand
> > is that the errors somehow are related to audio channel, and RTP divides
> > the media into two streams (one audio and one video) and sends them
> through
> > separate ports, so I guess you should have some sort of mechanism on the
> > other end to capture and mix these two streams.
> > One other way to test this idea is to use the -an option while you are
> > streaming media, this option means "No Audio" and will just stream the
> > video channel.
> >
> > if you please, keep me updated about your results.
> >
> > BR,
> > Maziar
> >
> >
> > --
> > Hälsningar,
> > Maziar Mehrabi
> >
> > On Tue, Sep 23, 2014 at 2:38 AM, Alex Lin <op1031 at gmail.com> wrote:
> >
> > > Hi Bill,
> > >
> > > >> I might be tempted to set both video and audio codec to copy, and
> save
> > > in a .TS file without -f at all.
> > > I did a look search on google about .ts files. My understanding is
> that,
> > I
> > > can use videosnarf to convert a packet trace to .TS file. Is that the
> way
> > > you have in mind as well?
> > >
> > > Thank you,
> > > AL
> > >
> > > On Fri, Sep 19, 2014 at 12:19 PM, Bill Davidsen <davidsen at tmr.com>
> > wrote:
> > >
> > > > Alex Lin wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I am using Windows 7 64 bit, and I downloaded the 64 bit version of
> > > >> ffmpeg: ffmpeg-20140916-git-b76d613-win64-static.7z
> > > >>
> > > >> I have spent the entire day experimenting with ffmpeg today but I
> > > haven't
> > > >> quite figure out if ffmpeg is the right solution to my problem yet,
> > so I
> > > >> would like to get some opinions.
> > > >>
> > > >> I am receiving H264 encoded packets through RTP with sample rate of
> > > >> 90,000,
> > > >> and I need to record these packets. The file format doesn't really
> > > matter
> > > >> at this point.
> > > >>
> > > >> Currently, I have a server sending the H264 packets to port 50002 of
> > my
> > > >> machine (192.168.1.200), so I run the following ffmpeg command on my
> > > >> machine:
> > > >>
> > > >> ffmpeg -i udp://192.168.1.200:50002 -f mp4 hello.mp4
> > > >>
> > > >
> > > > I might be tempted to set both video and audio codec to copy, and
> save
> > in
> > > > a .TS file without -f at all.
> > > > If that works you can capture the information and then play with it
> > from
> > > > the file. I am a Linux user,
> > > > so you may need guidance for Windows issues from an expert, but if
> you
> > > can
> > > > capture the data you
> > > > eliminate some possible problems by not reformatting the data at
> > capture.
> > > >
> > > >
> > > >> Then the following shows
> > > >>
> > > >> ffmpeg version N-66289-gb76d613 Copyright (c) 2000-2014 the FFmpeg
> > > >> developers
> > > >>    built on Sep 15 2014 22:11:04 with gcc 4.8.3 (GCC)
> > > >>    configuration: --enable-gpl --enable-version3
> --disable-w32threads
> > > >> --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r
> > > >> --enable-gnutls --enable-iconv --enable-libass --enable-libbluray
> > > >> --enable-libbs2b --enable-libcaca --enable-libfreetype
> --enable-libgme
> > > >> --enable-libgsm --enable-
> > > >> libilbc --enable-libmodplug --enable-libmp3lame
> > > --enable-libopencore-amrnb
> > > >> --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
> > > >> --enable-librtmp --enable-libschroedinger --enable-libsoxr
> > > >> --enable-libspeex --enable-libtheora --enable-libtwolame
> > > >> --enable-libvidstab --enable-libvo-aacenc --
> > > >> enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
> > > >> --enable-libwavpack --enable-libwebp --enable-libx264
> --enable-libx265
> > > >> --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
> > > >>    libavutil      54.  7.100 / 54.  7.100
> > > >>    libavcodec     56.  1.100 / 56.  1.100
> > > >>    libavformat    56.  4.101 / 56.  4.101
> > > >>    libavdevice    56.  0.100 / 56.  0.100
> > > >>    libavfilter     5.  1.100 /  5.  1.100
> > > >>    libswscale      3.  0.100 /  3.  0.100
> > > >>    libswresample   1.  1.100 /  1.  1.100
> > > >>    libpostproc    53.  0.100 / 53.  0.100
> > > >>
> > > >> The server starts sending video packets, and nothing happens on the
> > > >> command
> > > >> prompt with the ffmpeg command.
> > > >> The server stops sending video packets, and nothing happens still (I
> > > >> waited
> > > >> for at least 5 minutes), so I pressed Ctrl+C, then I see this
> > > >>
> > > >> udp://192.168.1.200:50002: Invalid data found when processing input
> > > >> Received signal 2: terminating.
> > > >>
> > > >> am I using ffmpeg correctly? and are the H264 packets I am receiving
> > not
> > > >> supported?
> > > >> I have looked around and did not see any debug log generated by
> > ffmpeg,
> > > so
> > > >> I don't really know where else to look.
> > > >> If it is necessary, I can provide a packet capture with the H264
> > > packets.
> > > >>
> > > >>
> > > > --
> > > > bill davidsen <davidsen at tmr.com>
> > > >   CTO TMR Associates, Inc
> > > > Unsigned numbers may not be negative. However, unsigned numbers may
> be
> > > > less than zero for suffiently large values of zero.
> > > >
> > > >
> > > > _______________________________________________
> > > > ffmpeg-user mailing list
> > > > ffmpeg-user at ffmpeg.org
> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> > > >
> > > _______________________________________________
> > > ffmpeg-user mailing list
> > > ffmpeg-user at ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> > >
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-user at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>

More information about the ffmpeg-user mailing list