ffmpeg RTMP examples not working

[Van]

I pulled xuggler from svn, ran ant tests, ran ant installer

• start local FMS instance running live application.
• connect publisher UI: FMS Admin App shows 1 connection and stream
being published
• connect viewer UI: FMS Admin App shows 1 connection has been added,
video object displays live stream in UI

... all seems good to go...
connect ffmpeg via terminal

$ ffmpeg -i rtmp://10.211.55.3/live/test/stream -acodec copy -vcodec
copy ~/test.flv
FFmpeg version git-N-28655-g98ac192-xuggle-4.0.911, Copyright (c)
2000-2011 the FFmpeg developers
built on Apr 4 2011 09:43:01 with gcc 4.2.1 (Apple Inc. build 5664)
configuration: --prefix=/usr/local/xuggler --extra-
version=xuggle-4.0.911 --extra-cflags=-I/sources/xuggle-xuggler/build/
native/i386-apple-darwin10.7.0/captive/usr/local/xuggler/include --
extra-ldflags=-L/sources/xuggle-xuggler/build/native/i386-apple-
darwin10.7.0/captive/usr/local/xuggler/lib --enable-shared --enable-
gpl --enable-nonfree --enable-version3 --enable-libfaac --enable-
libx264 --enable-libmp3lame --enable-libvorbis --enable-libtheora --
enable-libspeex --enable-libopencore-amrnb --enable-libopencore-amrwb
--extra-cflags=-m64 --extra-ldflags=-m64 --enable-pthreads --
arch=x86_64 --extra-cflags=-arch --extra-cflags=x86_64 --extra-
ldflags=-arch --extra-ldflags=x86_64
libavutil 50. 40. 0 / 50. 40. 0
libavcodec 52.115. 0 / 52.115. 0
libavformat 52.103. 0 / 52.103. 0
libavdevice 52. 3. 0 / 52. 3. 0
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 13. 0 / 0. 13. 0
rtmp://10.211.55.3/live/test/stream: Input/output error

Note: Server address, app name, app instance name and stream name are
all correct
Changing path to non-existant (empty) feed results in successful
connection.

version is xuggle-4.0.911, was pulled this morning from svn url.
tried building xuggle-4.0.1076 from build system this weekend --
ffmpeg build tests would not pass
same ffmpeg tests would not pass from latest checkout from the ffmpeg
repo.

Seems this is a version/build issue. Anyone have recent sources that
they have successfully built and ran against on OS X that they could
post to a sharing site? If not, are there any pointers on getting
xuggler+ffmpeg to successfully run the xuggler RTMP streaming examples?

[DroidMunkey]

try putting a trailing slash on the url - the libRTMP parser is kinda
flaky

rtmp://10.211.55.3/live/test/stream -> rtmp://10.211.55.3/live/test/stream/

also see: http://rtmpdump.mplayerhq.hu/librtmp.3.html for some extra
params you can throw in the URL that may help if it still refuses to
correctly parse the url (try "rtmp://10.211.55.3/live/test/stream
app=live/test/stream" w/ the space in between )

I wouldn't try compiling it from source- it's broken frequently so you
really don't want to rely on it for production servers, just get the
prepackaged version- libRTMP should work fine in that.

--Robert

[Van]

Droid, thanks for the response. Unfortunately the added slash at the
end only gave a red texted "invalid URL" error.

Over the weekend I did try some other added params such as
playpath=path and live=1
these did not work. It seemed they were interpreted as part of the
stream name, since they would show up in the admin as "streamname
playpath=path"

Interesting that when the info is wrong, it connects just fine, but
listens to a non-existant stream.
It fails with a generic IO error (no red text help) when it tries to
access a valid stream.

It might also be important to note that I was able to get it to work
with RTMP with the vod app, streaming a file via FMS RTMP, but have
had no success with the FMS live application with the webcame feeds.
Also, this is all running on FMS4.0 -- perhaps the examples were
tested against an earlier version of FMS (3.5?) and something changed
with the live streams in 4.0


Van

On Apr 4, 2:24 pm, DroidMunkey <kinkymun...@gmail.com> wrote:
> try putting a trailing slash on the url - the libRTMP parser is kinda
> flaky
>
> rtmp://10.211.55.3/live/test/stream  ->  rtmp://10.211.55.3/live/test/stream/
>

> also see:http://rtmpdump.mplayerhq.hu/librtmp.3.htmlfor some extra

[Art Clarke]

Compile with librtmp?

> --
> You received this message because you are subscribed to the Google Groups "xuggler-users" group.
> To post to this group, send email to xuggle...@googlegroups.com.
> To unsubscribe from this group, send email to xuggler-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/xuggler-users?hl=en.
>

[Van]

Art, I assumed xuggler compiled it's captive ffmpeg binary with
librtmp support.
However the config string doesn't show librtmp being present.

So, how do I tell xuggler to compile it's ffmpeg with librtmp support?
This info was not in your documentation.


Thanks,

Van

On Apr 4, 6:20 pm, Art Clarke <acla...@xuggle.com> wrote:
> Compile with librtmp?
>

> On Apr 4, 2011, at 3:03 PM, Van <carney....@gmail.com> wrote:
>
>
>
>
>
>
>
> > Droid, thanks for the response. Unfortunately the added slash at the
> > end only gave a red texted "invalid URL" error.
>
> > Over the weekend I did try some other added params such as
> > playpath=path and live=1
> > these did not work. It seemed they were interpreted as part of the
> > stream name, since they would show up in the admin as "streamname
> > playpath=path"
>
> > Interesting that when the info is wrong, it connects just fine, but
> > listens to a non-existant stream.
> > It fails with a generic IO error (no red text help) when it tries to
> > access a valid stream.
>
> > It might also be important to note that I was able to get it to work
> > with RTMP with the vod app, streaming a file via FMS RTMP, but have
> > had no success with the FMS live application with the webcame feeds.
> > Also, this is all running on FMS4.0 -- perhaps the examples were
> > tested against an earlier version of FMS (3.5?) and something changed
> > with the live streams in 4.0
>
> > Van
>
> > On Apr 4, 2:24 pm, DroidMunkey <kinkymun...@gmail.com> wrote:
> >> try putting a trailing slash on the url - the libRTMP parser is kinda
> >> flaky
>
> >> rtmp://10.211.55.3/live/test/stream  ->  rtmp://10.211.55.3/live/test/stream/
>

> >> also see:http://rtmpdump.mplayerhq.hu/librtmp.3.htmlforsome extra

[Van]

Art, it does appear that RTMP support is compiled in.

output of $ffmpeg -protocols

Supported file protocols:
I.. = Input supported
.O. = Output supported
..S = Seek supported
FLAGS NAME
-----
I.. applehttp
I.S concat
IOS file
IO. gopher
IOS http
I.. mmsh
I.. mmst
.O. md5
IO. pipe
IO. rtmp
IO. rtp
IO. tcp
IO. udp

[Art Clarke]

Search the list.  By default we don't bundle librtmp into Xuggle (because there are other dependencies on different OSes that get pulled in like SSL).  But librtmp support is MUCH better than built-in FFMPEG RTMP support (and effectively build-in RTMP support in FFmpeg is not under active development today).  But if you want to try it on a Linux or Mac system, try setting the following environment variable:
export XUGGLE_NATIVE_CONFIGURE=--enable-captive-librtmp

XUGGLE_NATIVE_CONFIGURE is an easy way to pass command lines to the underlying C++ build system in Xuggle.  You can also do it from the command line in ant.

- Art

--
http://www.xuggle.com/
xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFmpeg in Java.

[DroidMunkey]

maybe you need to force an FLV container since your url doesn't end
in .flv - (I had gotten an error about an "unknown container format",
but I was broadcasting not watching)

IContainerFormat fmt = IContainerFormat.make();

if (fmt.setOutputFormat("flv", rtmp_url , null) < 0) {
System.out.println("fmt.setOutputFormat failed");
}

int r = mDestContainer.open(rtmp_url, IContainer.Type.WRITE, fmt,
true, false);

if (r < 0) {
IError e = IError.make(r);
throw new XugglingException(String.format("Unable to open %s: %s
(%d)", rtmp_url, e.getDescription(), e.getErrorNumber()));
}

--Robert

> --http://www.xuggle.com/

[Van]

Droid, that is interesting.

I recompiled xuggler build 4.0.911 per Art's sugestion on the use of
compiler flags.
However, ffmpeg gave nothing but errors, either that it couldn't read
the RTMP Packet Headers or that the netsream.play command failed.

Adding a '.flv' to the stream nam and invoking it yielded slightly
diff't results:

$ffmpeg -i "rtmp://10.211.55.3/live/test/stream.flv app=live/test
subscribe=stream.flv live=1" -acodec copy -vcodec copy -y ~/test.flv

FFmpeg version git-N-28655-g98ac192-xuggle-4.0.911, Copyright (c)
2000-2011 the FFmpeg developers

built on Apr 5 2011 07:48:03 with gcc 4.2.1 (Apple Inc. build 5664)

configuration: --prefix=/usr/local/xuggler --extra-
version=xuggle-4.0.911 --extra-cflags=-I/sources/xuggle-xuggler/build/
native/i386-apple-darwin10.7.0/captive/usr/local/xuggler/include --
extra-ldflags=-L/sources/xuggle-xuggler/build/native/i386-apple-
darwin10.7.0/captive/usr/local/xuggler/lib --enable-shared --enable-
gpl --enable-nonfree --enable-version3 --enable-libfaac --enable-
libx264 --enable-libmp3lame --enable-libvorbis --enable-libtheora --
enable-libspeex --enable-libopencore-amrnb --enable-libopencore-amrwb

--enable-librtmp --extra-cflags=-m64 --extra-ldflags=-m64 --enable-
pthreads --arch=x86_64 --extra-cflags=-arch --extra-cflags=x86_64 --

extra-ldflags=-arch --extra-ldflags=x86_64
libavutil 50. 40. 0 / 50. 40. 0
libavcodec 52.115. 0 / 52.115. 0
libavformat 52.103. 0 / 52.103. 0
libavdevice 52. 3. 0 / 52. 3. 0
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 13. 0 / 0. 13. 0

rtmp server sent error
q
RTMP_ReadPacket, failed to read RTMP packet header
rtmp://10.211.55.3/live/test/stream.flv app=live/test
subscribe=stream.flv live=1: Invalid data found when processing input

NOTE: upon successful FMS connection it subscribes to 'stream' and
**not** 'stream.flv' as it should, so no data is actually being
received because it's on the wrong channel.

So, while I still ended up getting an RTMP packet header read error,
it at least connected and didn't fail till after I stopped recording
and tried to write. Hardly a victory, but maybe an indicator as to
what's causing this issue.

I've been reluctant to build any code against this yet since it seems
that unless I can get a raw ffmpeg connection going, the java would be
destined to failure -- but I'll give your code snippet a go since
there seems to be an issue with the stream naming here seing how it
dropped the '.flv', and I had noticed the need to force container
types (via the appended '.flv') on the RTMP streaming file feeds I
tested last week which did work.

Maybe I'll get out of the woods yet :)


Van

[DroidMunkey]

try: rtmp://10.211.55.3/live/test/stream.flv app=live/test/stream.flv

it should be parsed as

app=<AppName>/<AppInstance>/<StreamName>

Are you sure you don't need extra connection parameters for FMS to let
you in? like the SWF verification hash or some other security?

Btw- forget FMS - I would use Wowza Media Server, it's way more
configurable and you can do almost anything w/ it (or checkout Red5
which is free - but requires more tweaks to scale up to 1000's of
connections)

I am doing real-time transcoding from FLV to h264 and watermarking/
thumbnailing INSIDE of wowza using xuggle on live streams. Way
better then having a separate app running

--Robert

> > > > are...
>
> read more »

[Van]

I'm not beholden to FMS, and in fact was initially intending to
develop on SmartFox Server2x. However it turns out the redbox support
for that is not there yet and they haven't replied to my inquiries
regarding their timeframe or about developer preview releases. Since
then I've grown partial to putting my service into the cloud. So I
could opt for Wowza, that service is available on EC2 and might
actually be more affordable than FMS on EC2. I'll have to research
that -- a google search is giving me an Amazon EC2 pricing data sheet
that seems inline with the fees I was expecting to pay for FMS.

And I'm in total agreement that being able to write the server code in
Java and tapping xuggler directly is the optimal solution, hence my
initial favoring of Smartfox.

I'll do some testing against Wowza this afternoon and see if I can get
success with that.


I did make an initial pass with a simple reader against FMS... with
predictably disappointing results.


import com.xuggle.mediatool.IMediaReader;
import com.xuggle.mediatool.ToolFactory;
import com.xuggle.xuggler.ICodec;
import com.xuggle.xuggler.IContainer;
import com.xuggle.xuggler.IContainerFormat;


public class RTMPReadTest {

static String rtmp_url = "rtmp://10.211.55.3/live/test/stream.flv";
/**
* @param args
*/
public static void main(String[] args) {
IContainer readContainer = IContainer.make();
readContainer.setForcedVideoCodec(ICodec.ID.CODEC_ID_FLV1);

IContainerFormat format = IContainerFormat.make();
format.setInputFormat("flv");

IMediaReader reader = ToolFactory.makeReader(readContainer);
readContainer.open(rtmp_url, IContainer.Type.READ, null, true,
false);

while (reader.readPacket() == null)
;
}

}


Had the same issues as the command line calls to ffmpeg, would connect
only to empty stream instances, as soon as data hit the stream
instance, it would quit with a read error.



Van

> > > > > > > >>> native/i386-apple-darwin10.7.0/captive/usr/local/xuggler/include --...
>
> read more »

[DroidMunkey]

it should be 'format' instead of NULL in the open line

readContainer.open(rtmp_url, IContainer.Type.READ, format, true,
false);

otherwise you aren't actually specifying the format you just setup.

--Robert

> > > > > > > > > Also, this is all running on...
>
> read more »

[Van]

Looks like the issue was FMS.
Setup Wowza, installed the live app, started the server and pointed my
publisher app at it.

The I ran ffmpeg against it

$ffmpeg -i "rtmp://bigred.local/live/stream app=live subscribe=stream

live=1" -acodec copy -vcodec copy -y ~/test.flvFFmpeg version git-
N-28655-g98ac192-xuggle-4.0.911, Copyright (c) 2000-2011 the FFmpeg
developers
built on Apr 5 2011 07:48:03 with gcc 4.2.1 (Apple Inc. build 5664)
configuration: --prefix=/usr/local/xuggler --extra-
version=xuggle-4.0.911 --extra-cflags=-I/sources/xuggle-xuggler/build/
native/i386-apple-darwin10.7.0/captive/usr/local/xuggler/include --
extra-ldflags=-L/sources/xuggle-xuggler/build/native/i386-apple-
darwin10.7.0/captive/usr/local/xuggler/lib --enable-shared --enable-
gpl --enable-nonfree --enable-version3 --enable-libfaac --enable-
libx264 --enable-libmp3lame --enable-libvorbis --enable-libtheora --
enable-libspeex --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-librtmp --extra-cflags=-m64 --extra-ldflags=-m64 --enable-
pthreads --arch=x86_64 --extra-cflags=-arch --extra-cflags=x86_64 --
extra-ldflags=-arch --extra-ldflags=x86_64
libavutil 50. 40. 0 / 50. 40. 0
libavcodec 52.115. 0 / 52.115. 0
libavformat 52.103. 0 / 52.103. 0
libavdevice 52. 3. 0 / 52. 3. 0
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 13. 0 / 0. 13. 0

Metadata:
height 150.00
title UnStreammmm
width 200.00
q
[flv @ 0x10180b000] Estimating duration from bitrate, this may be
inaccurate
Input #0, flv, from 'rtmp://bigred.local/live/stream app=live
subscribe=stream live=1':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0.0: Video: flv, yuv420p, 160x120, 1k tbr, 1k tbn, 1k tbc
Output #0, flv, to '/Users/van/test.flv':
Metadata:
encoder : Lavf52.103.0
Stream #0.0: Video: flv, yuv420p, 160x120, q=2-31, 1k tbn, 1k tbc
Stream mapping:
Stream #0.0 -> #0.0
Press ctrl-c to stop encoding
frame= 4556 fps= 0 q=-1.0 Lsize= 4933kB time=328.25 bitrate=
123.1kbits/s


test.flv was created in my home folder and successfully played back in
VLC.
A big fffffffffffffffffffuuuuuuuuuuuuuuuuuuuuuuuuu to FMS and hugs to
Wowza.

Thanks for your help.


Van

> > > > > > > > > Also, this is all running on...
>
> read more »

[Art Clarke]

take the ".flv" off of the stream name, and instead pass "-f flv" before the -i flag.  That will tell FFmpeg to hard code a FLV container, but still use the right stream name.

>
> read more »

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
To post to this group, send email to xuggle...@googlegroups.com.
To unsubscribe from this group, send email to xuggler-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xuggler-users?hl=en.