693 replies to this topic

[SpaceRat]

Ter info transcoding on vuduo2 only works when:
 
1) if vuplus-transcoding is installed (opk install vuplus-trancoding)

This is the correct part of the previous posting.

[christophecvr]

Ter info transcoding on vuduo2 only works when:
 
1) if vuplus-transcoding is installed (opk install vuplus-trancoding)

This is the correct part of the previous posting.

I not tested the authetinfication part which was 2) . Should be solved with you're latest change into webif,

But for the vuduo2 The 3) is the only and only correct way unless you did more then only correct the authetinfication part. will test this now. Just build with the latest webif update.

[christophecvr]

I do confitm that point 2)  authetinfication is solved.

But 3) is still there. For vuduo2 SIZE="720p" must be set. Other vu's wil have other setting there.

 

Run with 480p  gives

 

vlc http://192.168.65.82:8002/1:0:19:5221:C99:3:EB0000:0:0:0:
VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b)
[0x15a2108] main libvlc: Start vlc met standaardinterface. Gebruik 'cvlc' om vlc zonder interface te gebruiken.
"sni-qt/17596" WARN  06:28:31.622 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE 
[0x7fa248007098] ts demux error: MPEG-4 descriptor not found
[0x7fa248dbd3c8] packetizer_mpeg4audio packetizer: AAC channels: 2 samplerate: 48000
[0x7fa238002dc8] freetype spu text error: Breaking unbreakable line
[h264 @ 0x7fa248d0a5e0] illegal short term buffer state detected
[h264 @ 0x7fa248d0a5e0] Missing reference picture
[h264 @ 0x7fa248d601e0] Width/height changing with threads is not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.

Only audio plays black image. If I now stop the video stream and restart the video stream it plays also on 480p.

 

running with 720p which is ok gives

 

vlc http://192.168.65.82:8002/1:0:19:5221:C99:3:EB0000:0:0:0:
VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b)
[0x1734108] main libvlc: Start vlc met standaardinterface. Gebruik 'cvlc' om vlc zonder interface te gebruiken.
"sni-qt/18639" WARN  06:31:37.178 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE 
[0x7f4c000014e8] filesystem access error: cannot open file /home/christophe/vlc (No such file or directory)
[0x7f4c18000b78] main input error: open of `file:///home/christophe/vlc' failed
[0x7f4c00007328] ts demux error: MPEG-4 descriptor not found
[0x7f4c00db6d48] packetizer_mpeg4audio packetizer: AAC channels: 2 samplerate: 48000
[h264 @ 0x7f4c00d0a2e0] illegal short term buffer state detected
[0x7f4bf0003f58] freetype spu text error: Breaking unbreakable line

And it plays ok

[SpaceRat]

I not tested the authetinfication part which was 2)

I just didn't want to have information repeated which won't be correct anymore within 24h

But for the vuduo2 The 3) is the only and only correct way unless you did more then only correct the authetinfication part. will test this now. Just build with the latest webif update.

I only fixed the broken auth bypass for localhost.

The other problem simply doesn't exist:
I used a vuduo2 set to 480p for testing and it worked flawlessly without any changes, using latest vlc.

Anything else would be a shame, because lower res with more data per pixel scales to a better output than hi-res with only few data per pixel ...
Or to put it simple: At the same (low) bitrate and using the same codec, the lower resolution gives the better picture.

[SpaceRat]

Run with 480p  gives

[0202169c] logger interface: VLC media player - 2.1.3 Rincewind
[0202169c] logger interface: Copyright © 1996-2014 the VideoLAN team
[0202169c] logger interface:
[0202169c] logger interface: using logger.
[0202169c] logger interface debug: opening logfile `vlc-log.txt'
[h264 @ 04c79c80] illegal short term buffer state detected
[h264 @ 04c79c80] Missing reference picture, default is 65540
[h264 @ 04c79c80] Reinit context to 720x480, pix_fmt: yuv420p

And it plays ok ...

"Never change a running system" is the most stupid concept I've ever come along.
In most cases there is a reason for a new version, rendering the "running" wrong, you simply just didn't notice yet ...

Just update your vlc to a decently new one, 2.0.x is way old ...

[SpaceRat]

root@vuduo2:/proc/stb/encoder# cat 0/display_format & cat 1/display_format
480p
480p

[christophecvr]

The other problem simply doesn't exist:
I used a vuduo2 set to 480p for testing and it worked flawlessly without any changes, using latest vlc.

 

Sorry it does well exist, However after changing a vlc default setting it does work.

 

Vlc's default settings to change. Open preferences. Select all, section invoer/codecs videocodecs FFMPEG change Threads from 0 to 1.

 

Then it's ok.

 

Where this needed change was found :

 

https://forum.videol...hp?f=2&t=102839

 

Now it runs with 480p (the default) 520p and 720p

 

[SpaceRat]

Vlc's default settings to change. Open preferences. Select all, section invoer/codecs videocodecs FFMPEG change Threads from 0 to 1.

It's set to 0 here.

https://forum.videol...hp?f=2&t=102839

That's so 2012 ...
*g*

[christophecvr]

and depending on the channel the quality will improve in function off the 480p or 576p or 720p.

 

For a standard sd channel which normally is 576p. The best result will be obtained with 576p. Higher is usseles. Lower is lower quality.

For Hd channels which depend on which, they are now majorly at 1080p . (1920 x 1080). But the tuner for transcoding has maximum 720p. The best quality can be obtained at 720p, it's evident that older movies and series even broadcasted on hd channels will not have that good quality that's shure. Then 720p is usseles.

 

Further there are also extra problems if you want to stream trough internet . My max allowed upload is not enough to stream at full hd. For sd it's ok. (thats telenet limitation in belgium).

 

Then on the vuduo2 note the base video size

 

FE tune
[AUD]: AUDIO_SELECT_SOURCE 0 
[AUD]: AUDIO_SET_BYPASS_MODE 1 
[AUD]: downmix 0 state : 0
[AUD]: AUDIO_PAUSE 6503216 
[AUD]: AUDIO_PLAY 6503216 decoder start : 0
[VID]: VIDEO_SELECT_SOURCE 0  
[VID]: VIDEO_GET_SIZE src w: 1280 h:720 display w:1280 h:720

This is with transcoding on 480p ! . after reboot

[Erik Slagter]

Your missing the point Christophe. Actually all of 480p 576p and 720p work BUT if you change almost any of the other parameters, the encoding engine will crash. As will happen when you start playing around with the size parameter. The only safe operation is to set the parameters like mentioned in the setup script ONLY ONCE. Playing around with any other parameter or changing parameters repeatedly will crash the encoding engine (see dmesg). That is the reason why it's a startup script now, instead of a plugin.

 

I am using 480p all of the time, it's the default value and it works.

[SpaceRat]

For a standard sd channel which normally is 576p. The best result will be obtained with 576p.
For Hd channels which depend on which, they are now majorly at 1080p . (1920 x 1080). But the tuner for transcoding has maximum 720p. The best quality can be obtained at 720p,

This is true ... as long as we aren't talking about transcoding to the very same bitrate ...

Further there are also extra problems if you want to stream trough internet . My max allowed upload is not enough to stream at full hd.

And exactly that is the point ...

Your sending connection's upstream and your watching device connection's sustainable downstream speed define the limit for how high you can set the bitrate.

If it wasn't true, we wouldn't use transcoding at all:

Why bother with quality loss through transcoding when streaming across two 200 Mit/s symetric fiber lines?
Both lines can easily handle multiple untouched 15 MBit/s HD streams ...

But when you have a given bitrate you are transcoding to and which you can not exceed, you also trade in bpp (Bits per Pixel) if you increase the resolution.

So if you are setting up transcoding in order to stream across your 10 MBit/s upstream to lines which can easily handle 10 MBit/s down, you are probably right with your assumption that higher res is better.
However, if you have to keep the bitrate rather low, e.g. because you want to be able to watch the stream on your smartphone or your upstream is rather limited (e.g. DSL 16/1), a lower resolution will result in better quality due to the higher amount of bpp.

[christophecvr]

Your missing the point Christophe. Actually all of 480p 576p and 720p work BUT if you change almost any of the other parameters, the encoding engine will crash. As will happen when you start playing around with the size parameter. The only safe operation is to set the parameters like mentioned in the setup script ONLY ONCE. Playing around with any other parameter or changing parameters repeatedly will crash the encoding engine (see dmesg). That is the reason why it's a startup script now, instead of a plugin.

 

I am using 480p all of the time, it's the default value and it works.

No I'm not missing the point here, ...

 

There is wel more going on here.  (and that's not the fault off pli4 gues that this happens with all images).

 

It's related to hardware used more excactly the tuner self. I do have a dual tuner in a single slot by my box. Whatever You do the box always default to 1280 x 720 . This can be seen into dmesg output,

also when You start and I for example the first image when tuning is always for a short while 1280 x 720 . then swicthes to chnalle setting or demanded setting off for example 704 x 576p (sd channel)

1920 x 1080 hd channel. Why that's the question ?

 

Now lets stream .

 

First the standard streaming whitout encoding No problem. It will give with tread 0 the used image resolution. In this case sd channel will be automatically at 704 x 576. Hd channel at 1920 x 1080 . Does work perfect in vlc and is using port 8001.

 

Now lets use transcoding and stream via there.

 

If the plugin is setup at 480p (which is default) . It will send the stream at 480p. But the tread 0 is asking 720p. Result error as the stream does not match the image size setting. It is sending the 480p size on thread1 not 0.

 

Now vlc is set to use default tread 1 instead of 0. And ok It does work fine at 480p.

 

I'm so what shure(but definetely will not set my head on it) that persons who do have a vuduo2 with two single tuners. One in slot 1 and the other in slot 2 will not have this problem.

 

here the dmesg ouput I specially reflashed . Did not used HDMI but only scart.

 

FE tune
[AUD]: AUDIO_SELECT_SOURCE 0 
[AUD]: AUDIO_SET_BYPASS_MODE 1 
[AUD]: downmix 0 state : 0
[AUD]: AUDIO_PAUSE 6503216 
[AUD]: AUDIO_PLAY 6503216 decoder start : 0
[VID]: VIDEO_SELECT_SOURCE 0  
[VID]: VIDEO_GET_SIZE src w: 1280 h:720 display w:1280 h:720

Then every channel change it always says.  ??

 

FE tune
[AUD]: AUDIO_SELECT_SOURCE 0 
[AUD]: AUDIO_SET_BYPASS_MODE 1 
[AUD]: downmix 0 state : 0
[AUD]: AUDIO_PAUSE 6503216 
[AUD]: AUDIO_PLAY 6503216 decoder start : 0
[VID]: VIDEO_SELECT_SOURCE 0  
[VID]: VIDEO_SET_STREAMTYPE 1 
[VID]: VIDEO_FREEZE 6503216  0
[VID]: VIDEO_PLAY 6503216  5 2
[VID]: VIDEO_SLOWMOTION 0    1
[VID]: VIDEO_FAST_FORWARD 0    1
[VID]: VIDEO_CONTINUE 6503216  1 
[AUD]: AUDIO_CONTINUE 6503216 1 aph=0xcf72e680
[AUD]: setting mute : 0
[VID]: VIDEO_GET_SIZE src w: 0 h:0 display w:0 h:0

If I now set the transcoding-setup.sh with 720p and the vlc with thread 0 or 1 it runs always fine. (wheater just running sh /etc/init.d/transcoding-setup.sh or rebooting same result)

 

With 480p or 576p it does not work with vlc's standard at thread 0. As thread 0 always ask SIZE=720p.

 

Conclussion

 

some vuduo2 will just have 480p as default others 720p as default. And that is tuner related I guess.

 

After all it's not a problem, Users just need to know that in vlc the thread 1 must be selected instead off 0. It will work with 480p,576p or 720p.

 

That's all. Actually there is no real problem after all.

Edited by christophecvr, 29 March 2014 - 09:59.

[Erik Slagter]

The tuner has nothing to with the encoding. It's just the completely flakey implementation of the encoding that gives unpredictable results.

[christophecvr]

The tuner has nothing to with the encoding. It's just the completely flakey implementation of the encoding that gives unpredictable results.

Yes and now.

 

The encoding does work fine is setting the correct resolution but sends the size with thread1. thread 0 has always default size of 720p by my box , that's somehow comming from tuner as a default and transcoding does not change that. Other tuners will perhaps have other base defaults size and then this will be used on thread 0.

 

If You're box default stream on thread 0 is 480p, and transcoding setup is set to 480p. It will match  result image ok.

If You're box default stream on thread 0 is 720p(like it is by my box), and transcoding is setup to 480p result black image no match (audio is well ok)

If You're box default stream on thread 0 is 720p(like it is by my box), and transcoding is setup to 720p result in OK image.

 

Transcoding is sending the real used stream resolution on video thread1. the video thread 0 always uses the box default.

 

Confusing I know but users just have to change the base vlc preference to thread 1 and it is always ok.

Edited by christophecvr, 29 March 2014 - 10:20.

[Erik Slagter]

You should start to explain what you mean with "thread" in this context. Do you mean encoder as in /dev/bcm_enc? Both work here with 480p.

[christophecvr]

You should start to explain what you mean with "thread" in this context. Do you mean encoder as in /dev/bcm_enc? Both work here with 480p.

The FFMPEG THREAD

https://forum.videol...hp?f=2&t=102839

[SpaceRat]

You should start to explain what you mean with "thread" in this context. Do you mean encoder as in /dev/bcm_enc? Both work here with 480p.

He means the option "threads" for the ffmpeg settings in vlc ...
He believes it is necessary to set it to 1 rather than the default of 0.

And he's wrong.

I have just tried with the same ancient vlc as he uses inside my Ubuntu VM, it works as well with the default of 0.
On my real OS, I use vlc 2.1.3 and that's working with the default "0" as well.

Edited by SpaceRat, 29 March 2014 - 10:39.

[Erik Slagter]

I don't understand what the number of decoding threads on a video player has to do with an encoding engine on a stb???

[christophecvr]

You should start to explain what you mean with "thread" in this context. Do you mean encoder as in /dev/bcm_enc? Both work here with 480p.

He means the option "threads" for the ffmpeg settings in vlc ...
He believes it is necessary to set it to 1 rather than the default of 0.

And he's wrong.

I have just tried with the same ancient vlc as he uses inside my Ubuntu VM, it works as well with the default of 0.
On my real OS, I use vlc 2.1.3 and that's working with the default "0" as well.

I do not believe , It is just like that  . Definetely I'm not making things up It is just like that by me.

 

And wheater I use vlc 2.0.8 (standard of ubuntu) or 2.1.3 (self compiled cause that is on my other pc cause I needed blackmagic sdk in it). same result .

 

But before inventing things just try in You're case .... To set the transcoding-setup.sh on 720p reboot you're box and try with vlc at thread 0. It most probably will not work.

The same with vlc at stream1 . It will do.

[SpaceRat]

Now for something completely different:

There are two entries in inet.conf for transcoded streaming:

8003 stream tcp nowait root /usr/bin/filestreamproxy filestreamproxy
8002 stream tcp nowait root /usr/bin/livestreamproxy livestreamproxy

I noticed that other images also use a streamproxy for the regular "plain" streaming, e.g. Vu+ original, HDMU, ...:

8001 stream tcp nowait root /bin/streamproxy streamproxy

1. Can we have a separated streamproxy in OpenPLi too?
2. Could you please change the default lines in inetd.conf to

8003 stream tcp6 nowait root /usr/bin/filestreamproxy filestreamproxy
8002 stream tcp6 nowait root /usr/bin/livestreamproxy livestreamproxy

This would enable IPv6 (plus IPv4) connections to those proxies (Which is also the reason why I would prefer a separate streamproxy for port 8001 rather than the built in functionality).