From: shaheed <sr...@ie...> - 2001-07-29 21:31:20
Attachments:
demux_ts.c
|
Hi all, I have started hacking a Transport Stream Demux for 0.5. I stole some of the code from Paul Flinder's 0.4 code. The PATs and PMTs work (at least for some streams). Could some kind soul commit the patch to: xine-lib/src/demuxers/Makefile.am and add the attached file to the same directory please? Thanks, Shaheed |
From: Guenter B. <bar...@st...> - 2001-07-29 22:24:12
|
Hi Shaheed, On Sun, 29 Jul 2001, shaheed wrote: > I have started hacking a Transport Stream Demux for 0.5. I stole some of the > code from Paul Flinder's 0.4 code. The PATs and PMTs work (at least for some > streams). Could some kind soul commit the patch to: > > xine-lib/src/demuxers/Makefile.am > > and add the attached file to the same directory please? wow, cool somebody is working on this again. I've just commited your work to CVS - keep the patches coming! :-) Cheers, Guenter -- time is a funny concept |
From: shaheed <sr...@ie...> - 2001-07-30 03:03:53
|
Hi, Is there a good reason why PTS/DTS in xine are 32 bits? MPEG would certainly benefit from 33 (or 64, actually). Thanks, Shaheed |
From: Guenter B. <bar...@st...> - 2001-07-30 07:31:55
|
Hi Shaheed, On Mon, 30 Jul 2001, shaheed wrote: > Is there a good reason why PTS/DTS in xine are 32 bits? 32 bit are enough for 13h of video and are more efficient to handle than 64 bit values on the 32-bit processors available for home use today. dts values aren't used in xine at all btw. > MPEG would certainly benefit from 33 (or 64, actually). how? I never found a case where it could really help to have that extra bit. Cheers, Guenter -- time is a funny concept |
From: shaheed <sr...@ie...> - 2001-07-30 20:15:14
|
Hi Guenter, > On Mon, 30 Jul 2001, shaheed wrote: > > Is there a good reason why PTS/DTS in xine are 32 bits? > > 32 bit are enough for 13h of video and are more efficient to handle than > 64 bit values on the 32-bit processors available for home use today. dts > values aren't used in xine at all btw. Apart from the minimal cost of doing it right, there are certainly encoders and muxes that rollover the PCR right at the beginning of the content. Introducing truncation like this will just make the behaviour of audio/video sync at the beginning of such content unpredicatable. And then, when xine is used to tune in to a multicast Transport Stream, you have no idea (a) whether the wrap point is just a few seconds away, or (b) if the stream lasts longer than 26 h 30 m. Trust me: wrapping does occur in practice! Thanks, Shaheed |
From: Guenter B. <bar...@st...> - 2001-07-30 21:06:19
|
Hi Shaheed, On Mon, 30 Jul 2001, shaheed wrote: > > 32 bit are enough for 13h of video and are more efficient to handle than > > 64 bit values on the 32-bit processors available for home use today. dts > > values aren't used in xine at all btw. > > Apart from the minimal cost of doing it right, there are certainly encoders > and muxes that rollover the PCR right at the beginning of the content. > Introducing truncation like this will just make the behaviour of audio/video > sync at the beginning of such content unpredicatable. why would thatbe ? xine's metronom does handle these pts quite niceley > And then, when xine is used to tune in to a multicast Transport Stream, you > have no idea (a) whether the wrap point is just a few seconds away, or (b) if > the stream lasts longer than 26 h 30 m. > > Trust me: wrapping does occur in practice! I know just too well, even on DVDs PTS wrap, often quite suprisingly without hitting any 32 or 33-bit boundary. Xine's metronom takes care of it. Do you have any concrete example where that would go wrong? Cheers, Guenter -- time is a funny concept |
From: shaheed <sr...@ie...> - 2001-07-31 22:55:46
|
On Monday 30 July 2001 5:05 pm, Guenter Bartsch wrote: > > Apart from the minimal cost of doing it right, there are certainly > > encoders and muxes that rollover the PCR right at the beginning of the > > content. Introducing truncation like this will just make the behaviour of > > audio/video sync at the beginning of such content unpredicatable. > > why would thatbe ? xine's metronom does handle these pts quite niceley Hmmm. What happens when the video and audio PTSs are both about to wrap? Won't the audio PTS and video PTS (with the latter arriving out-of-display order) screw up? If not, then I'll be very happy. My inital comment was inspired when working on the demux_ts.c code: I thought there was a bug in PTS extraction toa 32 bit value. > Do you have any concrete example where that would go wrong? No. Perhaps you are right, and it all comes out in the wash. Thanks, Shaheed |
From: Guenter B. <bar...@st...> - 2001-08-01 09:43:03
|
Hi, On Wed, 1 Aug 2001, shaheed wrote: > > > Apart from the minimal cost of doing it right, there are certainly > > > encoders and muxes that rollover the PCR right at the beginning of the > > > content. Introducing truncation like this will just make the behaviour of > > > audio/video sync at the beginning of such content unpredicatable. > > > > why would thatbe ? xine's metronom does handle these pts quite niceley > > Hmmm. What happens when the video and audio PTSs are both about to wrap? > Won't the audio PTS and video PTS (with the latter arriving out-of-display > order) screw up? If not, then I'll be very happy. at least they shouldn't as metronom has some heuristics built-in for this case which will allow the audio and video PTS-offsets to be different for a short while. For really broken streams, metronom will force the two offsets to the same (greater) value after MAX_NUM_WRAP_DIFF failures - see metronom.c for details. Cheers, Guenter |
From: shaheed <sr...@ie...> - 2001-08-12 19:27:58
Attachments:
diff.txt
|
This patch to demux_ts.c removes some fprintf messages for some normal cases. These just get in the way. Please review and apply. |
From: James Courtier-D. <Ja...@su...> - 2001-08-12 23:54:48
|
I have tested this with a transport stream with MPEG2 Video and MPEG audio. I have not tested it with MPEG1 Video, or PCM or AC3 audio. In fact, I don't think it will currently work with AC3 audio. It will probably core dump. As I mentioned before, I checked out the latest CVS and it works fine on my system. Unless someone can give me the URL of a stream which does not work, I cannot fix things. If someone has a stream and understands Transport streams and the details of how the PES packets differ from Program Stream PES packets, then could they please provide constructive feed back, and not just "It does not work here." Cheers James > -----Original Message----- > From: xin...@li... > [mailto:xin...@li...]On Behalf Of shaheed > Sent: 13 August 2001 01:34 > To: xine-dev > Subject: [xine-devel] Patch to demux_ts.c to remove messages for some > normal cases. > > > > This patch to demux_ts.c removes some fprintf messages for some > normal cases. > These just get in the way. Please review and apply. > > |
From: shaheed <sr...@ie...> - 2001-08-13 20:06:29
|
Hi James, > As I mentioned before, I checked out the latest CVS and it works fine on my > system. > Unless someone can give me the URL of a stream which does not work, I > cannot fix things. I am using the same stream you pointed to (np.ts) as well as the one I pointed to earlier (ovs_mpg2_4096k_pal.m2t). If I am not mistaken, they both work for you. > If someone has a stream and understands Transport streams and the details > of how the PES packets differ from Program Stream PES packets, then could > they please provide constructive feed back, and not just "It does not work > here." I'm trying: since I believe the streams in question work for you, I was trying to understand enough to work out what might be going wrong. FWIW, I don't recall any differences between PES packets in Transport Streams and Program Streams (though I confess to being much more expert on TS than PS). I'll review the standards if I get a chance tomorrow. Thanks, Shaheed |
From: Ian L. <ile...@nt...> - 2001-08-13 22:02:51
|
On 2001.08.14 02:11 shaheed wrote: > > I am using the same stream you pointed to (np.ts) as well as the one I > pointed to earlier (ovs_mpg2_4096k_pal.m2t). If I am not mistaken, they > both > work for you. > > > If someone has a stream and understands Transport streams and the It's bombing in xineplug_vo_out_xshm.so. I just retested it on a box using Xvideo and it sort of works - it doesn't seg fault and I get audio. Could this be the reason? -- Ian Leonard eMail: ile...@nt... Phone: +44 (0)1865 765273 Please ignore spelling and punctuation - I did. |
From: James Courtier-D. <Ja...@su...> - 2001-08-13 22:51:40
|
Ok, I have the following: - ovs.m2t and np.ts work for me with XV and XShm. ovs.m2t is a picture of a garden, followed by a boy sitting next to a reflective sphere, with oss sound using EMU10K1 driver from opensource.creative.com. np.ts is just people sitting round a pool. When in XShm mode (-V XShm): - 16 depth (16 bpp) red: 0000f800, green: 000007e0, blue: 0000001f yuv2rgb: using MMXEXT for colorspace transform. I have a Geforce256 graphics card with Nvidia XV drivers installed. This might be a colour depth problem if vo_out_xshm is causing the crash, or a graphics card incompatibility. Cheers James > -----Original Message----- > From: xin...@li... > [mailto:xin...@li...]On Behalf Of Ian Leonard > Sent: 13 August 2001 23:05 > To: xine-dev > Cc: xine-dev > Subject: Re: [xine-devel] Patch to demux_ts.c to remove messages for > some normal cases. > > > > On 2001.08.14 02:11 shaheed wrote: > > > > I am using the same stream you pointed to (np.ts) as well as the one I > > pointed to earlier (ovs_mpg2_4096k_pal.m2t). If I am not mistaken, they > > both > > work for you. > > > > > If someone has a stream and understands Transport streams and the > > It's bombing in xineplug_vo_out_xshm.so. I just retested it on a box > using Xvideo and it sort of works - it doesn't seg fault and I get audio. > > Could this be the reason? > > -- > Ian Leonard > eMail: ile...@nt... > Phone: +44 (0)1865 765273 > > Please ignore spelling and punctuation - I did. > > _______________________________________________ > xine-devel mailing list > xin...@li... > http://lists.sourceforge.net/lists/listinfo/xine-devel |
From: James Courtier-D. <Ja...@su...> - 2001-08-13 23:51:46
|
Hello I have just added a new patch to the demux_ts.c CVS to catch one possible method of seg faulting. (Null audio plugin) There are currently other reasons why it could segfault (SPUfifo does not actually exist, it should use VideoFifo instead), but they do not seem to effect the successful playback of the ovs...m2t test stream. I have found that the libmad tends to crash my system. So I would delete the mad libs from /usr/local/lib/xine/plugins/*mad* It will then use libmpg123 instead which is far more stable. What does "mad" stand for anyway. Could I suggest to the list that when new plugins are added to the CVS, that they take lower priority than current ones, until enough people have tested them. Cheers James > -----Original Message----- > From: xin...@li... > [mailto:xin...@li...]On Behalf Of James > Courtier-Dutton > Sent: 13 August 2001 23:53 > To: Ian Leonard > Cc: xine-dev > Subject: RE: [xine-devel] Patch to demux_ts.c to remove messages for > some normal cases. > > > Ok, I have the following: - > ovs.m2t and np.ts work for me with XV and XShm. > ovs.m2t is a picture of a garden, followed by a boy sitting next to a > reflective sphere, with oss sound using EMU10K1 driver from > opensource.creative.com. > np.ts is just people sitting round a pool. > > When in XShm mode (-V XShm): - > 16 depth (16 bpp) red: 0000f800, green: 000007e0, blue: 0000001f > yuv2rgb: using MMXEXT for colorspace transform. > > I have a Geforce256 graphics card with Nvidia XV drivers installed. > > This might be a colour depth problem if vo_out_xshm is causing > the crash, or > a graphics card incompatibility. > > Cheers > James > > > > -----Original Message----- > > From: xin...@li... > > [mailto:xin...@li...]On Behalf Of Ian Leonard > > Sent: 13 August 2001 23:05 > > To: xine-dev > > Cc: xine-dev > > Subject: Re: [xine-devel] Patch to demux_ts.c to remove messages for > > some normal cases. > > > > > > > > On 2001.08.14 02:11 shaheed wrote: > > > > > > I am using the same stream you pointed to (np.ts) as well as the one I > > > pointed to earlier (ovs_mpg2_4096k_pal.m2t). If I am not > mistaken, they > > > both > > > work for you. > > > > > > > If someone has a stream and understands Transport streams and the > > > > It's bombing in xineplug_vo_out_xshm.so. I just retested it on a box > > using Xvideo and it sort of works - it doesn't seg fault and I > get audio. > > > > Could this be the reason? > > > > -- > > Ian Leonard > > eMail: ile...@nt... > > Phone: +44 (0)1865 765273 > > > > Please ignore spelling and punctuation - I did. > > > > _______________________________________________ > > xine-devel mailing list > > xin...@li... > > http://lists.sourceforge.net/lists/listinfo/xine-devel > > > _______________________________________________ > xine-devel mailing list > xin...@li... > http://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Guenter B. <bar...@st...> - 2001-08-14 00:23:14
|
Hi James, On Tue, 14 Aug 2001, James Courtier-Dutton wrote: > I have just added a new patch to the demux_ts.c CVS to catch one possible > method of seg faulting. (Null audio plugin) ...I'm looking for some ts test streams, could you point me to one perhaps? I intend to do some performance tweaking next (already working on a profiler here) and I think maybe a smaller memory footprint could help xine's performance. So I'd implement package splitting in your demuxer if you don't have time, but I need a test stream for that. > I have found that the libmad tends to crash my system. So I would delete the > mad libs from /usr/local/lib/xine/plugins/*mad* > It will then use libmpg123 instead which is far more stable. What does "mad" > stand for anyway. mad : MPEG Audio Decoder http://www.mars.org/home/rob/proj/mpeg/ what's the problem with it? Here it works very nicely and the code is much cleaner than libmpg123 especially in respect to reentrancy and stack usage (important on FreeBSD) so I guess we'll remove the libmpg123 plugin real soon. Could you provide some stack traces or test streams so I can reproduce your problems with libmad? > Could I suggest to the list that when new plugins are added to the CVS, that > they take lower priority than current ones, until enough people have tested > them. hum, the question is how many people will test a plugin if it's not used by default. I got _zero_ feedback on the ffmpeg plugin while it was disabled by default. Cheers, Guenter |
From: shaheed <sr...@ie...> - 2001-08-16 00:06:12
|
Thanks to some clues in the recent notes from James and Ian, I upgraded my GeForce 256 with nVidia's drivers and I too can get both the pieces of M2T sample content to play using Xv. I think I am seeing still some side effects of unbounded PES packets: messages such as ... nowhere to buffer input (corrupt stream?) nowhere to buffer input (corrupt stream?) nowhere to buffer input (corrupt stream?) nowhere to buffer input (corrupt stream?) nowhere to buffer input (corrupt stream?) Buffer overflow on data read for PES (corrupt stream?) ... and also 200 frames delivered, 12 frames skipped, 15 frames discarded 200 frames delivered, 0 frames skipped, 0 frames discarded 200 frames delivered, 0 frames skipped, 2 frames discarded with both sample streams, but it is looking good anyway. I think I do see some decoding errors, though these could also be related to the above messages. The symptoms are: ns.tp: top edge of pink bikini edge breaks up briefly. ovs.m2t: hiccup about 0.5 seconds in, brief breakup before and after "Introducing Network Computers" logo shot. XShm is still broken for me...I guess I'd have to learn a bit more about clour depths etc. to get to the bottom of that. The failing thread seems to have a useless bt: (gdb) bt #0 0x40362474 in mmxext_rgb16 () from /usr/local/lib/xine/plugins/xineplug_vo_out_xshm.so (gdb) q When I get a moment, I'll finish the gdb upgrade to see if I can get more info. FWIW, I actually have a Duron processor. Thanks! Shaheed |
From: James Courtier-D. <Ja...@su...> - 2001-08-16 06:57:56
|
So the bug is in XShm and not demux_ts.c as Xv works and XShm does not. Sounds like the MMX sensing code in Xine needs improving. When I get a mo, I will change all the debug messages. Most of the current ones can be ignored. Once the demux_ts.c supports discontinuities, most of these messages will disappear. Cheers James > -----Original Message----- > From: xin...@li... > [mailto:xin...@li...]On Behalf Of shaheed > Sent: 16 August 2001 06:13 > To: xine-dev > Cc: James Courtier-Dutton; Ian Leonard > Subject: [xine-devel] woohoo! demux_ts.c now works for me! > > > > Thanks to some clues in the recent notes from James and Ian, I > upgraded my > GeForce 256 with nVidia's drivers and I too can get both the > pieces of M2T > sample content to play using Xv. I think I am seeing still some > side effects > of unbounded PES packets: messages such as > > ... > nowhere to buffer input (corrupt stream?) > nowhere to buffer input (corrupt stream?) > nowhere to buffer input (corrupt stream?) > nowhere to buffer input (corrupt stream?) > nowhere to buffer input (corrupt stream?) > Buffer overflow on data read for PES (corrupt stream?) > ... > > and also > > 200 frames delivered, 12 frames skipped, 15 frames discarded > 200 frames delivered, 0 frames skipped, 0 frames discarded > 200 frames delivered, 0 frames skipped, 2 frames discarded > > with both sample streams, but it is looking good anyway. I think I do see > some decoding errors, though these could also be related to the above > messages. The symptoms are: > > ns.tp: top edge of pink bikini edge breaks up briefly. > > ovs.m2t: hiccup about 0.5 seconds in, brief breakup before and after > "Introducing Network Computers" logo shot. > > XShm is still broken for me...I guess I'd have to learn a bit more about > clour depths etc. to get to the bottom of that. The failing > thread seems to > have a useless bt: > > (gdb) bt > #0 0x40362474 in mmxext_rgb16 () > from /usr/local/lib/xine/plugins/xineplug_vo_out_xshm.so > (gdb) q > > When I get a moment, I'll finish the gdb upgrade to see if I can get more > info. FWIW, I actually have a Duron processor. > > Thanks! Shaheed > > _______________________________________________ > xine-devel mailing list > xin...@li... > http://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Ian L. <ile...@nt...> - 2001-08-16 10:04:49
|
On 2001.08.16 07:58 James Courtier-Dutton wrote: > So the bug is in XShm and not demux_ts.c as Xv works and XShm does not. > Sounds like the MMX sensing code in Xine needs improving. Indeed. I got it working with my Nvidia card (thanks for the instructions, James) I now have the following situaltion: Box 1. XShm, coredump. Xv works fine. Box 2. Works once but kills X on second play. One obvious difference between Box 1 and 2 is that Box 1 has 384mb of ram and box 2 only has 64mb (although top suggests there is ram to spare). > When I get a mo, I will change all the debug messages. > Most of the current ones can be ignored. Once the demux_ts.c supports > discontinuities, most of these messages will disappear. Is there anything I can do to bring this about? It's not my bag but I'll have a look if no one else is able to do it. > Cheers > James > > > > -----Original Message----- > > From: xin...@li... > > [mailto:xin...@li...]On Behalf Of shaheed > > Sent: 16 August 2001 06:13 > > To: xine-dev > > Cc: James Courtier-Dutton; Ian Leonard > > Subject: [xine-devel] woohoo! demux_ts.c now works for me! > > > > > > > > Thanks to some clues in the recent notes from James and Ian, I > > upgraded my > > GeForce 256 with nVidia's drivers and I too can get both the > > pieces of M2T > > sample content to play using Xv. I think I am seeing still some > > side effects > > of unbounded PES packets: messages such as > > > > ... > > nowhere to buffer input (corrupt stream?) > > nowhere to buffer input (corrupt stream?) > > nowhere to buffer input (corrupt stream?) > > nowhere to buffer input (corrupt stream?) > > nowhere to buffer input (corrupt stream?) > > Buffer overflow on data read for PES (corrupt stream?) > > ... > > > > and also > > > > 200 frames delivered, 12 frames skipped, 15 frames discarded > > 200 frames delivered, 0 frames skipped, 0 frames discarded > > 200 frames delivered, 0 frames skipped, 2 frames discarded > > > > with both sample streams, but it is looking good anyway. I think I do > see > > some decoding errors, though these could also be related to the above > > messages. The symptoms are: > > > > ns.tp: top edge of pink bikini edge breaks up briefly. > > > > ovs.m2t: hiccup about 0.5 seconds in, brief breakup before and > after > > "Introducing Network Computers" logo shot. > > > > XShm is still broken for me...I guess I'd have to learn a bit more > about > > clour depths etc. to get to the bottom of that. The failing > > thread seems to > > have a useless bt: > > > > (gdb) bt > > #0 0x40362474 in mmxext_rgb16 () > > from /usr/local/lib/xine/plugins/xineplug_vo_out_xshm.so > > (gdb) q > > > > When I get a moment, I'll finish the gdb upgrade to see if I can get > more > > info. FWIW, I actually have a Duron processor. > > > > Thanks! Shaheed > > > > _______________________________________________ > > xine-devel mailing list > > xin...@li... > > http://lists.sourceforge.net/lists/listinfo/xine-devel > > > _______________________________________________ > xine-devel mailing list > xin...@li... > http://lists.sourceforge.net/lists/listinfo/xine-devel > -- Ian Leonard eMail: ile...@nt... Phone: +44 (0)1865 765273 Please ignore spelling and punctuation - I did. |
From: shaheed <sr...@ie...> - 2001-08-12 19:48:43
|
Hi all, Is demux_ts.c supposed to deliver PES data or elementary stream data? At the moment, it seems to deliver PES data...but that does not make sense unless xine-lib automagically knows that a PES stream rather than a video elementary stream is going to be delivered. Does it automatically instantiate some kind of PES demuxing - if not why would the video decoder even want to get PES data? I know this is a dumb question, but I cannot understand what is going on with demux'ing API. I hope someone can clarify - maybe I can then get demux_ts.c to work for me. Thanks, Shaheed |
From: James Courtier-D. <Ja...@su...> - 2001-08-12 23:35:23
|
demux_ts.c delivers packets to the decoders in a xine proprietary format. The suppose it is quite similar to Elementary streams. The current demux_ts.c creates PES packets from the Transport stream in "demux_ts_pes_buffer" then sends them to "demux_ts_queue_pes" to decode the PES packet and put a decoded PES packet data portion(not header) on the fifo->put to the decoders. Cheers James > -----Original Message----- > From: xin...@li... > [mailto:xin...@li...]On Behalf Of shaheed > Sent: 13 August 2001 01:55 > To: xine-dev > Subject: [xine-devel] newbie question about demux'ing API > > > Hi all, > > Is demux_ts.c supposed to deliver PES data or elementary stream > data? At the > moment, it seems to deliver PES data...but that does not make > sense unless > xine-lib automagically knows that a PES stream rather than a > video elementary > stream is going to be delivered. Does it automatically > instantiate some kind > of PES demuxing - if not why would the video decoder even want to get PES > data? > > I know this is a dumb question, but I cannot understand what is > going on with > demux'ing API. I hope someone can clarify - maybe I can then get > demux_ts.c > to work for me. > > Thanks, Shaheed > > _______________________________________________ > xine-devel mailing list > xin...@li... > http://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Billy B. <ve...@du...> - 2001-07-30 21:15:29
|
shaheed (sr...@ie...): > > 32 bit are enough for 13h of video and are more efficient to handle > > than 64 bit values on the 32-bit processors available for home use > > today. dts values aren't used in xine at all btw. > > Apart from the minimal cost of doing it right, there are certainly > encoders and muxes that rollover the PCR right at the beginning of the > content. Introducing truncation like this will just make the > behaviour of audio/video sync at the beginning of such content > unpredicatable. When playing DVD streams, for example, it's pretty much impossible to tell when SCR discontinuities will occur. Basically, you have to assume that any jump > +- 5000 or so in the SCR is a discontinuity, and estimate the jump from the last clock you saw, keeping an internal clock that's always incrementing. xine does the same. So, in my player, I do what xine does and drop the high bit. If there's a case where wrapping and a discontinuity are not the same, please enlighten me. -- Billy Biggs bb...@du... http://www.billybiggs.com/ wb...@uw... |
From: shaheed <sr...@ie...> - 2001-07-31 22:47:36
|
On Monday 30 July 2001 5:12 pm, Billy Biggs wrote: > So, in my player, I do what xine does and drop the high bit. If > there's a case where wrapping and a discontinuity are not the same, > please enlighten me. You guys are the decoder experts: I'm more familiar with the mux end, so perhaps I am wrong on this. Anyway, AFAICS, the difference is that one can be construed as an error case, and the other cannot. Thus, in the case of a discontinuity, it is perfectly valid for a decoder to freeze the last complete frame, discard any partial pictures, and then wait for the next picture or random access point. For example, when you perform a seek operation to a video server (e.g. both OVS, and the now-defuct Mediaplex), the stream is very likely to contain complete picture sent before seek invoked partial picture sent before seek invoked SEEK more partial picture sent before seek invoked discontinuity inserted by server first picture from seek'd location Note that some video servers might not send a formal discontinity (e.g. discontinity_indicator = 1 etc.). In all cases, the decoder will see a timing discontinuity. If it treats this as a wrapping point, the screen will likely be corrupted (and of course, it could happen "near" a wrap point). Does this make sense? Thanks, Shaheed |
From: Michel L. <wa...@zo...> - 2001-07-31 23:50:20
|
On Tue, Jul 31, 2001 at 11:52:29PM -0400, shaheed wrote: > On Monday 30 July 2001 5:12 pm, Billy Biggs wrote: > Thus, in the case of a discontinuity, it is perfectly valid for a decoder to > freeze the last complete frame, discard any partial pictures, and then wait > for the next picture or random access point. For example, when you perform a > seek operation to a video server (e.g. both OVS, and the now-defuct > Mediaplex), the stream is very likely to contain > > complete picture sent before seek invoked > partial picture sent before seek invoked > SEEK > more partial picture sent before seek invoked > discontinuity inserted by server > first picture from seek'd location > > Note that some video servers might not send a formal discontinity > (e.g. discontinity_indicator = 1 etc.). In all cases, the decoder > will see a timing discontinuity. If it treats this as a wrapping > point, the screen will likely be corrupted (and of course, it could > happen "near" a wrap point). Hmmm, you do get a point on that one. I still think it doesnt really matter though, since most of the time we will be able to detect the discontinuity by only looking at the 32 lower bits. But, if the discontinuity is 13 hours plus or minus epsilon with epsilon shorter than the discontinuity error detection threshold (should be 1 second or so), then yeah we will not detect this properly. The probability is only twice higher than if we seeked to another part of the stream that had the full 33 bits to a close value though (say, seeking a multiple of 26 hours in a continuous stream) -- Michel "Walken" LESPINASSE Of course I think I'm right. If I thought I was wrong, I'd change my mind. |
From: Guenter B. <bar...@st...> - 2001-08-01 09:45:48
|
Hiho, On Tue, 31 Jul 2001, Michel LESPINASSE wrote: > > For example, when you perform a > > seek operation to a video server (e.g. both OVS, and the now-defuct > > Mediaplex), the stream is very likely to contain > > > > complete picture sent before seek invoked > > partial picture sent before seek invoked > > SEEK > > more partial picture sent before seek invoked > > discontinuity inserted by server > > first picture from seek'd location > > > > Note that some video servers might not send a formal discontinity > > (e.g. discontinity_indicator = 1 etc.). In all cases, the decoder > > will see a timing discontinuity. If it treats this as a wrapping > > point, the screen will likely be corrupted (and of course, it could > > happen "near" a wrap point). that certainly does sound bad. I'm glad seeking in xine doesn't work this way (the engine is completely re-started when the user seeks) Cheers, Guenter -- time is a funny concept |
From: Michel L. <wa...@zo...> - 2001-07-30 22:03:23
|
On Mon, Jul 30, 2001 at 09:20:26PM -0400, shaheed wrote: > Trust me: wrapping does occur in practice! Sure. So we have to handle it. Once we handle wrapping correctly, we dont care wether it happens every 13 hours or every 26 hours. So 32 bits are fine :) I like the 32-bit pts values, because they allow to handle that kind of wrapping transparently, by being careful to always consider differences between pts values. Like, doing if (pts2 - pts1 > limit) instead of if (pts2 > pts1 + limit). We still need some additional code to handle clock discontinuities though (as opposed to simple wraps) Regards, -- Michel "Walken" LESPINASSE Of course I think I'm right. If I thought I was wrong, I'd change my mind. |