[DEV]New Argus Provider

[Rudig 0]

Tompa, it's definitely worth trying, but I'm curious what argus does when max file size is reached. Don't know if the file is a sliding window over the DVb stream or different. But it's a good idea to try

[Griffo 3]

From my very limited reading of the source, it looks like StreamedMP also uses a TSBuffer reader before sending to FFMPEG for transcoding. I think we may be out of luck sending the file directly to FFMPEG unless we switch to RTSP which does introduce delay.

 

Obviously there are architectural differences, but it looks to me likeArgus XMBC, and MP plugins use a TSreader, as does StreamedMP which aims to transcode live TV. What format do ServerWMC and the other plugins read in?

Edited November 4, 2014 by Griffo

[Rudig 0]

I still find it strange, when I used RTSP on my ffmpeg command indeed it did give some errors at first but did continue. Errors disappeared after about 10 seconds and decoding was fine. Also the output file was fine. Do we really have a problem here?

[pünktchen 1258]

I still find it strange, when I used RTSP on my ffmpeg command indeed it did give some errors at first but did continue. Errors disappeared after about 10 seconds and decoding was fine. Also the output file was fine. Do we really have a problem here?

Have you used the same ffmpeg paramaters as MBS does?

[Rudig 0]

Wrong info. Ignore my original message:

 

Yes copied the string from one of the logfiles you guys shared

Edited November 4, 2014 by Rudig

[pünktchen 1258]

I've also made some tests - very interesting!!!

 

I've copied the stream from Argus to my local drive

ffmpeg.exe -i "rtsp://192.168.0.3:554/stream3.0" -vcodec copy -acodec copy -y "C:\Temp\input.ts"

and started a second instance of ffmpeg 10 seconds later to transcode the local stream

ffmpeg.exe -loglevel debug -fflags +genpts -async 1 -vsync -1 -re -i "C:\Temp\input.ts" -sn -vcodec libvpx -force_key_frames expr:gte(t,n_forced*5) -vf "yadif=0:-1:0,scale=min(iw\,1920):trunc(ow/dar/2)*2" -speed 16 -quality good -profile:v 0 -slices 8 -crf 10 -qmin 0 -qmax 50 -maxrate:v 19872000 -bufsize:v (19872000*2) -b:v 19872000 -vsync vfr -map_metadata -1 -threads 3 -acodec libvorbis -ac 2 -ab 128000 -af "aresample=async=1000" -y "C:\Temp\output.webm"

No distortion anymore! Absolutely smooth picture!
(Only problem is the second instance of ffmeg transcodes faster than the first instance can deliver the stream copy...)

 

So i think the problem with ffmpeg in MBS is, it trys to encode the stream right the same moment the stream is generated/delivered by argus.

That's why there are so many packet and reference frame errors that ffmpeg can't handle.

[Sven 136]

You guys are good with ffmpeg (transcoding), better then me.

[pünktchen 1258]

I tried to get ffmepg to transcode a stream I manually created, just to examine the scenario that it was trying too early. I got the same result - it generated the same error even after the stream had been running for a minute.

 

What error? Stream breaks/Player stops or encoding stops?

 

Here is an other example for a live stream encoding that is working nice:

ffmpeg.exe -i "rtsp://192.168.0.3:554/stream3.0" -codec:v libx264 -preset:v ultrafast -tune fastdecode -crf 24 -maxrate 8000k -bufsize 4000k -codec:a aac -b:a 256k -ac 2 -strict experimental -async 1 -sn -f mpegts "C:\Temp\input.ts"

Maybe the libvpx encoder of ffmpeg that gets used by MBS is to fussy when it comes to stream errors.

But why does it work with serverwmc and nextpvr? Do they manipulate the video in some way before they stream it?

[Luke 37062]

i would just use rtsp instead of the tsbuffer. i don't think the tsbuffer is something ffmpeg natively understands.

[pünktchen 1258]

i would just use rtsp instead of the tsbuffer. i don't think the tsbuffer is something ffmpeg natively understands.

rtsp is what we are trying as input, but the output (webm or mp4) is unwatchable.

[Sven 136]

That's weird. Why is it not working then?

[pünktchen 1258]

Yes copied the string from one of the logfiles you guys shared

Doesn't work for me. I get stream distortion

[Griffo 3]

I've also made some tests - very interesting!!!

 

I've copied the stream from Argus to my local drive

ffmpeg.exe -i "rtsp://192.168.0.3:554/stream3.0" -vcodec copy -acodec copy -y "C:\Temp\input.ts"

and started a second instance of ffmpeg 10 seconds later to transcode the local stream

ffmpeg.exe -loglevel debug -fflags +genpts -async 1 -vsync -1 -re -i "C:\Temp\input.ts" -sn -vcodec libvpx -force_key_frames expr:gte(t,n_forced*5) -vf "yadif=0:-1:0,scale=min(iw\,1920):trunc(ow/dar/2)*2" -speed 16 -quality good -profile:v 0 -slices 8 -crf 10 -qmin 0 -qmax 50 -maxrate:v 19872000 -bufsize:v (19872000*2) -b:v 19872000 -vsync vfr -map_metadata -1 -threads 3 -acodec libvorbis -ac 2 -ab 128000 -af "aresample=async=1000" -y "C:\Temp\output.webm"

No distortion anymore! Absolutely smooth picture!

(Only problem is the second instance of ffmeg transcodes faster than the first instance can deliver the stream copy...)

 

So i think the problem with ffmpeg in MBS is, it trys to encode the stream right the same moment the stream is generated/delivered by argus.

That's why there are so many packet and reference frame errors that ffmpeg can't handle.

 

I tried to get ffmepg to transcode a stream I manually created, just to examine the scenario that it was trying too early. I got the same result - it generated the same error even after the stream had been running for a minute.

[Rudig 0]

Sorry, I don't know why but I can't reproduce a successful transcode from a rtsp stream now.

I'll try some more tomorrow but sorry for this wrong information earlier.

[Luke 37062]

rtsp is what we are trying as input, but the output (webm or mp4) is unwatchable.

 

He should try playing with the ReadAtNativeFramerate param, turning it on/off. Also in the live tv service call to create a live stream he could try introducing a delay before returning the stream to the server. so for example, tell argus to start, then delay, then return it to MBS. that will allow it to build up a little bit before it gets fed into ffmpeg.

[Sven 136]

He should try playing with the ReadAtNativeFramerate param, turning it on/off. Also in the live tv service call to create a live stream he could try introducing a delay before returning the stream to the server. so for example, tell argus to start, then delay, then return it to MBS. that will allow it to build up a little bit before it gets fed into ffmpeg.

 

I tried already with the ReadAtNativeFramerate. But no difference.

Also tried to introduce a delay. But the output is still unwatchable...

[Rudig 0]

@@pünktchen what if you drop the -re parameter from your second ffmeg-command? this tries to keep up with actual frames.

[pünktchen 1258]

@@pünktchen what if you drop the -re parameter from your second ffmeg-command? this tries to keep up with actual frames.

 

-re should definitely be on. I am also not sure anymore of the second ffmpeg instance in my tests. Is it too fast, is it too slow or is it right - i don't know.

My VLC player stops playing sometimes earlier sometimes later, but ffmpeg continues encoding.

Btw. I'm always testing with 1080i HD channels, with SD channels VLC plays forever...

 

@@Rudig Have you tried it yourself?

@@Sven Is it hard to create a DEV version with this 2 ffmpeg instances concept?

[Rudig 0]

Yes I tried it but my media center PC is to slow to do real time ffmpeg conversion. PC that is fast enough can only reach the media center through wifi so I have a bandwidth issue there. So my test is probably not very representative

[pünktchen 1258]

I don't think that's possible. @@Luke is it possible?

Oh, it has to be done in the core not the plugin? Didn't know that. Than of course it is only a bad workaround.

The better way if you ask google about ffmpeg and rtsp live streaming (especially with h.264) would be: Don't use it!

Instead they all suggest to use VLC as a wrapper!

[Sven 136]

-re should definitely be on. I am also not sure anymore of the second ffmpeg instance in my tests. Is it too fast, is it too slow or is it right - i don't know.

My VLC player stops playing sometimes earlier sometimes later, but ffmpeg continues encoding.

Btw. I'm always testing with 1080i HD channels, with SD channels VLC plays forever...

 

@@Rudig Have you tried it yourself?

@@Sven Is it hard to create a DEV version with this 2 ffmpeg instances concept?

 

I don't think that's possible. @@Luke is it possible?

[Griffo 3]

Are we at an impasse? 

[Luke 37062]

Oh, it has to be done in the core not the plugin? Didn't know that. Than of course it is only a bad workaround.

The better way if you ask google about ffmpeg and rtsp live streaming (especially with h.264) would be: Don't use it!

Instead they all suggest to use VLC as a wrapper!

 

that doesn't really mean much because Vlc is built with ffmpeg.

[Luke 37062]

It seems argus is outputting a stream that cannot be easily fed into ffmpeg.

 

so unfortunately, either MBS needs to adapt to argus, or argus needs to output a stream that will be more compatible on a universal level. Since I am not going to do anything specific for Argus (or any other service) in the MBS core, there would have to be some benefit that will be applicable elsewhere.

 

I think if argus had an api to stream over http, that could be something we could try.

[Luke 37062]

You can also test out the latest server dev build. i'm experimenting with mp4 playback. hopefully you guys are testing on more devices than just the browser. well, you can see if the mp4 helps although even if it does, it's not something you can predict or control, since the output represents the needs of the playback clients, e.g. nothing to do with the input (argus).