2520 replies to this topic

[athoik]

Now I did a extra test with hls service live m6 , which You posted
 
It stops playing after a while and the reason is clear we run out off data and got eos.
 
This could quit be a gstreamer hls module error self.
 
the service is:

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3a//sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8:mastag
#DESCRIPTION mastag

log appended it can be clearly seen where it goes wrong

Actually there is no problem recording that channel, just make sure that you have valid date on the box (not 1970).

The resulting mpeg-ts is not good for our hardware decoder.

See: http://forums.openpl...e-4#entry515984

[samsamsam]

Hello,

 

How "christophecvr/gstreamer1.0-plugin-multibox-dvbmediasink" should be configured for the ET9000?

 

Thanks,

SSS

[christophecvr]

For the ET9000 just same as You did by open pli.

 

guess it's :

DVBMEDIASINK_CONFIG = "--with-wma --with-wmv --with-pcm --with-dts --with-eac3"

[samsamsam]

Thank you.

[ataru80]

Im not sure if this has been already raised,

but the sTagTitle is no longer working for online web radios.

for example in shoutcast plugin any radio selected does not give anymore Title, Artist, Year.

 

In fact if you run the followin radio stream:

4097:0:0:0:0:0:0:0:0:0:http%3a//relay.181.fm%3a8128/

 

the following python instruction:

print self.currPlay.info().getInfoString(iServiceInformation.sTagTitle)

 

returns a null string.

 

Are still working:

currPlay.info().getInfoString(iServiceInformation.sTagAudioCodec)

currPlay.info().getInfoString(iServiceInformation.sTagGenre)

 

With the Gstreamer 0.x everything was working fine.

Can someone confirm using ShoutCast plugin or webradioFS

Edited by ataru80, 5 December 2015 - 08:00.

[athoik]

Hi,

 

This commit is causing problems: https://github.com/O...1c08498d7665964

 

Got message #195 from element "dvbaudiosink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ organization\=\(string\)\"181.FM\\\ -\\\ POWER\\\ 181\\\ -\\\=\\\[:\\\ The\\\ Hitz\\\ Channel\\\ :\\\]\\\=-\\\ www.181.fm\"\,\ genre\=\(string\)Top40\,\ location\=\(string\)http://www.181.fm\;";
Got message #196 from element "dvbaudiosink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ organization\=\(string\)\"181.FM\\\ -\\\ POWER\\\ 181\\\ -\\\=\\\[:\\\ The\\\ Hitz\\\ Channel\\\ :\\\]\\\=-\\\ www.181.fm\"\,\ genre\=\(string\)Top40\,\ location\=\(string\)http://www.181.fm\;";
Got message #219 from element "dvbaudiosink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ organization\=\(string\)\"181.FM\\\ -\\\ POWER\\\ 181\\\ -\\\=\\\[:\\\ The\\\ Hitz\\\ Channel\\\ :\\\]\\\=-\\\ www.181.fm\"\,\ genre\=\(string\)Top40\,\ location\=\(string\)http://www.181.fm\,\ has-crc\=\(boolean\)false\,\ channel-mode\=\(string\)joint-stereo\,\ audio-codec\=\(string\)\"MPEG-1\\\ Layer\\\ 3\\\ \\\(MP3\\\)\"\,\ nominal-bitrate\=\(uint\)128000\,\ bitrate\=\(uint\)127706\;";
Got message #220 from element "dvbaudiosink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ organization\=\(string\)\"181.FM\\\ -\\\ POWER\\\ 181\\\ -\\\=\\\[:\\\ The\\\ Hitz\\\ Channel\\\ :\\\]\\\=-\\\ www.181.fm\"\,\ genre\=\(string\)Top40\,\ location\=\(string\)http://www.181.fm\,\ has-crc\=\(boolean\)false\,\ channel-mode\=\(string\)joint-stereo\,\ audio-codec\=\(string\)\"MPEG-1\\\ Layer\\\ 3\\\ \\\(MP3\\\)\"\,\ nominal-bitrate\=\(uint\)128000\,\ minimum-bitrate\=\(uint\)127706\,\ maximum-bitrate\=\(uint\)127706\,\ bitrate\=\(uint\)127706\;";
Got message #223 from element "dvbaudiosink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ title\=\(string\)\"Alessia\\\ Cara\\\ -\\\ Here\"\,\ homepage\=\(string\)http://www.181.fm\,\ has-crc\=\(boolean\)false\,\ channel-mode\=\(string\)joint-stereo\,\ audio-codec\=\(string\)\"MPEG-1\\\ Layer\\\ 3\\\ \\\(MP3\\\)\"\,\ nominal-bitrate\=\(uint\)128000\,\ minimum-bitrate\=\(uint\)127706\,\ maximum-bitrate\=\(uint\)127706\,\ bitrate\=\(uint\)127706\;";

 

I will revert it.

[mx3L]

@athoik

I think we don't need to revert it, we just have to make sure that we don't send eventUpdateInfo when only bitrate is changed. Now we are not sending eventUpdateInfo when bitrate is in tags and m_bitrate is set, while other entries in tags could have changed(this case)

[athoik]

See: https://bugzilla.gno...996&action=diff

 

A proper patch was included for review in GStreamer but stays unnoticed...

Edited by athoik, 5 December 2015 - 09:07.

[mx3L]

In that case I agree, it should be reverted and we should add this patch in our oe, until gstreamer devs will do something about it.

 

Patch looks good, I think you should create new issue, since I think it's not that relevant to #758234.

[MastaG]

How well is this going to perform on a softfloat receiver?

[code=auto:0]

    if (parse->priv->post_avg_bitrate && parse->priv->avg_bitrate) {
      gfloat diffprev = (float) 100.0 * (ABSDIFF (parse->priv->avg_bitrate,
          parse->priv->posted_avg_bitrate)) / (float) parse->priv->avg_bitrate;
      if (diffprev >= update_threshold)
        parse->priv->tags_changed = TRUE;
    }[/code]

eg How many times does it need to perform this calculation?

[athoik]

It will perform just fine. The event we receive now consume much more cpu cycles...

Edited by athoik, 5 December 2015 - 10:28.

[mirakels]

But why float? Do you ever think you want the threshold to be something like 1.75% or something in the future?

what is wrong with  (100 * diff) % base  > threshold 

Assuming bitrate will not overflow a 32-bit int value when multiplied by 100...

[athoik]

But why float? Do you ever think you want the threshold to be something like 1.75% or something in the future?
what is wrong with  (100 * diff) % base  > threshold 
Assuming bitrate will not overflow a 32-bit int value when multiplied by 100...

Done! https://bugzilla.gno...800&action=diff

[MastaG]

it takes a while for them to respond..

https://bugzilla.gno...g.cgi?id=759055

[athoik]

it takes a while for them to respond..
https://bugzilla.gno...g.cgi?id=759055

You can perform a review on the patch using bugzilla, this will bring the thread in their attention.

[MastaG]

yes I'm going to register a bugzilla account.

I'm actually mass building for all receivers right now with your bugzilla patch included.

So everyone can give it a spin since I've been getting lots of requests lately.

When I've tried it myself I'll report my findings in the bugzilla thread.

[MastaG]

Nice

http://cgit.freedesk...c50581d22592b5e

[mamamia]

Vu+ integrating your work! 

 

http://code.vuplus.c...e1d846b740647ba

 

[gstreamer1.0-plugin-dvbmediasink] apply patch files.
 - audiosink_mpeg4_aac_header.patch, thanks to mx3L 
 - videosink_ffmpeg_mpeg4_nofourcc.patch, thanks to christophecvr 

[Erik Slagter]

Cool guys!

[MastaG]

The MP4 bug has returned.

After this commit: http://cgit.freedesk...07cfa072caef45e

There is a requirement for libsoup 2.48 while master and gst-1 only have 2.46 in openembedded-core.

For this reason the gstsouphttpsrc plugin is not built anymore when using upstream gstreamer.

 

So I tried to get an updated libsoup from upstream: https://github.com/o...p-2.4_2.52.1.bb

Placing it in meta-openpli/recipes-support/libsoup/.

 

Libsoup get's upgraded to 2.52 on my receiver and the gstsouphttpsrc plugin returns.

However, now MP4 is broken again.

 

I'm reverting this gstreamer commit for now...