From: Mauro B. <mau...@ti...> - 2002-05-27 15:58:19
|
Hello, MPEG TS files that were working perfectly with 0.9.9 do not always work with 0.9.10. Anybody did some similar testing? "possible still frames" everywhere... any idea? Input is from file. This does not happen always, but there is no recovery after the first "possible still frame". While video jumps from still frame to still frame, audio is playing smoothly. Same problems with the DVB input plugin I just merged against 0.9.10. Ciao, Mauro. Here is some xine-logging: system layer format 'MPEG_TS' detected. metronom: video discontinuity #2, type is 0, disc_off is 0 metronom: waiting for audio discontinuity #2 metronom: audio discontinuity #2, type is 0, disc_off 0 metronom: audio vpts adjusted with prebuffer to 481672 metronom: waiting for in_discontinuity update #2 metronom: video vpts adjusted to 481672 video_decoder: new pts 1083158517 metronom: video discontinuity #3, type is 2, disc_off is 1083158517 metronom: waiting for audio discontinuity #3 metronom: audio discontinuity #3, type is 2, disc_off 1083158517 metronom: waiting for in_discontinuity update #3 audio_decoder: using audio decoder plugin 'mad' input_file: get optional data, type 00000003, sub (nil) input_file: get optional data, type 00000003, sub (nil) audio_out: stream audio format is 48000 kHz sampling rate, 16 bits. mode is 8. audio_oss_out: ao_open rate=48000, mode=8, dev=/dev/dsp audio_oss_out: audio rate : 48000 requested, 48000 provided by device/sec audio_oss_out : 2 channels output audio_out: output sample rate 48000 audio_out: thread created video_decoder: using decoder >mpeg2dec< using video decoder plugin 'mpeg2dec' libmpeg2: frame size is 0 x 0, ratio is 3 libmpeg2: frame size has changed to from 0 x 0 to 704 x 576 libmpeg2: old frames freed. audio_out: inserting 4489 0-frames to fill a gap of 8420 pts video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) 200 frames delivered, 187 frames skipped, 0 frames discarded video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup 200 frames delivered, 191 frames skipped, 0 frames discarded video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) 200 frames delivered, 193 frames skipped, 0 frames discarded 200 frames delivered, 196 frames skipped, 0 frames discarded video_out: freeing frame backup video_out: possible still frame (fifosize = 0) video_out: freeing frame backup video_out: possible still frame (fifosize = 0) metronom: video jump video_out: freeing frame backup video_out: possible still frame (fifosize = 0) 200 frames delivered, 196 frames skipped, 0 frames discarded video_out: freeing frame backup 200 frames delivered, 197 frames skipped, 0 frames discarded video_out: possible still frame (fifosize = 0) |
From: Miguel F. <mi...@ce...> - 2002-05-27 16:27:45
|
Hi Mauro, Here we go again... i think it's the third time i talk about this problem with TS demuxer... ;) Take a look at this message: From: Miguel Freitas <mi...@ce...> To: xine-dev <xin...@li...> Cc: shaheed <sr...@ie...> Subject: [xine-devel] transport streams question Date: 17 May 2002 18:53:26 -0300 Hi folks, While testing latest demux_ts patches i noticed problems to play some cnn transport streams under xine. One problem is related to still frame code and i will do tests with dvd menus before commiting my fix. The other problem really puzzles me, so i'd like to ask advice to TS especialists over there... Shaheed? ;) The ts files i tried have audio data much ahead (in time) from video. This causes the audio decoder fifo to get full while video decoder is still processing old frames. Since the full fifo blocks the demuxer, video playback gets very sluggish (triggering still frame code several times) while the audio plays fine. If i run xine without audio, the demuxer doesn't block and video playback is ok. Since i can't control how these streams are generated, i hope something could be done at demuxer stage to handle it better. debuging demux_ts i noticed that all buffers being passed to decoders are only 156 or 168 bytes long! This is too small and will create a needless pressure on xine engine. Besides, it makes the stream unplayable. Is it possible to deliver data in larger chunks? Perhaps joining several of this 156 bytes buffers into a single buffer? regards, Miguel On Mon, 2002-05-27 at 12:57, Mauro Borghi wrote: > > Hello, > > MPEG TS files that were working perfectly with 0.9.9 do not always work with > 0.9.10. Anybody did some similar testing? "possible still frames" > everywhere... any idea? > > Input is from file. This does not happen always, but there is no recovery > after the first "possible still frame". While video jumps from still frame to > still frame, audio is playing smoothly. > > Same problems with the DVB input plugin I just merged against 0.9.10. > > Ciao, > Mauro. > > > Here is some xine-logging: > > system layer format 'MPEG_TS' detected. > metronom: video discontinuity #2, type is 0, disc_off is 0 > metronom: waiting for audio discontinuity #2 > metronom: audio discontinuity #2, type is 0, disc_off 0 > metronom: audio vpts adjusted with prebuffer to 481672 > metronom: waiting for in_discontinuity update #2 > metronom: video vpts adjusted to 481672 > video_decoder: new pts 1083158517 > metronom: video discontinuity #3, type is 2, disc_off is 1083158517 > metronom: waiting for audio discontinuity #3 > metronom: audio discontinuity #3, type is 2, disc_off 1083158517 > metronom: waiting for in_discontinuity update #3 > audio_decoder: using audio decoder plugin 'mad' > input_file: get optional data, type 00000003, sub (nil) > input_file: get optional data, type 00000003, sub (nil) > audio_out: stream audio format is 48000 kHz sampling rate, 16 bits. mode is > 8. > audio_oss_out: ao_open rate=48000, mode=8, dev=/dev/dsp > audio_oss_out: audio rate : 48000 requested, 48000 provided by device/sec > audio_oss_out : 2 channels output > audio_out: output sample rate 48000 > audio_out: thread created > video_decoder: using decoder >mpeg2dec< > using video decoder plugin 'mpeg2dec' > libmpeg2: frame size is 0 x 0, ratio is 3 > libmpeg2: frame size has changed to from 0 x 0 to 704 x 576 > libmpeg2: old frames fr7eed. > audio_out: inserting 4489 0-frames to fill a gap of 8420 pts > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > 200 frames delivered, 187 frames skipped, 0 frames discarded > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > 200 frames delivered, 191 frames skipped, 0 frames discarded > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > 200 frames delivered, 193 frames skipped, 0 frames discarded > 200 frames delivered, 196 frames skipped, 0 frames discarded > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > metronom: video jump > video_out: freeing frame backup > video_out: possible still frame (fifosize = 0) > 200 frames delivered, 196 frames skipped, 0 frames discarded > video_out: freeing frame backup > 200 frames delivered, 197 frames skipped, 0 frames discarded > video_out: possible still frame (fifosize = 0) > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Mauro B. <mau...@ti...> - 2002-05-27 17:18:32
|
Hello Miguel, thanks for replying so quickly! Sorry I didn't notice your message 10 days ago... :-} Very interesting! ;-) Yet I do not understand why this issue didn't show up in 0.9.9, while it does in 0.9.10 (on the same file), especially after noticing that the audio fifo has been made more than 5 times bigger! There must be something else... That said, the fact remains: the ts demux simply passes (one at a time) packet payloads to the decoders. I'll try and put my hands on it... since you seem quite sure the problem lies there :-) Ciao, Mauro. Miguel Freitas wrote: > Hi Mauro, > > Here we go again... i think it's the third time i talk about this > problem with TS demuxer... ;) > > Take a look at this message: > > From: Miguel Freitas <mi...@ce...> > To: xine-dev <xin...@li...> > Cc: shaheed <sr...@ie...> > Subject: [xine-devel] transport streams question > Date: 17 May 2002 18:53:26 -0300 > Hi folks, > > While testing latest demux_ts patches i noticed problems to play some > cnn transport streams under xine. One problem is related to still frame > code and i will do tests with dvd menus before commiting my fix. > > The other problem really puzzles me, so i'd like to ask advice to TS > especialists over there... Shaheed? ;) > > The ts files i tried have audio data much ahead (in time) from video. > This causes the audio decoder fifo to get full while video decoder is > still processing old frames. Since the full fifo blocks the demuxer, > video playback gets very sluggish (triggering still frame code several > times) while the audio plays fine. If i run xine without audio, the > demuxer doesn't block and video playback is ok. > > Since i can't control how these streams are generated, i hope something > could be done at demuxer stage to handle it better. debuging demux_ts i > noticed that all buffers being passed to decoders are only 156 or 168 > bytes long! This is too small and will create a needless pressure on > xine engine. Besides, it makes the stream unplayable. > > Is it possible to deliver data in larger chunks? Perhaps joining several > of this 156 bytes buffers into a single buffer? > |
From: Steve B. <sb...@co...> - 2002-05-28 14:15:36
|
Mauro Borghi wrote: > Hello Miguel, > > thanks for replying so quickly! Sorry I didn't notice your message 10 > days ago... :-} Very interesting! ;-) > > Yet I do not understand why this issue didn't show up in 0.9.9, while > it does in 0.9.10 (on the same file), especially after noticing that > the audio fifo has been made more than 5 times bigger! There must be > something else... > > That said, the fact remains: the ts demux simply passes (one at a > time) packet payloads to the decoders. > I'll try and put my hands on it... since you seem quite sure the > problem lies there :-) > > Ciao, > Mauro. > I put some printf's in buffer.c to track the # of available buffers. Results were pretty non-intuitive. 1. The same ts stream runs variously smoothly or haltingly on successive xine executions. 2. On the smooth plays, the video fifo fills up to about 200-300 and then starts to empty. 3. On the rough plays, same file, the fifo runs either empty (500-499-500-...) or full (1-0-1-...). While I'll admit that 175 bytes in a 8k buffer isn't efficient, I agree with Mauro that this might be something else. Steve |
From: Mauro B. <mau...@ti...> - 2002-05-28 16:09:29
Attachments:
demux_ts.c.diff
|
Hello, today some more testing was done, and besides confirming what Steve says, now I'm more confident the problem does not involve demuxing. A new buffering function has also been tested, which fills the buffers at will (a demux_ts.c diff against 0.9.10 attached). Here is a summary: - 0.9.10 + audio null --> ok - 0.9.10 + any demux_ts buffering --> 1. ok very few times 2. 20-30% video frames *skipped* 3. still frames continuously detected - 0.9.9 + demux_ts from 0.9.10 --> ok - 0.9.9 + demux_ts from 0.9.10 + new buffering --> ok I keep wondering what causes the problem: the new libmad? still frame detection or a/v sync strategies? the mpg logo? ...I'm just wildly guessing. With the more efficient buffering, an expected side effect pops up: increased latency due to more data waiting in the fifos (which in turn needs huge prebuffering at input stage, when watching live dvb programs -- especially annoying when zapping). A second and unexpected side effect is that the reworked demux_ts_buffer_pes seems to have broken the seek :-} -- but this is no worry... I simply had no time to do some more debugging (it's probably because the buffers being filled must be reset after a seek!) You'll find more add-ons in the attached diff: they were necessary for correct integration with the dvb input plugin, which (btw :-) would be ready for inclusion... once these malfunctions being addressed are solved. Looking forward for your comments and answers, ciao, Mauro. Steve Brown wrote: > I put some printf's in buffer.c to track the # of available buffers. > Results were pretty non-intuitive. > > 1. The same ts stream runs variously smoothly or haltingly on successive > xine executions. > 2. On the smooth plays, the video fifo fills up to about 200-300 and > then starts to empty. > 3. On the rough plays, same file, the fifo runs either empty > (500-499-500-...) or full (1-0-1-...). > > While I'll admit that 175 bytes in a 8k buffer isn't efficient, I agree > with Mauro that this might be something else. |
From: Steve B. <sb...@co...> - 2002-05-28 16:44:18
|
Mauro, I'm beginning to think that it's a timing problem with the mutex locks. Could there be a lockup when the fifo is either full or empty with the net effect being a single buffer fifo? This could explain why the same file sometimes works fine and sometimes doesn't. I'm not quite sure how to investigate this, maybe replace the lock/unlock calls w/ those in xine_mutex.c and look at some more logs. I'm pretty new to pthreads. Just some thoughts, Steve Mauro Borghi wrote: > Hello, > > today some more testing was done, and besides confirming what Steve > says, now I'm more confident the problem does not involve demuxing. > > A new buffering function has also been tested, which fills the buffers > at will (a demux_ts.c diff against 0.9.10 attached). > > Here is a summary: > > - 0.9.10 + audio null --> ok > > - 0.9.10 + any demux_ts buffering --> 1. ok very few times > 2. 20-30% video frames *skipped* > 3. still frames continuously > detected > > - 0.9.9 + demux_ts from 0.9.10 --> ok > - 0.9.9 + demux_ts from 0.9.10 + new buffering --> ok > > I keep wondering what causes the problem: the new libmad? still frame > detection or a/v sync strategies? the mpg logo? ...I'm just wildly > guessing. > > With the more efficient buffering, an expected side effect pops up: > increased latency due to more data waiting in the fifos (which in turn > needs huge prebuffering at input stage, when watching live dvb > programs -- especially annoying when zapping). > > A second and unexpected side effect is that the reworked > demux_ts_buffer_pes seems to have broken the seek :-} -- but this is > no worry... I simply had no time to do some more debugging (it's > probably because the buffers being filled must be reset after a seek!) > > You'll find more add-ons in the attached diff: they were necessary for > correct integration with the dvb input plugin, which (btw :-) would be > ready for inclusion... once these malfunctions being addressed are > solved. > > Looking forward for your comments and answers, > ciao, > Mauro. > |
From: Miguel F. <mi...@ce...> - 2002-05-28 19:21:38
|
Hi Mauro, I just tried your patch, it fixes the problem of playing the cnn test streams i have. So maybe for your streams there is another problem i'm not aware of... btw, i won't commit your patch right away as xine seems to hang on exit after ts use. Maybe there's some buffer leaking? (i haven't looked the patch yet) anyway keep up with your good work! :) regards, Miguel ps: don't hardcode MAX_PES_BUF_SIZE, you may get this value from buf->max_size. On Tue, 2002-05-28 at 13:08, Mauro Borghi wrote: > Hello, > > today some more testing was done, and besides confirming what Steve says, now > I'm more confident the problem does not involve demuxing. > > A new buffering function has also been tested, which fills the buffers at will > (a demux_ts.c diff against 0.9.10 attached). > > Here is a summary: > > - 0.9.10 + audio null --> ok > > - 0.9.10 + any demux_ts buffering --> 1. ok very few times > 2. 20-30% video frames *skipped* > 3. still frames continuously > detected > > - 0.9.9 + demux_ts from 0.9.10 --> ok > - 0.9.9 + demux_ts from 0.9.10 + new buffering --> ok > > I keep wondering what causes the problem: the new libmad? still frame > detection or a/v sync strategies? the mpg logo? ...I'm just wildly guessing. > > With the more efficient buffering, an expected side effect pops up: increased > latency due to more data waiting in the fifos (which in turn needs huge > prebuffering at input stage, when watching live dvb programs -- especially > annoying when zapping). > > A second and unexpected side effect is that the reworked demux_ts_buffer_pes > seems to have broken the seek :-} -- but this is no worry... I simply had no > time to do some more debugging (it's probably because the buffers being filled > must be reset after a seek!) > > You'll find more add-ons in the attached diff: they were necessary for correct > integration with the dvb input plugin, which (btw :-) would be ready for > inclusion... once these malfunctions being addressed are solved. > > Looking forward for your comments and answers, > ciao, > Mauro. > > Steve Brown wrote: > > I put some printf's in buffer.c to track the # of available buffers. > > Results were pretty non-intuitive. > > > > 1. The same ts stream runs variously smoothly or haltingly on successive > > xine executions. > > 2. On the smooth plays, the video fifo fills up to about 200-300 and > > then starts to empty. > > 3. On the rough plays, same file, the fifo runs either empty > > (500-499-500-...) or full (1-0-1-...). > > > > While I'll admit that 175 bytes in a 8k buffer isn't efficient, I agree > > with Mauro that this might be something else. > > ---- > |
From: Mauro B. <mau...@ti...> - 2002-05-29 15:40:25
Attachments:
demux_ts.c.diff
|
Hello! Heaps of good news :-) 1. Attached a new patch for demux_ts.c - seeking and stopping/exiting now work: as correctly foreseen by you, there were buffer leaks. 2. Decided to keep hardcoded MAX_PES_BUF_SIZE, setting it to 2048: this makes a good compromise between buffering and latency needs. 3. The frame-skipping problem (which keeps showing with debugged demux_ts - especially when *not* building with 'make debug') disappears removing xine-logo mrl from config file (so that nothing is played when starting xine or switching to different playlist items). [Steve, please try]. Just one bad news, about (3.): I don't know why ;-) Ciao, Mauro. Miguel Freitas wrote: > Hi Mauro, > > I just tried your patch, it fixes the problem of playing the cnn test > streams i have. So maybe for your streams there is another problem i'm > not aware of... > > btw, i won't commit your patch right away as xine seems to hang on exit > after ts use. Maybe there's some buffer leaking? (i haven't looked the > patch yet) anyway keep up with your good work! :) > > regards, > > Miguel > > ps: don't hardcode MAX_PES_BUF_SIZE, you may get this value from > buf->max_size. > > On Tue, 2002-05-28 at 13:08, Mauro Borghi wrote: > >>Hello, >> >>today some more testing was done, and besides confirming what Steve says, now >>I'm more confident the problem does not involve demuxing. >> >>A new buffering function has also been tested, which fills the buffers at will >>(a demux_ts.c diff against 0.9.10 attached). >> >>Here is a summary: >> >>- 0.9.10 + audio null --> ok >> >>- 0.9.10 + any demux_ts buffering --> 1. ok very few times >> 2. 20-30% video frames *skipped* >> 3. still frames continuously >> detected >> >>- 0.9.9 + demux_ts from 0.9.10 --> ok >>- 0.9.9 + demux_ts from 0.9.10 + new buffering --> ok >> >>I keep wondering what causes the problem: the new libmad? still frame >>detection or a/v sync strategies? the mpg logo? ...I'm just wildly guessing. >> >>With the more efficient buffering, an expected side effect pops up: increased >>latency due to more data waiting in the fifos (which in turn needs huge >>prebuffering at input stage, when watching live dvb programs -- especially >>annoying when zapping). >> >>A second and unexpected side effect is that the reworked demux_ts_buffer_pes >>seems to have broken the seek :-} -- but this is no worry... I simply had no >>time to do some more debugging (it's probably because the buffers being filled >>must be reset after a seek!) >> >>You'll find more add-ons in the attached diff: they were necessary for correct >>integration with the dvb input plugin, which (btw :-) would be ready for >>inclusion... once these malfunctions being addressed are solved. |
From: Steve B. <sb...@co...> - 2002-05-29 17:47:53
|
Mauro, I'm not sure what this means, but if I substitute my test file for the logo file in config, it plays (no dropped frames) regardless of debug/nodebug or with/without your buffer optimizations. Occasionally, the sound will not start or is choppy, but if I hit "stop", which restarts the logo mrl (now my test file), the sound works properly too. The buffering doesn't seem to be the issue here. I suspect it is either a mutex lock problem or the way the threads are scheduled. I've never tried to debug pthreads before. I can check for the former by using the errorcheck in mutex_init and maybe the latter by trying some of the other scheduling attrs in the pthread_create calls. My first suspicion is the scheduling. If there it were a lock problem, I think we would just see deadlocks and not timing-dependent behavior. Any ideas? Steve Mauro Borghi wrote: > Hello! > Heaps of good news :-) > > 1. Attached a new patch for demux_ts.c - seeking and stopping/exiting > now work: as correctly foreseen by you, there were buffer leaks. > > 2. Decided to keep hardcoded MAX_PES_BUF_SIZE, setting it to 2048: > this makes a good compromise between buffering and latency needs. > > 3. The frame-skipping problem (which keeps showing with debugged > demux_ts - especially when *not* building with 'make debug') > disappears removing xine-logo mrl from config file (so that nothing is > played when starting xine or switching to different playlist items). > [Steve, please try]. > > Just one bad news, about (3.): I don't know why ;-) > > Ciao, > Mauro. > |
From: Miguel F. <mi...@ce...> - 2002-05-29 19:29:59
|
Hi Steve, On Wed, 2002-05-29 at 14:47, Steve Brown wrote: > The buffering doesn't seem to be the issue here. I suspect it is either > a mutex lock problem or the way the threads are scheduled. I've never > tried to debug pthreads before. I can check for the former by using the > errorcheck in mutex_init and maybe the latter by trying some of the > other scheduling attrs in the pthread_create calls. > > My first suspicion is the scheduling. If there it were a lock problem, I > think we would just see deadlocks and not timing-dependent behavior. I'm not meant to discourage your debuging, quite the opposite... but have you considered that thread scheduling is probably working fine for every stream format except demux_ts? Anyway we really need to investigate why does the logo playing have any effect on next playbacks... regards, Miguel |
From: Steve B. <sb...@co...> - 2002-05-29 20:36:20
|
Miguel, Back to looking for races in demux_ts. There seems to be a missing line of code in 0.9.10. It fixes some, but not all problems. Steve Miguel Freitas wrote: > >Anyway we really need to investigate why does the logo playing have any >effect on next playbacks... > > >regards, > >Miguel > --- demux_ts.c.orig Wed May 29 13:20:27 2002 +++ demux_ts.c Wed May 29 13:04:05 2002 @@ -1191,6 +1191,7 @@ demux_ts *this = (demux_ts *)gen_this; buf_element_t *buf; + pthread_mutex_lock( &this->mutex ); /* do-while needed to seek after demux finished */ do { |
From: Miguel F. <mi...@ce...> - 2002-05-29 21:04:47
|
Hi Steve, hmmm, i just fixed this problem before reading your email! :) good catch! ;) regards, Miguel On Wed, 2002-05-29 at 17:36, Steve Brown wrote: > Miguel, > > Back to looking for races in demux_ts. > > There seems to be a missing line of code in 0.9.10. > > It fixes some, but not all problems. > > Steve > > > > Miguel Freitas wrote: > > > > >Anyway we really need to investigate why does the logo playing have any > >effect on next playbacks... > > > > > >regards, > > > >Miguel > > > --- demux_ts.c.orig Wed May 29 13:20:27 2002 > +++ demux_ts.c Wed May 29 13:04:05 2002 > @@ -1191,6 +1191,7 @@ > demux_ts *this = (demux_ts *)gen_this; > buf_element_t *buf; > > + pthread_mutex_lock( &this->mutex ); > /* do-while needed to seek after demux finished */ > do { > > > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Miguel F. <mi...@ce...> - 2002-05-29 21:03:17
|
Hi Mauro, Nice work! I just commited your patch to cvs, plus a small fix to demux loop. Another thing that occured me: isn't possible that some allocated m->buf would never be freed if we quit the demuxer? regards, Miguel On Wed, 2002-05-29 at 12:38, Mauro Borghi wrote: > Hello! > Heaps of good news :-) > > 1. Attached a new patch for demux_ts.c - seeking and stopping/exiting now > work: as correctly foreseen by you, there were buffer leaks. > > 2. Decided to keep hardcoded MAX_PES_BUF_SIZE, setting it to 2048: this makes > a good compromise between buffering and latency needs. > > 3. The frame-skipping problem (which keeps showing with debugged demux_ts - > especially when *not* building with 'make debug') disappears removing > xine-logo mrl from config file (so that nothing is played when starting xine > or switching to different playlist items). [Steve, please try]. > > Just one bad news, about (3.): I don't know why ;-) > > Ciao, > Mauro. |
From: Mauro B. <mau...@ti...> - 2002-05-30 15:05:56
|
Hi Miguel, Miguel Freitas wrote: > Hi Mauro, > > Nice work! Thanks :-) > > I just commited your patch to cvs, plus a small fix to demux loop. > Another thing that occured me: isn't possible that some allocated m->buf > would never be freed if we quit the demuxer? Is there any scenario where demux_ts_loop gets cancelled or demux_ts_close called without a demux_ts_stop? If so... then your thought might become true. Anyway... I'm going to check for nasty-special conditions... (e.g. when a put has just been performed, and seek is invoked, a buf might be freed before it gets to the decoders: segfault risk?) Ciao, Mauro. |
From: Miguel F. <mi...@ce...> - 2002-05-30 15:14:42
|
On Thu, 2002-05-30 at 12:04, Mauro Borghi wrote: > > I just commited your patch to cvs, plus a small fix to demux loop. > > Another thing that occured me: isn't possible that some allocated m->buf > > would never be freed if we quit the demuxer? > > Is there any scenario where demux_ts_loop gets cancelled or demux_ts_close > called without a demux_ts_stop? If so... then your thought might become true. Hey, forget what i said... i haven't noticed that buf's were always freed when loop finishes! :) > Anyway... I'm going to check for nasty-special conditions... (e.g. when a put > has just been performed, and seek is invoked, a buf might be freed before it > gets to the decoders: segfault risk?) No, i don't think this would be a problem since all code is protected by our mutex. We only briefly release it when it's safe to do so. But you might want to free the current bufs when seeking, so they won't contain garbage data after seek... regards, Miguel |
From: Mauro B. <mau...@ti...> - 2002-05-30 17:11:08
Attachments:
demux_ts.c.diff
|
Hi Miguel! Miguel Freitas wrote: > But you might want to free the current bufs when seeking, so they won't > contain garbage data after seek... bufs actually happen to be freed when seeking (which calls start, which in turn causes demux_ts_pes_new -- which eventually frees buf if needed) Please find attached new patch for demux_ts: - a couple of fixes on dynamically allocated mem (this->pmt[x] were assigned NULL before freeing); - a little fix to avoid freeing a buffer when we already put it in fifo; - ehm... code beautyfication (I don't like lines longer than 80 chars :-}) Ciao, Mauro. |
From: Miguel F. <mi...@ce...> - 2002-05-30 18:37:41
|
Patch applied! Is your dvb plugin ready for inclusion at xine tree? I just browsed your cvs and saw that the previously 3 plugins have already being merged, good! I hope Daniel may assist you with the configure / auto*magic stuff... ;) regards, Miguel On Thu, 2002-05-30 at 14:09, Mauro Borghi wrote: > Hi Miguel! > > Miguel Freitas wrote: > > But you might want to free the current bufs when seeking, so they won't > > contain garbage data after seek... > > bufs actually happen to be freed when seeking (which calls start, which in > turn causes demux_ts_pes_new -- which eventually frees buf if needed) > > Please find attached new patch for demux_ts: > > - a couple of fixes on dynamically allocated mem (this->pmt[x] were assigned > NULL before freeing); > - a little fix to avoid freeing a buffer when we already put it in fifo; > - ehm... code beautyfication (I don't like lines longer than 80 chars :-}) > > Ciao, > Mauro. > ---- > |
From: <bar...@t-...> - 2002-05-30 19:24:35
|
hi miguel, hi mauro, On 30 May 2002, Miguel Freitas wrote: > Patch applied! > > Is your dvb plugin ready for inclusion at xine tree? ...just to be sure: no objections from my side against the merger. very nice work! :) (i'm still waiting for my win tv nova card, hope to get it soon (i have found a sponsor for it :) - so for now i still cannot test any of the ts / dvb stuff) keep up the good work, guenter -- time is a funny concept |
From: Mauro B. <mau...@ti...> - 2002-05-31 18:18:57
|
Hi Miguel! Miguel Freitas wrote: > Patch applied! Good! :-) > > Is your dvb plugin ready for inclusion at xine tree? Yes, I think it's ready (it'll need updates, but cvs is there for exactly this reason). > > I just browsed your cvs and saw that the previously 3 plugins have > already being merged, good! I hope Daniel may assist you with the > configure / auto*magic stuff... ;) - the operating mode is now configurable from .xine/config (more config values are planned in the future, but the basic configs are there) - look at xine-lib/configure.in and xine-lib/src/input/Makefile.am on my cvs: the correct building is "sort of" auto-detected already... however I'd definitely like our autotools-guru (Daniel) to check and improve it CORBA support is ready as well! After some rethinking, I decided it was more sensible to have the idl interface reflecting actions.h. This is really a quick way to get scriptable support for xine, just running commands through xine-corba-remote, being a shell all that you need: $ xine-corba-remote mrl some.avi $ xine-corba-remote play $ ... A few more functions may be needed in the future, but you can do heaps of actions already. Now... it's late! And no internet during the week-end! We'll work out the details next week: so you have plenty of time to decide if I'm ready for cvs write access. ;-P If needed, my cvs is also accessible as anonymous, through pserver: cvs -d :pserver:ano...@ta...:/home/cvsroot login Then you can access modules 'xine-lib' and 'xine-ui'. Have a nice w-end! Ciao, Mauro. |
From: James Courtier-D. <Ja...@su...> - 2002-06-15 18:09:09
|
Mauro Borghi wrote: > Hello Miguel, > > thanks for replying so quickly! Sorry I didn't notice your message 10 > days ago... :-} Very interesting! ;-) > > Yet I do not understand why this issue didn't show up in 0.9.9, while > it does in 0.9.10 (on the same file), especially after noticing that > the audio fifo has been made more than 5 times bigger! There must be > something else... > > That said, the fact remains: the ts demux simply passes (one at a > time) packet payloads to the decoders. > I'll try and put my hands on it... since you seem quite sure the > problem lies there :-) > > Ciao, > Mauro. > > > > Miguel Freitas wrote: > >> Hi Mauro, >> >> Here we go again... i think it's the third time i talk about this >> problem with TS demuxer... ;) >> >> Take a look at this message: >> >> From: Miguel Freitas <mi...@ce...> >> To: xine-dev <xin...@li...> >> Cc: shaheed <sr...@ie...> >> Subject: [xine-devel] transport streams question >> Date: 17 May 2002 18:53:26 -0300 >> Hi folks, >> >> While testing latest demux_ts patches i noticed problems to play some >> cnn transport streams under xine. One problem is related to still frame >> code and i will do tests with dvd menus before commiting my fix. >> >> The other problem really puzzles me, so i'd like to ask advice to TS >> especialists over there... Shaheed? ;) >> >> The ts files i tried have audio data much ahead (in time) from video. >> This causes the audio decoder fifo to get full while video decoder is >> still processing old frames. Since the full fifo blocks the demuxer, >> video playback gets very sluggish (triggering still frame code several >> times) while the audio plays fine. If i run xine without audio, the >> demuxer doesn't block and video playback is ok. >> >> Since i can't control how these streams are generated, i hope something >> could be done at demuxer stage to handle it better. debuging demux_ts i >> noticed that all buffers being passed to decoders are only 156 or 168 >> bytes long! This is too small and will create a needless pressure on >> xine engine. Besides, it makes the stream unplayable. >> >> Is it possible to deliver data in larger chunks? Perhaps joining several >> of this 156 bytes buffers into a single buffer? >> > Could a possible solution to this be to make the demuxer decide on the fifo buffer sizes. demux_ts obviously like small buffers, whereas AVI and DVD like much bigger buffers. joining several small TS packets into a single larger packet could be problematic. E.g. Still frames, with just a single TS packet needed to make the entire frame, but the demuxer will be waiting for the next TS packet to arrive so it can make a bigger single packet. We would then have to re-implement all that clever still frame detection code currently in the video_out.c in the TS demuxer, just to get past this. It is due to this reason why I suggest letting the demuxer decide on fifo buffer sizes. Letting the demuxer decide on fifo buffer sizes does create a few problems of it's own. 1) Stream changes which causes a demuxer change. E.g. TS stream stops, xine logo is then displayed using MPEG_BLOCK. This would therefore require a total shut down of the demuxer and fifos between each item in the play list. Cheers James |