693 replies to this topic

[Erik Slagter]

All the people that have problems, did you make changes to the /etc/enigma2/streamproxy.conf file? If so, can you post it?

[Rob van der Does]

The only thing I did was changing the bitrate via the app (from 1mbs to 50kbs).
In all other images I tried this works flawless (I understand that doesn't help you, but just to underline that in itself the Solo2 should do a fine job).
The first tow times I changed the bitrate I was surprised to see no difference in PQ after the stream had restarted. When I use 50kbs in other images the PQ is really bad. So it looks like the new setting isn't actually applied.

[Rob van der Does]

All the people that have problems, did you make changes to the /etc/enigma2/streamproxy.conf file? If so, can you post it?

I did not. Just a fresh flashed PLi with basic settings to get the image running.

[SpaceRat]

The first tow times I changed the bitrate I was surprised to see no difference in PQ after the stream had restarted. When I use 50kbs in other images the PQ is really bad. So it looks like the new setting isn't actually applied.

That's normal.

Neither does Erik's transproxy use settings inside /etc/enigma2/settings (Let alone ones that would be compatible to the Vu+ transproxy) nor does his proxy allow reliable detection of itself (Which would allow OWIF or a plugin to configure it).

So the only way to configure it is the manual way inside /etc/enigma2/streamproxy.conf

Well, to be precise there is a second one through parameters in the URL, but without a reliable detection mechanism at hand, nobody will support it.

[Erik Slagter]

http://your_receiver...eb?request=info

http://your_receiver...uest=info&xml=1

 

The VU+ transtreamproxy and filestreamproxy don't use any setting from enigma at all. They're dependent on the plugin for setting the parameters, globally.

[SpaceRat]

http://your_receiver...eb?request=info
http://your_receiver...uest=info&xml=1

This is not a proper way to detect the operating mode for transcoding.
Don't rely on my words for it, just accept the fact that also nobody else supports it (e.g. in their Android/Crapple apps).

 

The VU+ transtreamproxy and filestreamproxy don't use any setting from enigma at all. They're dependent on the plugin for setting the parameters, globally.

That's a purely academic discussion, just like that about Linux being only the kernel.

[Erik Slagter]

http://your_receiver...eb?request=info
http://your_receiver...uest=info&xml=1

This is not a proper way to detect the operating mode for transcoding.

 

Before you start yelling again, yes no single app uses the extra features of the streamproxy. That's a shame, but it was to be expected (at least in the short run). Nobody wants to keep apdapting it's code to every image/implementation, which is understandable. It has nothing to do with "detection". Maybe at some time some app builders will start to see the advantage to users of http byte range access and to be able to seek to time offsets within a file.

 

The VU+ transtreamproxy and filestreamproxy don't use any setting from enigma at all. They're dependent on the plugin for setting the parameters, globally.

That's a purely academic discussion, just like that about Linux being only the kernel.

 

Maybe, but in this context it is actually relevant. See the context.

[tilleke]

Erik, you're wrong! Vu+ Players uses it and you know it.  

[колбаскин]

Erik maybe you return the plugin for normal work with VU+ Player (with settings for transcoding on mobile?)

[Erik Slagter]

Erik, you're wrong! Vu+ Players uses it and you know it.  

Yes I know it I was speaking in very (too) general terms.

Edited by Erik Slagter, 31 May 2014 - 09:18.

[Erik Slagter]

Erik maybe you return the plugin for normal work with VU+ Player (with settings for transcoding on mobile?)

What do you think? Do you really think that would solve the problems? Dream on.

 

Why don't I see (like requested "some" times earlier)

- a proper bug report including boxtype and app used

- output of the streamproxy when run in foreground

- dmesg output

 

Like I said, nothing has changed for about two weeks now.

Edited by Erik Slagter, 31 May 2014 - 09:34.

[delavega]

its still working for me since then.

[Erik Slagter]

its still working for me since then.

Thanks for the report. Didn't test it on the solo2 lately.

[Chelsea]

Are there soon any solution for the transcoding problem on Vu+ Duo2 ?

 

I still have big problem with streaming my channels, specially the HD channels.

 

The problem I had are:

 

Lagging/Micro freezes

Bad quality

Streaming ends

[Erik Slagter]

If you can start a session successfully, that is were our input to the process ends. The whole transcoding itself is done in hardware and controlled by drivers which are developed by VU+.

 

But this sounds like a bad network connection / bad wireless reception. You might want to try a lower bit rate.

[Chelsea]

If you can start a session successfully, that is were our input to the process ends. The whole transcoding itself is done in hardware and controlled by drivers which are developed by VU+.

 

But this sounds like a bad network connection / bad wireless reception. You might want to try a lower bit rate.

Sorry byt I do not use wireless connection at all.

My network are working very well.

 

I do not have any problem at all with Black Hole, but I do not like Back Hole, so I hope this will be fixed in OpenPli. J

[Kers]

I'm having problems with transcoding on Duo2, it worked for a while but stopped in the past week or two.

 

When I open the stream with VLC, I can see that its receiving some data, but the picture stays blank. I can see that its receiving data in the "input/read" section, but the decoded section stays at 0.

Codec part says that its a H264 + AAC stream, as it should.

 

Any idea what might be wrong?

 

Here is what /var/log/messages says:

Jun  5 13:53:13 vuduo2 user.warn streamproxy: streamproxy: accept new connection on port 8002, default action: transcode, fd 6
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: range requested from: 0
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: header[connection]: "close"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: header[host]: "vu2:8002"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: header[icy-metadata]: "1"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: header[range]: "bytes=0-"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: header[user-agent]: "VLC/2.1.4 LibVLC/2.1.4"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: url: /1:0:1:2756:7FC:2:11A0000:0:0:0:
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: parameter[] = "/1:0:1:2756:7FC:2:11A0000:0:0:0:"
Jun  5 13:53:13 vuduo2 user.warn streamproxy: Service: create service: 1:0:1:2756:7FC:2:11A0000:0:0:0
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: default live request
Jun  5 13:53:13 vuduo2 user.warn streamproxy: ClientSocket: transcoding service
Jun  5 13:53:13 vuduo2 user.warn streamproxy: LiveTranscoding: 1:0:1:2756:7FC:2:11A0000:0:0:0
Jun  5 13:53:13 vuduo2 user.warn streamproxy: WebifRequest: send request to webif: "GET /web/stream?StreamService=1:0:1:2756:7FC:2:11A0000:0:0:0 HTTP/1.0^M ^M "
Jun  5 13:53:13 vuduo2 user.warn kernel: FE tune
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[audio] = d05
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[audio-1] = d06
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[pat] = 0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[pcr] = d04
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[pmt] = 106
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[subtitle] = 938
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[subtitle-1] = 939
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[text] = 938
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: pid[video] = d04
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Encoder: encoder 0 in use: 0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Encoder: encoder 1 in use: 0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: setprop: display_format=480p
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Encoder: bitrate: 500/500000
Jun  5 13:53:14 vuduo2 user.warn streamproxy: setprop: bitrate=500000
Jun  5 13:53:14 vuduo2 user.warn streamproxy: setprop: profile=baseline
Jun  5 13:53:14 vuduo2 user.warn streamproxy: setprop: level=3.1
Jun  5 13:53:14 vuduo2 user.warn streamproxy: setprop: gop_frameb=0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Encoder: open encoder /dev/bcm_enc0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: pmt: 262
Jun  5 13:53:14 vuduo2 user.warn streamproxy: video: 3332
Jun  5 13:53:14 vuduo2 user.warn streamproxy: audio: 3333
Jun  5 13:53:14 vuduo2 user.warn streamproxy: start ioctl
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: encoder pid[audio] = d05
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: encoder pid[pat] = 0
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: encoder pid[pmt] = 106
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: encoder pid[video] = d04
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Demuxer: ioctl demuxer ADD PID: audio -> 0xd05
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Demuxer: ioctl demuxer ADD PID: pmt -> 0x106
Jun  5 13:53:14 vuduo2 user.warn streamproxy: Demuxer: ioctl demuxer ADD PID: video -> 0xd04
Jun  5 13:53:14 vuduo2 user.warn streamproxy: LiveTranscoding: state init -> starting
Jun  5 13:53:16 vuduo2 user.warn streamproxy: LiveTranscoding: state starting -> running
 

 

[Erik Slagter]

This says transcoding is taking place sucessfully.

 

At this moment the output of "dmesg" is more interesting. It may very well be that the transcoding engine has crashed. This is very typical when no stream is received.

[Kers]

 

It seems that the stream actually does come, but is somehow not understood by linux VLC 2.1.4.

When I opened it with BS Player on my android mobile it worked, but VLC does now decode it even though its getting the data and recognizes the codec.

If I download the playlist file and open it from the commandline with vlc, I get the error "MPEG-4 descriptor not found". Maybe thats why its not displaying correctly.

 

$ vlc stream.m3u 
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0xff5058] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0x1009808] main playlist: stopping playback
[0x7fbd70c055d8] ts demux error: MPEG-4 descriptor not found

 

 

 

EDIT: Ok, the problem is with the playlist file, if I take the URL and give it directly to VLC, it works ok.

 

I seem to remember that there was a similar issue before, where the .m3u file was not liked by VLC. Is that correct?

 

$ vlc http://vu2:8002/1:0:1:189D:7FD:2:11A0000:0:0:0:
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0xdfd058] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[0x7fb4bcc04c38] ts demux error: MPEG-4 descriptor not found
[0x7fb4bce25c88] packetizer_mpeg4audio packetizer: AAC channels: 2 samplerate: 48000
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fb4a4001248] main vout display error: Failed to resize display
[h264 @ 0x7fb4bcca7940] illegal short term buffer state detected
[0x7fb4d40063c8] freetype spu text error: Breaking unbreakable line
[h264 @ 0x7fb4bcca7940] Missing reference picture
[h264 @ 0x7fb4bcca8600] Reinit context to 720x480, pix_fmt: 0
[0x7fb4d40063c8] freetype spu text error: Breaking unbreakable line
[0x7fb4a4001248] main vout display error: Failed to resize display
[0x7fb4d40063c8] freetype spu text error: Breaking unbreakable line

 

 

Edited by Kers, 5 June 2014 - 15:46.

[Kers]

For completeness sake, here is the playlist file contents:

$ more stream.m3u 
#EXTM3U 
#EXTVLCOPT--http-reconnect=true 
#EXTVLCOPT:program=6301
http://vu2:8002/1:0:1:189D:7FD:2:11A0000:0:0:0: