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 #201 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 2 November 2014 - 11:12

The dtsdownmix does work on my et8500. Didn't test it on other boxes.
That's with the cinch connectors

Edited by Sjaaky, 2 November 2014 - 11:13.


Re: GStreamer 1.0 #202 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 2 November 2014 - 19:29

@athoik, I'd gladly accept a patch to disable a segfault handler permanently. A library should never install a segfault handler (even not an application, imho).


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #203 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 2 November 2014 - 20:19

Doesn't that cripple the green screen and enigma crash log?

Re: GStreamer 1.0 #204 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 3 November 2014 - 13:18

xvid -> mpeg4 https://bugzilla.gno...g.cgi?id=739196 we need to give more information why we need to know that mpeg4 is actually xvid, please leave your comments on the bug if you want this to get fixed.

 

Done. It just happens to be in the dvbmediasink and driver code I've been working on for the last week or so, so I'm familiar with it.


"Beauty lies in the hands of the beer holder."

 


Re: GStreamer 1.0 #205 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 3 November 2014 - 15:14

Doesn't that cripple the green screen and enigma crash log?

The signal handler should be in main application, not in the library....

 

Apart from a signal handler, I'd prefer a simple fork (or even thread clone, but I am not sure if that always works with signals) that acts as the parent, that "reaps" the child when it's dead and optionally restarts it. The process status reveals what signal killed the child and the process cannot go into an endless handler loop.


Edited by Erik Slagter, 3 November 2014 - 15:16.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #206 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 3 November 2014 - 17:12

Doesn't that cripple the green screen and enigma crash log?

The signal handler should be in main application, not in the library....


I disabled the signal handler in bsod.cpp in order to be able to create core dumps instead of green screens ;)

Sorry if that wasn't clear.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #207 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 3 November 2014 - 19:23

Finally figured out why xvid videos on et4x00 were still not playing smoothly after reverting xvid mimetype.

As @peteru wrote
 

The specific case of real MPEG-4 Part 2 vs XVID comes down to issues with
"packed" format - where the frames are re-ordered and also the use of DTS
instead of PTS when the data comes from the AVI container

So I tried to use DTS intead of PTS in dvbvideosink and now xvid videos in AVI are played without issues on et4x00.

 

My suggestion to properly fix this issue would be:

 

1. detect in dvbvideosink.c if avidemux element is used in pipeline(maybe in set caps function?)

2. If avidemux is used and provided video is xvid we use GST_BUFFER_DTS macro else we use GST_BUFFER_PTS for settings pts in pes

 

I will try to provide patch, but need to figure out first point


Edited by mx3L, 3 November 2014 - 19:26.


Re: GStreamer 1.0 #208 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 3 November 2014 - 19:27

 

 

Doesn't that cripple the green screen and enigma crash log?

The signal handler should be in main application, not in the library....

 


I disabled the signal handler in bsod.cpp in order to be able to create core dumps instead of green screens ;)

Sorry if that wasn't clear.

Okay in that case never mind ;)


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #209 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 3 November 2014 - 19:29

Finally figured out why xvid videos on et4x00 were still not playing smoothly after reverting xvid mimetype.

As @peteru wrote
 

The specific case of real MPEG-4 Part 2 vs XVID comes down to issues with
"packed" format - where the frames are re-ordered and also the use of DTS
instead of PTS when the data comes from the AVI container

So I tried to use DTS intead of PTS in dvbvideosink and now xvid videos in AVI are played without issues on et4x00.

 

My suggestion to properly fix this issue would be:

 

1. detect in dvbvideosink.c if avidemux element is used in pipeline(maybe in set caps function?)

2. If avidemux is used and provided video is xvid we use GST_BUFFER_DTS macro else we use GST_BUFFER_PTS for settings pts in pes

 

I will try to provide patch, but need to figure out first point

 

So it actually IS the issue I brought up. Iew. Should we really go out of our ways to be compatible with every bogus trick invented to avoid problems with other bogus technology?

 

Note: while avi isn't even a standard at all, it is also improperly used by divx. FFmpeg will always complain when it encounters such a file. If one insists on using an avi container, one shouldn't be using b frames, it isn't designed for that, period. Either don't use b frames, or use a container that is suitable for using b frames (almost all of them are).


Edited by Erik Slagter, 3 November 2014 - 19:31.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #210 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 November 2014 - 16:31

@Erik
In case we want to fully support gstreamer1.0 in recievers like xtrend et4000 we will probably have to do that.
I have many media files like this(Xvid codec in AVI format), so this is probably not a rare case.

 

Tested on Xvid,DivX3 in AVI on et4000 and et6500, everything works smoothly.

For example DivX3 was not working on et4000 before at all.

 

Please test somebody also on other receivers, thanks

 

 

Attached Files



Re: GStreamer 1.0 #211 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 4 November 2014 - 17:59

@mx3L, nice find!

So the are two issues with xvid when used from avi container!

1. Detect xvid and use correct ioctl
2. Detect avi container and use DTS instead of PTS

If you remux into mkv the problem goes away?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #212 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 November 2014 - 20:51

@athoik

 

I put xvid avi to mp4 and to mov format, but in that process was fourcc changed from xvid to plain mpeg4, so no xvid caps were detected and playback of video was not smooth anymore because of mpeg4 streamtype.

This needs to be further tested, I did test only "packed" xvid in avi format and divx3 in avi. It's possible that also other formats with xvid/divx with usage of b-frames needs DTS instead of PTS.



Re: GStreamer 1.0 #213 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 4 November 2014 - 21:41

isn't there some property in the caps which we could check, instead of looking for the avidemux?



Re: GStreamer 1.0 #214 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 November 2014 - 22:53

In caps no, but we could use "container-format" property from taglist



Re: GStreamer 1.0 #215 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 November 2014 - 23:55

never mind, tags are not ment for this purpose and looks like they are not easily reachable from sink


Edited by mx3L, 4 November 2014 - 23:55.


Re: GStreamer 1.0 #216 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 5 November 2014 - 00:58

I think it is strange. Shouldn't it be the responsibility of some parser or demux to put the proper pts on a segment? It seems wrong to let the sink correct this.

Re: GStreamer 1.0 #217 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 5 November 2014 - 09:40

So the best solution is to put all available timestamps(PTS/DTS) to PES packet so decoder can choose what it needs.

I managed to do that, tested on et4x00 and playback of xvid/divx is flawless.

 

Please test

 

 

Attached Files



Re: GStreamer 1.0 #218 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 5 November 2014 - 10:13

That sounds like a proper, generic solution!
Does it still require patch #2210?

Re: GStreamer 1.0 #219 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 5 November 2014 - 11:32

I see an if with pts and dts and an else with pts.... But what if we have pts only?
Or is this a stuped thought from me?
At least the patch looks nice!

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


Re: GStreamer 1.0 #220 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 5 November 2014 - 12:47

Then dts is false, so pts = dts will not be executed and only the pts is used.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users