From: Reinhard N. <rn...@gm...> - 2006-01-27 23:08:16
Attachments:
xine-lib-demuxer.patch
|
Hi, a few words on the changes: WRAP_THRESHOLD: For any reason there are broadcasts where the offset between an audio PTS and a video PTS is much larger than originally expected offset. PTS wrap detection: See explanation in source. Preview buffer support: read_data() operates like input->read() when no prepared preview data is available. Otherwise it emulates reading the prepared preview data. All direct calls to input->read() in functions which are also used to process preview data had to be changed to read_data(). Preview data must be prepared and processed in case where the input plugin provides such data. Demuxer plugin selection based on XINE_DEMUX_CONTENT_STRATEGY now considers preview data, which has a higher priority than the self read preview data on seekable streams. The content detection now looks for all possible video and audio stream IDs as well as private1 and padding ID. The extension strategy now also accepts ".vdr" files. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rn...@gm... |
From: Thibaut M. <thi...@gm...> - 2006-01-30 11:06:25
|
On 1/28/06, Reinhard Nissl <rn...@gm...> wrote: > Hi, > > a few words on the changes: > > WRAP_THRESHOLD: > For any reason there are broadcasts where the offset between an audio > PTS and a video PTS is much larger than originally expected offset. > > PTS wrap detection: > See explanation in source. + V7 V8 A7 V9 Dv V0 Da A9 Dv V1 V2 A1 V3 V4 A3 You detect 3 discontinuities instead of 1 ? sounds a bit hacky. IMHO it would be better to move the discontinuity detection logic to the decoder loops, that would solve nicely your problem, and remove all the duplicated code from demuxers. Thibaut |
From: Michael R. <mr...@us...> - 2006-01-30 15:29:17
|
Hi, > IMHO it would be better to move the discontinuity detection logic to > the decoder loops, that would solve nicely your problem, and remove > all the duplicated code from demuxers. I don't remember having heard this idea before (maybe it's just my memory), but this sounds like a terrific idea. Michael |
From: James Courtier-D. <Ja...@su...> - 2006-02-01 08:46:30
|
Michael Roitzsch wrote: > Hi, > >> IMHO it would be better to move the discontinuity detection logic to >> the decoder loops, that would solve nicely your problem, and remove >> all the duplicated code from demuxers. > > I don't remember having heard this idea before (maybe it's just my > memory), but this sounds like a terrific idea. > > Michael > Moving the discontinuity detection to the decoder from the demuxer will break DVD playing. Be careful about changing anything there. |
From: Thibaut M. <thi...@gm...> - 2006-02-01 15:31:09
|
On 2/1/06, James Courtier-Dutton <Ja...@su...> wrote: > Michael Roitzsch wrote: > > Hi, > > > >> IMHO it would be better to move the discontinuity detection logic to > >> the decoder loops, that would solve nicely your problem, and remove > >> all the duplicated code from demuxers. > > > > I don't remember having heard this idea before (maybe it's just my > > memory), but this sounds like a terrific idea. > > > > Michael > > > > Moving the discontinuity detection to the decoder from the demuxer will > break DVD playing. Please explain why. I know that some input plugins (vdr, mms, maybe also dvdnav) are aware about discontinuities (or new stream start) but they currently rely on a specific behavior of the demuxer to handle the disc. The mms/asf case is really a bad hack. What's missing is a clean way to pass this info from the input plugin to the demuxer layer. > Be careful about changing anything there. Thibaut |
From: Michael R. <mr...@us...> - 2006-02-01 17:13:31
|
Hi James, >>> IMHO it would be better to move the discontinuity detection logic to >>> the decoder loops, that would solve nicely your problem, and remove >>> all the duplicated code from demuxers. >> I don't remember having heard this idea before (maybe it's just my >> memory), but this sounds like a terrific idea. >> Michael > > Moving the discontinuity detection to the decoder from the demuxer > will > break DVD playing. Not necessarily. The demuxer would still be free to use the NAV packets to handle discontinuities itself, so that any later generic discontinuity detection would not kick in. Michael |
From: Reinhard N. <rn...@gm...> - 2006-01-30 22:34:41
|
Hi, Thibaut Mattern wrote: >> a few words on the changes: >> >> WRAP_THRESHOLD: >> For any reason there are broadcasts where the offset between an audio >> PTS and a video PTS is much larger than originally expected offset. >> >> PTS wrap detection: >> See explanation in source. > > + V7 V8 A7 V9 Dv V0 Da A9 Dv V1 V2 A1 V3 V4 A3 > > You detect 3 discontinuities instead of 1? sounds a bit hacky. It's impossible to handle this issue in a different way with the current _x_demux_control_newpts() interface. > IMHO it would be better to move the discontinuity detection logic to > the decoder loops, that would solve nicely your problem, and remove > all the duplicated code from demuxers. This might work for PTS wraps, but I think it fails when a different amount of video and audio packets is missing, e. g. after "hard" cutting a recording. Audio and video could easily get out of sync in such a case. Just my 0.02 €. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rn...@gm... |
From: Julian S. <ju...@ju...> - 2006-02-05 14:44:46
|
Hi, Am Samstag, 28. Januar 2006 00:03 schrieb Reinhard Nissl: > WRAP_THRESHOLD: > For any reason there are broadcasts where the offset between an audio > PTS and a video PTS is much larger than originally expected offset. > > PTS wrap detection: > See explanation in source. just wanted to let you know, that this fix works fine for me - DVB-S transmission run without freezing after some hours, like they did before, now. Thanks, Julian |
From: Miguel F. <mfr...@gm...> - 2006-02-05 20:15:42
|
hi Thibaut, Reinhard, On 1/30/06, Thibaut Mattern <thi...@gm...> wrote: > On 1/28/06, Reinhard Nissl <rn...@gm...> wrote: > > Hi, > > > > a few words on the changes: > > > > WRAP_THRESHOLD: > > For any reason there are broadcasts where the offset between an audio > > PTS and a video PTS is much larger than originally expected offset. > > > > PTS wrap detection: > > See explanation in source. > > + V7 V8 A7 V9 Dv V0 Da A9 Dv V1 V2 A1 V3 V4 A3 > > You detect 3 discontinuities instead of 1 ? sounds a bit hacky. actually it doesn't sound that bad to me. yes, 3 discontinuities look strange but that stream _is_ strange. i never thought that i would be possible to have packets using the old pts values past a discontinuity. > IMHO it would be better to move the discontinuity detection logic to > the decoder loops, that would solve nicely your problem, and remove > all the duplicated code from demuxers. that might be an interesting idea in the long run (although we still need to think of possible implications), but Reinhard patch seems to address an important issue under the constraits of the current architecture. would you object to committing this patch? Miguel |
From: Thibaut M. <thi...@gm...> - 2006-02-06 09:39:10
|
On 2/5/06, Miguel Freitas <mfr...@gm...> wrote: > hi Thibaut, Reinhard, > > On 1/30/06, Thibaut Mattern <thi...@gm...> wrote: > > On 1/28/06, Reinhard Nissl <rn...@gm...> wrote: > > > Hi, > > > > > > a few words on the changes: > > > > > > WRAP_THRESHOLD: > > > For any reason there are broadcasts where the offset between an audio > > > PTS and a video PTS is much larger than originally expected offset. > > > > > > PTS wrap detection: > > > See explanation in source. > > > > + V7 V8 A7 V9 Dv V0 Da A9 Dv V1 V2 A1 V3 V4 A3 > > > > You detect 3 discontinuities instead of 1 ? sounds a bit hacky. > > actually it doesn't sound that bad to me. yes, 3 discontinuities look > strange but that stream _is_ strange. i never thought that i would be > possible to have packets using the old pts values past a > discontinuity. mpeg is evil... > > IMHO it would be better to move the discontinuity detection logic to > > the decoder loops, that would solve nicely your problem, and remove > > all the duplicated code from demuxers. > > that might be an interesting idea in the long run (although we still > need to think of possible implications), but Reinhard patch seems to > address an important issue under the constraits of the current > architecture. would you object to committing this patch? No. Anyway I don't have the time to propose something else. > Miguel Thibaut |
From: Miguel F. <mfr...@gm...> - 2006-02-06 11:56:09
|
On 2/6/06, Thibaut Mattern <thi...@gm...> wrote: > > architecture. would you object to committing this patch? > > No. > Anyway I don't have the time to propose something else. ok, i will commit it. btw, i never saw this c construction before: case 0xe0 ... 0xef: which seems quite nice, but does anybody knows where is it defined and if it is well supported? Miguel |
From: Mark A. <mar...@gm...> - 2006-02-06 12:11:33
|
> btw, i never saw this c construction before: > > case 0xe0 ... 0xef: > > which seems quite nice, but does anybody knows where is it defined and > if it is well supported? It's a GCC extension, supported since 2.95 or possibly earlier. Defined he= re: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC82 Mark |