2520 replies to this topic

[MastaG]

Well then it's easy.

Someone should build the gst 1.x branch for each and every receiver with all patches applied (even the ones mentioned here in the last few posts).

Then upload those to dropbox or somewhere else and let everyone test it for themselfs.

 

Maybe the last few issues can be sorted out then:

 

- Playback of very big mkv (20-40GB; blue ray rip) should stop every 10-20 minutes (cannot confirm this because I don't have such files).
- Covers included in MP3 files are not shown.
- When Merlin music player is installed, MP3 playback from normal media player is not working (I can confirm this).

[littlesat]

- When Merlin music player is installed, MP3 playback from normal media player is not working (I can confirm this).

 

This should not be a real problem.... It might simply be Merlin is obsoleted... or Merlin needs to be adapted...

Edited by littlesat, 14 December 2014 - 15:16.

[mx3L]

0001-riff-media-added-fourcc-to-all-mpeg4-video-caps.patch - supply patch for build environment!
gst10_as_gst010_base.patch - applied
gst10_as_gst010_divx4_fix.patch - applied

Thanks,

In master branch of openpli-oe-core, there are no gstreamer1.0 recipes and gst-1.0 branch was not updated since 2013. I'm using recipes uploaded here by @athoik (post #282).

[peteru]

I've been looking into Windows Media playback. Does the existing video/x-wmv playback work properly for anyone with either gstreamer-0.10 or gstreamer-1.x ? My initial look at gstdvbvideosink.c suggests it should be broken for every box out there. But, before I start making changes, I'd like to find out if it really is as broken as I think it is.

Thanks.

[athoik]

It works, but there might be issues solved in drivers instead of fixing videosink!

What makes you think it is broken?

[peteru]

Looking at the code in gst_dvbvideosink_set_caps, the case where codec data is copied for CT_VC1_SM appears to truncate the codec data to the first 4 bytes.

[Erik Slagter]

0001-riff-media-added-fourcc-to-all-mpeg4-video-caps.patch - supply patch for build environment!
gst10_as_gst010_base.patch - applied
gst10_as_gst010_divx4_fix.patch - applied

Thanks,
In master branch of openpli-oe-core, there are no gstreamer1.0 recipes and gst-1.0 branch was not updated since 2013. I'm using recipes uploaded here by @athoik (post #282).

Then we need to take care of this when the switch has been made, I guess.

[athoik]

 

else if (self->codec_type == CT_VC1_SM)
{
	const GValue *codec_data = gst_structure_get_value(structure, "codec_data");
	if (codec_data)
	{
		guint8 *data;
		video_codec_data_t videocodecdata;
		gint width, height;
		gint codec_size = GST_BUFFER_SIZE(gst_value_get_buffer(codec_data));
		if (codec_size > 4) codec_size = 4;
		gst_structure_get_int(structure, "width", &width);
		gst_structure_get_int(structure, "height", &height);
		videocodecdata.length = 33;
		data = videocodecdata.data = (guint8*)g_malloc(videocodecdata.length);
		memset(data, 0, videocodecdata.length);
		data += 18;
		/* width */
		*(data++) = (width >> 8) & 0xff;
		*(data++) = width & 0xff;
		/* height */
		*(data++) = (height >> 8) & 0xff;
		*(data++) = height & 0xff;
		if (codec_data && codec_size) memcpy(data, GST_BUFFER_DATA(gst_value_get_buffer(codec_data)), codec_size);
		ioctl(self->fd, VIDEO_SET_CODEC_DATA, &videocodecdata);
		g_free(videocodecdata.data);
	}
} 

....

if (codec_size > 4) codec_size = 4;
if (codec_data && codec_size) memcpy(data, GST_BUFFER_DATA(gst_value_get_buffer(codec_data)), codec_size);

No idea why this is done

[socks]

Some users have reported issues with gstreamer 1.x:
Playback of very big mkv (20-40GB; blue ray rip) should stop every 10-20 minutes (cannot confirm this because I don't have such files).
 

 

This is not GStreamer 1.x related. I'm facing the same problem with GStreamer 0.1 and large mkv files.

[betacentauri]

The same user says that when he is using gstreamer 0.10 he has no problems with the same files.

[betacentauri]

Now I know why merlin music player (MMP) causes these problems. The C++ library from MMP registers itself as capable of playing mp3 files. It uses service ref starting with 4116. So all "mp3" plugins which are not explicitly using 4097, use after MMP installation the MMP c++ lib for playback. Unfortunately the c++ lib uses software decoding and alsasink for playback. As alsasink is not installed, playback don't work.

 

MMP has an option to enable software decoding (then it uses own lib otherwise servicemp3). I think it's added because some boxes are not able to playback mp3 via hardware. I have some questions regarding this:
1. Who knows which boxes are not capable of playing mp3 data via hardware?

2. @Athoik: As far as I can see alsasink is not installed and build. Can we add it again?

3. In dvbmediasink you can use configure to set caps according to the box hardware. If box hw cannot decode mp3 data then you can use --with-mp3=no. Then servicemp3 should use softwaredecoding with alsasink if hw supports this. So do we really need the MMP C++ lib? If yes, in which cases?

[Erik Slagter]

Even my good ol' dm800 could do decoding of mp3 in hardware. All these SoC's have simply mpeg 1 layer I/II/III decoding in hardware. So I guess this has been made as a workaround for a buggy driver or a workaround for some STB we don't support... I'd rather have it gone, it's always giving problems for users.

[betacentauri]

According to schwerkraft git DM7025 is not capable of playing mp3 (mpeg 1 layer 3) as it uses "sink_factory_ati_xilleon":

http://schwerkraft.e...1e;hb=HEAD#l259

Edited by betacentauri, 27 December 2014 - 18:02.

[theparasol]

So no problem for openpli at all to drop software decoding support since none of the current boxes/images will be affected.

[betacentauri]

I just removed library and adapted plugin.py. Now it works here(with et8500) without problems.

Edited by betacentauri, 27 December 2014 - 18:10.

[Erik Slagter]

According to schwerkraft git DM7025 is not capable of playing mp3 (mpeg 1 layer 3) as it uses "sink_factory_ati_xilleon":

http://schwerkraft.e...1e;hb=HEAD#l259

Yes that sounds familiar. We have stopped supporting the DM7025 some time ago

[Erik Slagter]

I just removed library and adapted plugin.py. Now it works here(with et8500) without problems.

Did you change the plugin itself? Would be nice if the author could apply it as well.

[betacentauri]

I can provide a patch to remove the lib in your git: http://sourceforge.n...linmusicplayer/

But not today

 

Today I have attached patch for you. It fixes problem in servicemp3 with covers included in audio files. It didn't work with Gstreamer 1.x. Should make no problems with normal builds.

Attached Files

•  0001-Fix-servicemp3-cover-processing-with-gstreamer-1.x.patch.txt   984bytes   19 downloads

[Erik Slagter]

Applied.

[betacentauri]

Thanks Erik!

Regarding Merlin Music Player (MMP): I know that some drivers cut off some seconds of mp3 audio (I think at start and or end). Software decoding didn't do that. So it might be a good idea not to remove the lib completely.

 

My idea is only to change line 29 in

http://sourceforge.n...inmp3player.cpp

Replace "mp3" by e.g. "mp3dummy" or "mp3_mmp" or "". Then all players except MMP don't use the MMP lib any longer. MMP don't use "mp3" extension to find the ServiceFactory so it can still use the MMP lib. Just tried it. It works (well alsalib is missing at the moment, but I can see that service ref 4116 is used then config is changed). So MMP users can decide whether they want to use sw or hw decoding.

 

I know not very nice, but acceptable?

Edited by betacentauri, 29 December 2014 - 14:39.