Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #1521 littlesat

  • PLi® Core member
  • 57,101 posts

+698
Excellent

Posted 12 July 2015 - 11:36

Pushed :D And Thanks....!!!

 

 
txt.gif  Fix-CD-With-more-than-9-tracks.patch   468bytes   3 downloads
txt.gif  01-enigma2-serviceMP3-cuesheet.patch   7.72KB   4 downloads
txt.gif  02-enigma2-serviceMP3-chapters-support.patch   5.81KB   2 downloads
txt.gif  03-enigma2-serviceMP3-start-sequence.patch   3.52KB   5 downloads

txt.gif  04-IPTV-recording-in-E2.patch   27.24KB   11 downloads


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #1522 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 12 July 2015 - 16:26

What we are expecting to finally switch to gst 1.x? 



Re: GStreamer 1.0 #1523 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 12 July 2015 - 18:42

@littlesat ,

 

I just noticed a small enoying bug in cuesheet support.

 

If a media did not had a cuts file and the user did not ad a cut. There was always a cuts file saved but an empty then.

 

Also If A user made a cuts file and did removed all the cuts he made. The cuts file remained empty then.

 

Now If there was no cuts file loaded or user did not add cuts or just removed previousely made cuts

There will be no empty cuts file made or left.

 

Sorry had forgotten on that.

 

Included the small patch for current e2.

 

 

Attached Files



Re: GStreamer 1.0 #1524 littlesat

  • PLi® Core member
  • 57,101 posts

+698
Excellent

Posted 12 July 2015 - 21:33

Seen on time and pushed (untested)

 

txt.gif  cuesheet-correction.patch   1.34KB   4 downloads

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #1525 Taykun345

  • Senior Member
  • 1,297 posts

+41
Good

Posted 13 July 2015 - 08:05

I am not following the discussion and here is my question. Are crazy spinners on vu+ solved with 1.0 gstreamer when you load .srt subtitles?
Army MoodBlue HD skin modification by me: https://github.com/T...-MoodBlueHD-mod
Matrix10 MH-HD2 skin modification by me: https://github.com/B...-MX-HD2-OpenPli
MetrixHD skin modification by me: https://github.com/T...xHD-WPstyle-mod
Slovenian translation for OpenPLi E2: https://github.com/T...ion-for-OpenPLi

Re: GStreamer 1.0 #1526 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 13 July 2015 - 11:02

I am not following the discussion and here is my question. Are crazy spinners on vu+ solved with 1.0 gstreamer when you load .srt subtitles?

I'm currently bussy with the subtitles on gst-1.0.

 

For internal srt (embedded in media m4v or mkv) all 100 % no spinner. Start , Stop and resume.

 

For external srt at media start I never have a spinner anymore. Working 100 % and synchronized.

  - At media resume (a stopt movie restarted which goes to the last play position does bug cause buffers are pushed whitout segment )

     I'm still just trying to find out the real cause since this problem does not happen always .



Re: GStreamer 1.0 #1527 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 16 July 2015 - 09:45

@littlesat

 

Here a extra patch for start sequence by gst-1.

After reboot it could happen that the gstreamer sink's still wen't to early to play state.

 

Thats solved with this patch.

 

works perfect on vuduo2 and dm8000 with gst-1.

 

 

Attached Files



Re: GStreamer 1.0 #1528 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,603 posts

+62
Good

Posted 17 July 2015 - 09:27

@Christophecvr.

Combining your cuesheet patch and fix on top of it results in this code in servicemp3.cpp:

        FILE *f = fopen(filename.c_str(), "wb");

        if (f)
        {
                /* remove the cuts file if cue is empty */
                if(empty_cue)
                {
                        fclose(f);
                        remove(filename.c_str());
                        return;
                }
                unsigned long long where;
                int what;

               ....
        }

I'm sure you can see the unlogical sequence of events here and know how to refactor this in a more optimized way.

Please think and review your code before submitting.

 

Also when implementing an unimplemented function (cuesheet()), do not leave the 'unimplemented' version in the .h file in a commented version. You implemented the function so just remove the 'unimplemented version in the servicemp3.h file.


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: GStreamer 1.0 #1529 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 09:53

@mirakels

 

 

Also when implementing an unimplemented function (cuesheet()), do not leave the 'unimplemented' version in the .h file in a commented version. You implemented the function so just remove the 'unimplemented version in the servicemp3.h file.

Yes I left it commented , but indeed it should be removed now. Sorry forgot that.

      FILE *f = fopen(filename.c_str(), "wb");

        if (f)
        {
                /* remove the cuts file if cue is empty */
                if(empty_cue)
                {
                        fclose(f);
                        remove(filename.c_str());
                        return;
                }
                unsigned long long where;
                int what;

               ....
        }

Actually it's not that unlogic.

First You must think about the fact that A user maight have set some cuts into one off his movies he wathed before.

Later on he is wathcing the movie again. The cuts file is loaded. Cuts are there.

On this occasion he decided to remove all cuts previousely made.

The cuesheet will be empty , but the file will still be there,

With that code it will remove the file.

 

p.s. I used the FILE *f = fopen(filename.c_str(), "wb") also as check if file exist.



Re: GStreamer 1.0 #1530 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 10:03

@mirakels

 

as extra note ,

 

I could also use

 struct stat buffer;   
 return (stat (filename.c_str(), &buffer) == 0);

But Since the : FILE *f  was in why not use it at the same time ?



Re: GStreamer 1.0 #1531 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 10:11

the return then a boolean.

 

I hope sourceforge will be back soon. It's becoming off line for long now


Edited by christophecvr, 17 July 2015 - 10:12.


Re: GStreamer 1.0 #1532 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 10:32

@mirakels gues You prefere it like this then

void eServiceMP3::saveCuesheet()
{
	std::string filename = m_ref.path;

		/* save cuesheet only when main file is accessible. */
#if GST_VERSION_MAJOR < 1
	if (::access(filename.c_str(), R_OK) < 0)
		return;
#else
		/* save cuesheet only when main file is accessible. and no TOC chapters avbl*/
	if ((::access(filename.c_str(), R_OK) < 0) || m_use_chapter_entries)
		return;
#endif
	filename.append(".cuts");
	/* do not save to file if there are no cuts */
	/* remove the cuts file if cue is empty */
	if(m_cue_entries.begin() == m_cue_entries.end())
	{
		if (::access(filename.c_str(), R_OK) == 0)
			remove(filename.c_str());
		return;
	}

	FILE *f = fopen(filename.c_str(), "wb");

	if (f)
	{
		unsigned long long where;
		int what;

		for (std::multiset<cueEntry>::iterator i(m_cue_entries.begin()); i != m_cue_entries.end(); ++i)
		{
			where = htobe64(i->where);
			what = htonl(i->what);
			fwrite(&where, sizeof(where), 1, f);
			fwrite(&what, sizeof(what), 1, f);

		}
		fclose(f);
	}
	m_cuesheet_changed = 0;
}

I well can't test now since I cant build e2 with sourcefourge down.



Re: GStreamer 1.0 #1533 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,603 posts

+62
Good

Posted 17 July 2015 - 13:36

@mirakels


Actually it's not that unlogic.

First You must think about the fact that A user maight have set some cuts into one off his movies he wathed before.

Later on he is wathcing the movie again. The cuts file is loaded. Cuts are there.

On this occasion he decided to remove all cuts previousely made.

The cuesheet will be empty , but the file will still be there,

With that code it will remove the file.

 

p.s. I used the FILE *f = fopen(filename.c_str(), "wb") also as check if file exist.

 

Yes I understand your reasoning and saw that, but in this implementation you use more or less uses 'hidden' or side effect functionality that may not be obvious to people trying to understand the code. Using fopen() to verify a file exist is odd. Why not use access() for that too just like you do to check the main file?

Something like:

filename.append(".cuts");

if(empty_cue) {
   if (!access(filename.c_str(), 0) 
       remove(filename.c_str()); /* remove now unneeded cue file */
   return;
}

/* save new cues */
FILE *f = fopen(filename.c_str(), "wb");
if (f) {
    unsigned long long where;
    int what;

    ...
   
}
m_cuesheet_changed = 0;

And I think this 'm_cuesheet_changed = 0' should be at the start of the saveCuesheet() function cause when the main file is not accessible or the cue_sheet is empty, the function is exited leaving  this variable untouched.


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: GStreamer 1.0 #1534 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,603 posts

+62
Good

Posted 17 July 2015 - 13:40

oops sorry, just saw your new code to late :)

Note my use of acces (file, 0). instead of R_OK. You do not want to verify any mode bits for checking if the file exists.

factoring out the empty_que variable is also fine in this case.

 

Also please think about my m_cuesheet_changed remark..


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: GStreamer 1.0 #1535 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 14:43

@mirakels

 

I did understand you're remarks.

 

As the mather off fact it was an issue for witch I use a darts board when a wrote the initial code . Using fopen() to verify a file exist is odd , but still a quit accepted way off work in c,c++ or using an extra rule before.

 

You're remark made me understand that my bet was wrong you're really right, cause :

 

  - first the code is much more readable

  - But on top off it much more performant(and i'm a performance freak)

 

Then the remark that I just commented the code which was there in the servicemp3.h instead off removing it was meant as info to the pli4 dev team. This I will remove in one off next patches.

 

A last this is more a question. Instead off using 0  is it not better to use F_OK  as fare I understand R_OK will be there if file is only readable but F_OK will check read/write acces.

I still need to check this at base , but I prefer to use the R_OK , F_OK or ... instead off the nummerical value, this makes code more readable.



Re: GStreamer 1.0 #1536 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,603 posts

+62
Good

Posted 17 July 2015 - 22:39

Hihi if you are a perforamce freak you should certainly object to using fopen() to check if a file exists. fopen() has much more overhead than access().

(I'm also keen on performance but also on not using unnecessary resources)

 

 

About the F_OK/R_OK or 0. Using R_OK is not what you want. As most of the code runs as root it does not care much if  a file is really readable or not, root can probably read it anyway. You really want to test for file existence. So yes, F_OK is fine too. F_OK is actually defined as 0, so it indeed is better to use F_OK  :)


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: GStreamer 1.0 #1537 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 17 July 2015 - 23:18

And now just hoping that sourceforge is comming back online ........



Re: GStreamer 1.0 #1538 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 22 July 2015 - 12:34

Some updates for gst-1 branch. Subtitles.

 

I did found a solution to the last error with external srt.

on vuduo2 it works perfect.

 

Since still no gstreamer I can't make a clean patch. (For that I first need to have the real last commit off enigma2 pure pli4 git version)

 

Also I noticed that the vob subtittle support was already tried out. Did worked quit ok, but caused other bugs.

 

The other bugs where well more cause gst-0.10 is so buggy further the sequencing is very wrong in gst-0.10 enigma2. (could be required due to buggy gst-0.10)

 

gst-1 is pretty stable (1.5.1 actually 1.4.5 was already)

bugs ? off course there still some, comparing to 0.10 it's almost none.

 

Can gst-1 give more problems then gst-0.10 ?

  There may be more problems, they are not due to gstreamer-1.0  but due to bad implementation off gstreamer into the plugins.

  A lot off hack's,work-arounds and not updated code to the new standards off linux kernels,libc,c++,c and gstreamer self (which by gst-1.5.1 is well updated to this standards).

 

Some schedule when to expect a beta gst-1 pli4 image ?

Well I can't tell, that's up to the pli4 dev team and it's not so an easy task (a lot off work).

 

Concerning having the perfect mediaplayer for gst-1,

There I'm working on I expect .... hope around september.



Re: GStreamer 1.0 #1539 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 22 July 2015 - 13:34

For Enigma2 it is c6061e6215b69376a7eb91a2fb2f19ddb7ac7ee4.  For the rest (dvbmediasink..pliplugins) sorry.

 


Since still no gstreamer I can't make a clean patch. (For that I first need to have the real last commit off enigma2 pure pli4 git version)

 


Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: GStreamer 1.0 #1540 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 22 July 2015 - 20:24

Ok. Sourceforge is coming back to life. Only tuxbox-common is a problem at the moment. FIx rev at svn373 and build ok :)


Edited by Beeker, 22 July 2015 - 20:24.

Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.




3 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users


    Bing (1)