Posted 20 April 2015 - 19:48
Subject: [PATCH] gstreamer1.0 base add subparse patch from Bug 740784 Add patch from Bug 740784 - subparse: fails to detect UTF-8 encoding Also remove PR from gstreamer bitbakes since PRServer doesn't require it.
0001-gstreamer1.0-base-add-subparse-patch-from-Bug-740784.patch 4.95KB
7 downloads
Posted 21 April 2015 - 09:46
Ter info :
And yes still our sync problem. I can't give it up. I well found out some code which just does not work into audiosink and even on the contrary makes all thins worse.
I just added extra debug but info for gst. On the dreambox launching debug into 5 mode (debug) is to heavy. into 4 mode (info) it's ok to run debug
dvbaudiosink, dvbvideosink and dtsdownmix, with gst-launch-1.0 or with enigma2 log.
gst-launch-1.0 example with debug info level (4). before gst launch do not forget to kille enigma2 by using init 4.
gst-launch-1.0 playbin --gst-debug=dvbaudiosink:4,dvbvideosink:4,dtsdownmix:4 uri=file:///xxx .
Or just use init 4 and start enigma2 back with for example: ( I use cf to set my enigma2 log file if you have an hd you can use that or even a usb stick whatever but do not use flash mem for that)
GST_DEBUG=dtsdownmix:4,dvbaudiosink:4,dvbvideosink:4 enigma2.sh > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1
You can also just use the stdout from terminal by ommiting > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1 .
The latest commits set in master of my dvb mediasink :
https://github.com/c.../commits/master
Pay attention to note I made started with fixme
case GST_EVENT_SEGMENT:
{
const GstSegment *segment;
GstFormat format;
gdouble rate;
guint64 start, end, pos;
gst_event_parse_segment(event, &segment);
format = segment->format;
rate = segment->rate;
start = segment->start;
end = segment->stop;
pos = segment->position;
GST_INFO_OBJECT(self, "GST_EVENT_SEGMENT rate=%f format=%d start=%"G_GUINT64_FORMAT " position=%"G_GUINT64_FORMAT, rate, format, start, pos);
/* fixme on dreambox this does not work att all and I gues on any box*/
/* the video0 can't be opened since its in use */
/* The try off opening video0 makes sync issues worse than they already are */
if (format == GST_FORMAT_TIME)
{
self->timestamp_offset = start - pos;
if (rate != self->rate)
{
/* IS THIS NEEDED ? it really does not work on the contrary it increase the time*/
/* before sync is back ok after pause fast forward or backwards */
int video_fd = open("/dev/dvb/adapter0/video0", O_RDWR);
if (video_fd >= 0)
{
GST_INFO_OBJECT(self, "GST_EVENT_SEGMENT IS VIDEO0 OPEN ?");
int skip = 0, repeat = 0;
if (rate > 1.0)
{
skip = (int)rate;
}
else if (rate < 1.0)
{
repeat = 1.0 / rate;
}
ioctl(video_fd, VIDEO_SLOWMOTION, repeat);
ioctl(video_fd, VIDEO_FAST_FORWARD, skip);
ioctl(video_fd, VIDEO_CONTINUE);
close(video_fd);
video_fd = -1;
}
self->rate = rate;
}
}
break;
}
Posted 21 April 2015 - 09:58
I forgot last note.
Some seems not to be interested, but I wan't to keep dm8000 and dm800se support with gst-1.0 . Those boxes where to expensive to throw them into waste bin.
And it's not that I'm a fan of dreambox believe me . I even replaced one off them by a vuduo2 . But I hate trowing good working hardware into waste bin.
I'm shure there must be a simple elegant solution to solve this sync issue.
For those interested in letting the dm8000 and dm800se working with openpli4 lets join forces. All remarks to add maybe left or right an extra info always welcome debug is to heavy for dream.
Posted 21 April 2015 - 10:50
@christophecvr
I think that problem is that there is no intersection of PTS in HW buffers of video/audio.
When we start to play video, its starts to be written little earlier then audio and audio writing progress is slower(in case if there is SW decoding involved - probably much slower) then video writing progress according to timestamps.
This means that audio has a problem to catch up with video in even in HW buffer and on top of that video is already rendering, which makes it even harder for audio to catch up.
Possible solution could be to pre-fill HW buffer by VIDEO_FREEZE call while rendering at least for a few seconds, which would make high possibility that driver would find intersection of PTS in HW buffers.
To your question:
Maybe it's neccessary for audio playback only, but I'm not sure if in slowmotion or in fastforward mode there is audio heared
Edited by mx3L, 21 April 2015 - 10:52.
Posted 21 April 2015 - 11:35
@mx3L
Yes this is the way off thinking. But whit al tests I did , the first pts intersection seems to be right.
A video freeze out off dvbaudiosink does not work. Since we can't acces the video0 device out off dvbaudiosink.
I don't who implemented that procedure in the dvbaudiosink to work with the video0 but looks to me he never ever tested if it really worked.
As far I found out it can't work and never did. The video0 dev is occupied by another instance and seemed to be locked for opening.
Posted 21 April 2015 - 12:14
Also I forgot to mention some extra stuff I found out. Trough kernel log's.
We also have the kernel warning with skip firts pts. (this does not happen if we use sync mode in video and audio)
What i'm shure off. We start with ok intersection. which is unfortunetelly wrongly rejected.
And then the resync which is really uneeded starts.
On top of it, an video with dts audio has.
1 video frame. 2 audioframes within the same video frame .
So if the resync procedure starts it might hook on the video frame start pos 0 with the second audio frame. Result is audio is half a frame before video frame.
Kernel log.
Apr 21 13:11:59 dm8000 user.warn kernel: bcm_pcm_playback_open Apr 21 13:11:59 dm8000 user.warn kernel: bcm_pcm_playback_close Apr 21 13:11:59 dm8000 user.warn kernel: bcm_pcm_playback_open Apr 21 13:11:59 dm8000 user.warn kernel: bcm_pcm_playback_close Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: set blank to 0 Apr 21 13:12:00 dm8000 user.warn kernel: sync is off so we enable it Apr 21 13:12:00 dm8000 user.warn kernel: playback! Apr 21 13:12:00 dm8000 user.warn kernel: total video delay: 0 (0 ms) Apr 21 13:12:00 dm8000 user.warn kernel: audio xpt start Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: set fallback framerate to 24000 Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: set streamtype! Apr 21 13:12:00 dm8000 user.warn kernel: stop rave Apr 21 13:12:00 dm8000 user.warn kernel: set H264 Apr 21 13:12:00 dm8000 user.warn kernel: sw rave disabled! Apr 21 13:12:00 dm8000 user.warn kernel: restart rave Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: start decode Apr 21 13:12:00 dm8000 user.warn kernel: PCM Apr 21 13:12:00 dm8000 user.warn kernel: audio: streamtype set 13 Apr 21 13:12:00 dm8000 user.warn kernel: audio: streamtype_set: stop rave Apr 21 13:12:00 dm8000 user.warn kernel: decode Apr 21 13:12:00 dm8000 user.warn kernel: audio: streamtype_set: restart rave Apr 21 13:12:00 dm8000 user.warn kernel: set mute 0 (111) 0 Apr 21 13:12:00 dm8000 user.warn kernel: audio: decoder start 0 Apr 21 13:12:00 dm8000 user.warn kernel: video delay 0 (0 ms) Apr 21 13:12:00 dm8000 user.warn kernel: total video delay: 0 (0 ms) Apr 21 13:12:00 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:00 dm8000 user.warn kernel: RAP first pts 0x0, stc 0x34d98146, pcr invalid Apr 21 13:12:00 dm8000 user.warn kernel: video_stc is not valid yet.. so ignore audio first pts Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: first pts 0x0 Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: framerate changed 2 Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: resolution changed (1920 800) Apr 21 13:12:00 dm8000 user.warn kernel: VIDEO0: aspect changed 4 Apr 21 13:12:00 dm8000 user.warn kernel: set current avs auto aspect to 16:9 Apr 21 13:12:00 dm8000 user.warn kernel: disable wss on display 0 Apr 21 13:12:00 dm8000 user.warn kernel: set wss 7 on display 1 Apr 21 13:12:00 dm8000 user.warn kernel: set current avs auto aspect to 16:9 Apr 21 13:12:00 dm8000 user.warn kernel: disable wss on display 0 Apr 21 13:12:00 dm8000 user.warn kernel: set wss 7 on display 1 Apr 21 13:12:00 dm8000 user.warn kernel: set sb to 3(1) Apr 21 13:12:00 dm8000 user.warn kernel: enable tsm0 Apr 21 13:12:00 dm8000 user.warn kernel: RAP sampling rate info isr (48000) Apr 21 13:12:01 dm8000 user.warn kernel: VIDEO0: progressive changed (1) Apr 21 13:12:02 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:02 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:02 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:02 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:04 dm8000 user.info kernel: bcm4506: channel 0 is sleeping now Apr 21 13:12:05 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:05 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:05 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:10 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:10 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:10 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:12 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:12 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:13 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:13 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:13 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:14 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:14 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:14 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:14 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:16 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:16 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:16 dm8000 user.warn kernel: ch0: unlock Apr 21 13:12:18 dm8000 user.warn kernel: ch0: lock Apr 21 13:12:18 dm8000 user.warn kernel: ignore pts error when audio is not running Apr 21 13:12:18 dm8000 user.warn kernel: ch0: unlock
Here can be seen 16 seconds before audio runs
Edited by christophecvr, 21 April 2015 - 12:17.
Posted 21 April 2015 - 12:18
I don't who implemented that procedure in the dvbaudiosink to work with the video0 but looks to me he never ever tested if it really worked.
You can see initial commit of dvbmediasink here.
* GStreamer DVB Media Sink * Copyright 2006 Felix Domke <tmbinc@elitedvb.net>
So you know how implemented this. Go ahead ask him...
Edited by athoik, 21 April 2015 - 12:18.
Posted 21 April 2015 - 13:01
@athoik
I send him a mail with the question.
But can you in the mean time test with my latest commit on :
https://github.com/c...ox-dvbmediasink
This with the mkv i sended a while ago to you ?
You have a dm800se.
Just to know , do You see in any debug (info level 4) the message "GST_EVENT_SEGMENT IS VIDEO0 OPEN ?"
If not it's a prove that the procedure does not work. since dvbaudiosink is unsuccesfull in opening video0 device.
Posted 21 April 2015 - 13:19
When video is playing the video sink is responsible for Fast/Slow motion.
When audio is playing the audio sink is responsible to Fast/Slow motion, so only then it should work.
BTW here is the commit that introduced Fast/Slow on dm800.
Author Andreas Frisch <andreas.frisch@multimedia-labs.de> Thu, 23 Apr 2009 16:23:44 +0000 (16:23 +0000)
What exacly do you want me to test? Cause this code is supposed to be responsible to Fast/Slow motion. Is there an issue with Fast/Slow motion?
Posted 21 April 2015 - 13:55
When video is playing the video sink is responsible for Fast/Slow motion.
When audio is playing the audio sink is responsible to Fast/Slow motion, so only then it should work.
BTW here is the commit that introduced Fast/Slow on dm800.
Author Andreas Frisch <andreas.frisch@multimedia-labs.de> Thu, 23 Apr 2009 16:23:44 +0000 (16:23 +0000)What exacly do you want me to test? Cause this code is supposed to be responsible to Fast/Slow motion. Is there an issue with Fast/Slow motion?
Well the bring in has been done into the dvbaudiosink for reasons ? that's one off my questions .
It can not acces the video0 device as it 's occopied. that's logic. But it is well causing a increase of the audio replay when using dtsdownmix.
By the way also on vuduo2 it's never used, and there all works fine. But this attempt to open the video0 out off dvbaudiosink is there and also not succesfull.
Point is it should be removed completely out of the audiosink, unless someone is proving it works and is needed.
The test I ask. On the dm800se Do you ever see the output GST_EVENT_SEGMENT IS VIDEO0 OPEN ? exactly as written when you run with gst-launch-1.0 level 4:
gst-launch-1.0 playbin --gst-debug=dvbaudiosink:4,dvbvideosink:4,dtsdownmix:4 uri=file:///xxx
of where xxx is the mkv file i sended to you.
or You may as well stop enigma(init 4) and run enigma with log output :
GST_DEBUG=dtsdownmix:4,dvbaudiosink:4,dvbvideosink:4 enigma2.sh > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1
replace the > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1
to you're needs.
Then You can start stop the video out off enigma and later on can see all what happened in sequence with enigma.
I'm shure You never will find the exact string <GST_EVENT_SEGMENT IS VIDEO0 OPEN ?> which mean that this procedure not works but well causes extra delays into resync cause it's tried.
Edited by christophecvr, 21 April 2015 - 13:58.
Posted 21 April 2015 - 15:33
Is there a possibility to test the new gstreamer 1.0 with XP1000?
H9.Twin ::: H9.2H ::: H9.S ::: HD1265 ::: H2H :::::::::: WaveFrontier T90: 1W, 3, 7, 13, 16, 19, 23, 28, 42E ::::::::::
Posted 21 April 2015 - 16:02
Well the bring in has been done into the dvbaudiosink for reasons ? that's one off my questions .
It can not acces the video0 device as it 's occopied. that's logic. But it is well causing a increase of the audio replay when using dtsdownmix.
By the way also on vuduo2 it's never used, and there all works fine. But this attempt to open the video0 out off dvbaudiosink is there and also not succesfull.
Point is it should be removed completely out of the audiosink, unless someone is proving it works and is needed.
The test I ask. On the dm800se Do you ever see the output GST_EVENT_SEGMENT IS VIDEO0 OPEN ? exactly as written when you run with gst-launch-1.0 level 4:
gst-launch-1.0 playbin --gst-debug=dvbaudiosink:4,dvbvideosink:4,dtsdownmix:4 uri=file:///xxx
of where xxx is the mkv file i sended to you.
or You may as well stop enigma(init 4) and run enigma with log output :
GST_DEBUG=dtsdownmix:4,dvbaudiosink:4,dvbvideosink:4 enigma2.sh > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1
replace the > /media/cf/enigma2-gst-01-plimediasink1.log 2>&1
to you're needs.
Then You can start stop the video out off enigma and later on can see all what happened in sequence with enigma.
I'm shure You never will find the exact string <GST_EVENT_SEGMENT IS VIDEO0 OPEN ?> which mean that this procedure not works but well causes extra delays into resync cause it's tried.
Posted 21 April 2015 - 16:17
Looks like my assumption was wrong, tested with hw-prefill for 5 seconds, doesn't look that it helps. Didn't test it with dtsdownmix
diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 2b87caa..defbe71 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -1278,6 +1278,10 @@ static GstFlowReturn gst_dvbaudiosink_render(GstBaseSink *sink, GstBuffer *buffe
if (self->fd < 0) return GST_FLOW_ERROR;
+ /*
+ if (GST_BUFFER_DTS_IS_VALID(buffer))
+ GST_DEBUG_OBJECT(self, "dts=%" GST_TIME_FORMAT "\n", GST_TIME_ARGS(GST_BUFFER_DTS(buffer)));
+ */
if (GST_BUFFER_IS_DISCONT(buffer))
{
if (self->cache)
diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index fbebd11..0f71c0f 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -274,6 +274,7 @@ static gboolean gst_dvbvideosink_unlock (GstBaseSink * basesink);
static gboolean gst_dvbvideosink_unlock_stop (GstBaseSink * basesink);
static GstStateChangeReturn gst_dvbvideosink_change_state (GstElement * element, GstStateChange transition);
static gint64 gst_dvbvideosink_get_decoder_time (GstDVBVideoSink *self);
+static gboolean gst_dvbvideosink_asyncprefill_stop(GstClock *clock, GstClockTime time,GstClockID id, gpointer user_data);
/* initialize the plugin's class */
static void gst_dvbvideosink_class_init(GstDVBVideoSinkClass *self)
@@ -349,11 +350,28 @@ static void gst_dvbvideosink_init(GstDVBVideoSink *self)
self->unlockfd[0] = self->unlockfd[1] = -1;
self->saved_fallback_framerate[0] = 0;
self->rate = 1.0;
+ self->prefilled = self->prefilling = FALSE;
+ self->clock_id = NULL;
gst_base_sink_set_sync(GST_BASE_SINK(self), FALSE);
gst_base_sink_set_async_enabled(GST_BASE_SINK(self), TRUE);
}
+static gboolean gst_dvbvideosink_asyncprefill_stop(GstClock *clock, GstClockTime time,GstClockID id, gpointer user_data)
+{
+ GstDVBVideoSink *self = (GstDVBVideoSink*)user_data;
+ if (self->fd >= 0 && self->prefilling && !self->paused)
+ {
+ self->prefilled = TRUE;
+ self->prefilling = FALSE;
+ ioctl(self->fd, VIDEO_CONTINUE);
+ GST_DEBUG_OBJECT(self, "prefill of HW buffer stopped");
+ }
+ else
+ GST_DEBUG_OBJECT(self, "we are not prefilling?");
+ return TRUE;
+}More--
+
static gint64 gst_dvbvideosink_get_decoder_time(GstDVBVideoSink *self)
{
gint64 cur = 0;
@@ -510,6 +528,10 @@ static gboolean gst_dvbvideosink_event(GstBaseSink *sink, GstEvent *event)
self->rate = rate;
}
}
+ if (!self->prefilling)
+ {
+ self->prefilled = FALSE;
+ }
break;
}
case GST_EVENT_CAPS:
@@ -719,6 +741,28 @@ static GstFlowReturn gst_dvbvideosink_render(GstBaseSink *sink, GstBuffer *buffe
{
return GST_FLOW_OK;
}
+ if (!self->prefilled && !self->prefilling)
+ {
+ self->prefilling = TRUE;
+ GstClock *clock = GST_ELEMENT_CLOCK(GST_ELEMENT(sink));
+ GstClockTime time = gst_clock_get_time (clock) + (5 * GST_SECOND);
+
+ if (self->clock_id != NULL)
+ {
+ if (!gst_clock_single_shot_id_reinit (clock, self->clock_id, time))
+ {
+ gst_clock_id_unref (self->clock_id);
+ self->clock_id = gst_clock_new_single_shot_id (clock, time);
+ }
+ }
+ else
+ {
+ self->clock_id = gst_clock_new_single_shot_id (clock, time);
+ }
+ ioctl(self->fd, VIDEO_FREEZE);
+ GST_DEBUG_OBJECT(self, "prefilling HW buffer for 5 seconds");
+ gst_clock_id_wait_async (self->clock_id, gst_dvbvideosink_asyncprefill_stop, self, NULL);
+ }
#if GST_VERSION_MAJOR < 1
pes_header = GST_BUFFER_DATA(self->pesheader_buffer);
@@ -742,6 +786,10 @@ static GstFlowReturn gst_dvbvideosink_render(GstBaseSink *sink, GstBuffer *buffe
codec_data = codecdatamap.data;
codec_data_size = codecdatamap.size;
}
+ /*
+ if (GST_BUFFER_DTS_IS_VALID(buffer))
+ GST_DEBUG_OBJECT(self, "dts=%" GST_TIME_FORMAT "\n", GST_TIME_ARGS(GST_BUFFER_DTS(buffer)));
+ */
#endif-
#ifdef PACK_UNPACKED_XVID_DIVX5_BITSTREAM
@@ -1793,6 +1841,11 @@ static gboolean gst_dvbvideosink_stop(GstBaseSink *basesink)
self->pesheader_buffer = NULL;
}
+ if (self->clock_id)
+ {
+ gst_clock_id_unref (self->clock_id);
+ self->clock_id = NULL;
+ }
#ifdef PACK_UNPACKED_XVID_DIVX5_BITSTREAM
if (self->prev_frame)
{
@@ -1849,7 +1902,7 @@ static GstStateChangeReturn gst_dvbvideosink_change_state(GstElement *element, G
break;
case GST_STATE_CHANGE_PAUSED_TO_PLAYING:
GST_DEBUG_OBJECT (self,"GST_STATE_CHANGE_PAUSED_TO_PLAYING");
- if (self->fd >= 0) ioctl(self->fd, VIDEO_CONTINUE);
+ if (self->fd >= 0 && self->prefilled) ioctl(self->fd, VIDEO_CONTINUE);
self->paused = FALSE;
break;
default:
diff --git a/gstdvbvideosink.h b/gstdvbvideosink.h
index 8cf1dc2..833d1b7 100644
--- a/gstdvbvideosink.h
+++ b/gstdvbvideosink.h
@@ -114,6 +114,9 @@ struct _GstDVBVideoSink
gint64 lastpts;
gint64 timestamp_offset;
gboolean must_send_header;
+ gboolean prefilled, prefilling;
+-More--
+ GstClockID clock_id;
queue_entry_t *queue;
};
0001-test.patch 4.96KB
0 downloads
Posted 21 April 2015 - 16:43
@athoik ,
Nice brainstorm this is needed to solve this problem. Unfortunately a bit off track and that's cause I rush to much.
The base problem is and there i'm almost shure cause the first pts intersect of audio is 100 % right but skipped cause the video is not ready and that's not the case att all video is playing in same segment and ok.
The skipping off this pts when you start the video video is at 0 but audio also at 0 . They really do start tighter whitout any problem. but driver skips that ok pts and that's wrong. Then the problems arise. And it takes quite a while before the autosync finds an ok sync point, which on top can be wrong due to the split off 2 audio frames for one single video frame . This split sorry it's like that as for why ask to the video makers.
But in my tests I saw that implementation of video0 opening into the dvbaudiosink . I thaught maybe to find there a way to solve our problem. The only thing I found is that this does not work, actually never worked and can't work.
Removing it does not solve the sync issue, so that's not really the point. But on dreambox (in several tests i runnned with that removed) . It's just take much less before the video our audio replays then when it's enabled.
And trying to open an occupied really existing device, ok for very fast hardware and a lot off memory left avbl no problem just result -1 and thats it cased closed.
Unfortunately the dream is slow and his resources are already in use very close to the real max ram and processor capacity.
There is much more behind the simple open command then You think, and yes it needs memory in use ok it's released once You have You're -1 or 0 (0 which is ok answer for the open command). But it's needed.
And cause the few resources avbl are in use already. It will cause a swap event and use the swap space (file) whitout swap space it will even freeze the box completely for a while.
Posted 21 April 2015 - 17:08
@mx3L
I new already that this patch would never worked . I tried such thing not really the same way but the same goal whitout succes.
neverthless keep on brainstorming.
In all my tests I really found out that even the open command see message above can cause problems on dreambox only and only due to the very limited resourses.
Posted 21 April 2015 - 17:27
I think you should split this discussion in a thread about dts downmix with gst-1 on DMM hardware. gst-1 is already mature, as I have experienced by using the OpenATV 5.0 version on Solo2 and Duo2 (and I guess on other boxes the performance is similar). So I think a final effort of all people involved has to be done to bring gst-1 on OpenPLI (4.0 or 5.0, whatever). The non-working dts downmix on DMM hardware should not be a show stopper.
Posted 21 April 2015 - 17:39
I think you should split this discussion in a thread about dts downmix with gst-1 on DMM hardware. gst-1 is already mature, as I have experienced by using the OpenATV 5.0 version on Solo2 and Duo2 (and I guess on other boxes the performance is similar). So I think a final effort of all people involved has to be done to bring gst-1 on OpenPLI (4.0 or 5.0, whatever). The non-working dts downmix on DMM hardware should not be a show stopper.
Nice This toppic has been started by athoik and yes it was normally for dreambox.
So feel free to create You're own toppic.
There You will be able to spawn all you're complete usseless unfounded critics on you're own.
And serious working persons do not have to read you're bullshit anymore.
Posted 21 April 2015 - 18:28
@christophecvr
Well I wasn't so sure, since after FREEZE ioctl in videosink render is audio and video fd still accepting buffers, so after CONTINUE ioctl after 5 seconds it has prefilled audio/video buffer. Drivers should find sync point immediately, but it's just guessing game, without the knowledge of how exactly it works.
@malakuidi
gst-1 - I'm on it since christmas on et6x00 and et4x00 and I haven't experienced issues with playback aside wav issue which was resolved. So I think there is no reason to not to start to build images for it.
Posted 21 April 2015 - 18:35
Guys the topic is "GStreamer 1.0" so everything related with "GStreamer 1.0" fits here.
Although monopolizing the thread with non supported boxes (eg DMM), non supported modes on boxes (eg DTS on DMM) leads almost nowhere.
I agree with @malakudi, a thread "GStreamer 1.0 with DMM" is really better for DMM specific issues.
@christophecvr, it's not bad to push hardware to its limits (eg 8088 MPH: We Break All Your Emulators), but without knowledge, without manuals you can't do magic (unless you are a magician and Enigma2 schene has no magicians......... only a magic binary blob).
Posted 21 April 2015 - 18:59
athoik: +1
* 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.
Change from openvix to openpli - lose existing hdd recordings?Started by xdoktor, 30 Dec 2023  openpli, openvix, hdd, recordings
|
|
|
||
Having Trouble While Installing This SoftwareStarted by CharleyDavis, 27 Jun 2023 OpenPLi
|
|
|
||
Faild to flash or update OPENPLIStarted by dede_one, 8 Oct 2022 openpli
|
|
|
||
hd+ funktioneret nichtStarted by JeppeG, 29 Sep 2022 Vu+, hd+, oscam, openpli
|
|
|
||
No data on transponder! (Timeout reading PAT)Started by JelleB8, 10 Jul 2022 openpli, vu+
|
|
|
0 members, 55 guests, 0 anonymous users
