2520 replies to this topic

[mx3L]

New stable release available !

https://gstreamer.fr...g/releases/1.8/

[MastaG]

you beat me to it

http://phoronix.com/...er-1.8-Released

 

I'll try to build a new round of images for public testing next week.

[mx3L]

Did some tests with 1.8.0 with comparison to 1.6.3:

 

- looks like there is fixed issue with distortion, at least I see none of it:

http://forums.openpl...ndpost&p=519063

 

- improved playback of HLS streams, meaning there is no immediate freeze and quite long waiting in variant playlists for better quality, but playback is for few seconds in lower quality and then jumps fluently to better quality.

 

So very nice improvement

[mx3L]

Some finding:

 

http://live.rpctv.co...l/playlist.m3u8

 

If I try to play this stream on et6x00 then decoder is frozen on startup, have to restart decoder by VIDEO_FREEZE/VIDEO_CONTINUE in order to continue.

I found out that freeze happens if we write PES header without PTS set for AU_DELIMITER buffer, since for some reason gstreamer doesn't set PTS for this initial buffer.

 

But for example this freeze is not happening on vusolose on the same stream.

 

If somebody wants to test, here is patch which 'fixes' it by setting some PTS value for this buffer, so PES is written with PTS.

https://gist.github....9e4e24a425b89f6

[Akki]

Has tested the patch in the Duo2 with GST 163, unfortunately, the Freezer are not away by the start of the Streams and the Stream stops after 3sek.

 

Greeting Akki

[mx3L]

Thanks for a test, this problem shouldn't be related to new vu +receivers, at least I have no problem with this stream on vusolosev2 even without patch for dvbvideosink, but I'm using gstreamer-1.8.0. Please try this stream on this version if possible.

Edited by mx3L, 1 April 2016 - 14:12.

[Andi316]

Is there a possibility for a working Dolby Atmos support and a Atmos Downmix?

At this time my Solo4k restarts after a couple of seconds with an Atmos audiotrack

[MastaG]

Some finding:

 

http://live.rpctv.co...l/playlist.m3u8

 

If I try to play this stream on et6x00 then decoder is frozen on startup, have to restart decoder by VIDEO_FREEZE/VIDEO_CONTINUE in order to continue.

I found out that freeze happens if we write PES header without PTS set for AU_DELIMITER buffer, since for some reason gstreamer doesn't set PTS for this initial buffer.

 

But for example this freeze is not happening on vusolose on the same stream.

 

If somebody wants to test, here is patch which 'fixes' it by setting some PTS value for this buffer, so PES is written with PTS.

https://gist.github....9e4e24a425b89f6

 

I can confirm your patch doesn't break anything on DM800HD, DM800Se and Spark7162.

This is with stable gstreamer 1.8.0.

However I wasn't able to reproduce the problem without your patch on any of my receivers.

But if it fixes the frozen video decoder for certain Xtrend receiver than you should create a pull request for PLi so we can all benefit.

 

Thanks for your work!

The patch will be in my next round of images as well

[christophecvr]

I just merged this patch into :

 

https://github.com/c.../commits/master

[mx3L]

Hi guys,

 

The intention of my post was to find out, if the problem occurs also on other receivers than xtrend et6x00, and if the problem is really solved by this patch also on these receivers. So I don't think it should be added in dvbvideosink, since it's not tested much and it's still only a workaround.

[christophecvr]

Hi guys,

 

The intention of my post was to find out, if the problem occurs also on other receivers than xtrend et6x00, and if the problem is really solved by this patch also on these receivers. So I don't think it should be added in dvbvideosink, since it's not tested much and it's still only a workaround.

Well sorry it's in in multibox. But it can be tested then anyway. I always can revert it. However on

 

duo2 and dm8000 with master-next and gst-1.9.0.1 it does not give any problem.

[mx3L]

No problem. Did you test also without patch on dm8000 if this stream doesn't freeze at start?

[MastaG]

I've also tested it on Zgemma Star sh1 and h3 without any issues.

However also I couldn't reproduce your problem there.

If it only occurs on Xtrend receivers maybe you could wrap the patch in ifdefs so it's only applied using --with-xtrend or something, just to be sure.

But I guess we can await some more testing.

I have some private  testers now and also will upload a new batch of unoffcial PLi images this week with stable gstreamer 1.8 and your patch, then we can see if anyone reports any problems.

[MastaG]

Btw chris since you are building your images with gstreamer master git snapshots (1.9.0.1) did you experience any problems with mkv files (with DTS) lately?

I still haven't upgraded from 1.8 stable, however Taapat seems to revert a commit on 1.9.0.1:

https://github.com/T...24309f3a306c41b

 

Also he seems to keep plugins-good right before this commit: https://cgit.freedes...03b2d0f424c0595

[mx3L]

Thanks, it really looks like that it's problem only for xtrend. I guess the same problem could be also on et9x00 and et5x00, since it's same SoC.

[christophecvr]

Btw chris since you are building your images with gstreamer master git snapshots (1.9.0.1) did you experience any problems with mkv files (with DTS) lately?

I still haven't upgraded from 1.8 stable, however Taapat seems to revert a commit on 1.9.0.1:

https://github.com/T...24309f3a306c41b

 

Also he seems to keep plugins-good right before this commit: https://cgit.freedes...03b2d0f424c0595

Yes with the posted on master next(pli5) toppic. But I just solved the problem for the media by using a work around. Into videosink.c now the media does play fine with gst-1.9.0.1

 

Ok what I did found is that basically the media is wrongly converted that is like malakudi told and I'm so what shure he's right.

 

The media has been converted from dts audio to ac3 audio in this case they should have set during convertion the dts timestamp to a pts timestamp which they dit not.

 

just as test I modified simply rule (into multibox mediasink videosink.c (it is not the way how it will be in a eventual published work-around)

 

rule no 1004

	if (GST_BUFFER_PTS_IS_VALID(buffer) || (self->use_dts && GST_BUFFER_DTS_IS_VALID(buffer)))

to

	if (GST_BUFFER_PTS_IS_VALID(buffer) || (self->use_dts && GST_BUFFER_DTS_IS_VALID(buffer)) || GST_BUFFER_DTS_IS_VALID(buffer))

Well then the the problematic mkv container does play well. Ok it will not be like this in a final work-around but we could make a work around by us for it. I bit more specific and fine tuned then

[MastaG]

Ah thank you Chris, I didn't read the PLi5 topic yet (since I'm not building it yet).

I'll apply your work-around once I upgrade past 1.8 stable as well

 

@Taapat, what problems did you see on this commit? https://cgit.freedes...03b2d0f424c0595

Also related to DTS? or something else?

[dazulrich]

Hi Christophecvr

over on openatv the posted  sample mkv that doesn't play with GST 1.80 and they use your multibox mediasink.

http://www.opena.tv/...tml#post218519 

 

 maybe you could check whether the file benfits from your patch. or whether there is a different underlying issue.

it is reported to have no video on differnt boxes and only sometimes audio with downmix on.

Allgemein
UniqueID/String                          : 175342409208024465530784283373952462537 (0x83E9B83A6C71514CE20E183C89566EC9)
Vollständiger Name                       : C:\Users\Thomas\Desktop\00schinpsel.mkv
Format                                   : Matroska
Format-Version                           : Version 4 / Version 2
Dateigröße                               : 9,26 MiB
Dauer                                    : 3s 640ms
Gesamte Bitrate                          : 21,3 Mbps
Kodierendes Programm                     : Lavf56.36.100
verwendete Encoder-Bibliothek            : Lavf56.36.100 / Lavf56.36.100

Video
ID                                       : 1
Format                                   : VC-1
Format-Profil                            : Advanced@L3
Codec-ID                                 : V_MS/VFW/FOURCC / WVC1
Codec-ID/Hinweis                         : Microsoft
Dauer                                    : 3s 629ms
Bitrate                                  : 20,7 Mbps
Breite                                   : 1 920 Pixel
Höhe                                     : 1 080 Pixel
Bildseitenverhältnis                     : 16:9
Modus der Bildwiederholungsrate          : konstant
Bildwiederholungsrate                    : 23,976 (24000/1001) FPS
ColorSpace                               : YUV
ChromaSubsampling/String                 : 4:2:0
BitDepth/String                          : 8 bits
Scantyp                                  : progressiv
Bits/(Pixel*Frame)                       : 0.417
Stream-Größe                             : 8,96 MiB (97%)

Attached Files

•  schinpsel.rar   9.26MB   2 downloads

[MastaG]

VC1?

[christophecvr]

Ah thank you Chris, I didn't read the PLi5 topic yet (since I'm not building it yet).

I'll apply your work-around once I upgrade past 1.8 stable as well

 

@Taapat, what problems did you see on this commit? https://cgit.freedes...03b2d0f424c0595

Also related to DTS? or something else?

No do not aply this work around , as it may brake a lot off other stuff.

 

I now first will look up if I can make a work-around which is safe and has more protection to just cover this type off rather wrong made media just as extra (old) media support