From: tiqq <ti...@gm...> - 2009-01-14 17:53:54
|
Hi! With some mkv files I had many discontinuity events. I found out, that if changing the timecode_diff in demux_matroska.c from int to int16_t fixes this problem. Using int will never produce negative values if int is not 16 Bit.... Are negative values allowed here? Since I don´t have the spec, I don´t know if this is a bug in the encoder or in xine. Coul´d some one check this out? Here is the possible code change in demux_matroska.c: static int parse_block (demux_matroska_t *this, uint64_t block_size, uint64_t cluster_timecode, uint64_t block_duration, int normpos, int is_key) { matroska_track_t *track; int64_t track_num; uint8_t *data; uint8_t flags; int gap, lacing, num_len; - int timecode_diff; + int16_t timecode_diff; int64_t pts, xduration; int decoder_flags = 0; data = this->block_data; if (!(num_len = parse_ebml_uint(this, data, &track_num))) return 0; data += num_len; - timecode_diff = (int)_X_BE_16(data); + timecode_diff = (int16_t)_X_BE_16(data); data += 2; flags = *data; data += 1; |
From: Darren S. <li...@yo...> - 2009-01-14 23:37:54
|
I demand that tiqq may or may not have written... > With some mkv files I had many discontinuity events. I found out, that if > changing the timecode_diff in demux_matroska.c from int to int16_t fixes > this problem. Using int will never produce negative values if int is not 16 > Bit.... > Are negative values allowed here? Since I don´t have the spec, I don't know > if this is a bug in the encoder or in xine. Could some one check this out? http://www.matroska.org/technical/specs/index.html#simpleblock_structure, AFAICS, says that you're right. Could you turn this into a proper patch? (I'd also prefer to import the patch using a real name rather than a pseudonym...) [snip] -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Dumb luck beats sound planning every time. Trust me. |
From: tiqq <ti...@gm...> - 2009-01-15 14:09:16
Attachments:
matroska.c.diff
|
>I demand that tiqq may or may not have written... >> With some mkv files I had many discontinuity events. I found out, that if >> changing the timecode_diff in demux_matroska.c from int to int16_t fixes >> this problem. Using int will never produce negative values if int is not >> 16 >> Bit.... >> Are negative values allowed here? Since I don´t have the spec, I don't >> know >> if this is a bug in the encoder or in xine. Could some one check this >> out? >http://www.matroska.org/technical/specs/index.html#simpleblock_structure, >AFAICS, says that you're right. Didn´t found that spec - thanks :) >Could you turn this into a proper patch? Do you mean a cvs diff? Attached... >(I'd also prefer to import the patch using a real name rather than a >pseudonym...) Dirk Leber is my name. Regards, Dirk |
From: Darren S. <li...@yo...> - 2009-01-15 15:32:19
Attachments:
matroska_pts_fix.patch
|
I demand that tiqq may or may not have written... >> I demand that tiqq may or may not have written... >>> With some mkv files I had many discontinuity events. I found out, that >>> if changing the timecode_diff in demux_matroska.c from int to int16_t >>> fixes this problem. Using int will never produce negative values if int >>> is not 16 Bit.... Are negative values allowed here? Since I don´t have >>> the spec, I don't know if this is a bug in the encoder or in xine. >>> Could some one check this out? >> http://www.matroska.org/technical/specs/index.html#simpleblock_structure, >> AFAICS, says that you're right. > Didn´t found that spec - thanks :) It took me about a minute or so to find it (and you mean "didn't find"). >> Could you turn this into a proper patch? > Do you mean a cvs diff? Attached... "hg diff" with something suitable for use as a commit message; in this case, I think that a changelog entry in the diff would be useful too. Using the message subject as a patch summary and body text as an extended description is useful; attaching an exported commit is also good. Were we still using CVS for xine-lib, "cvs diff -u" (in the root dir of the checked-out source) would be what's wanted. >> (I'd also prefer to import the patch using a real name rather than a >> pseudonym...) > Dirk Leber is my name. I now have enough information to construct the patch myself and properly attribute it. (It's still better if that's done by the patch submitter, of course...!) Patch attached for reference (I've added a changelog entry). I'll commit it soonish. -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Screenwriters apply character personalities like Post-It notes. |
From: Jason T. <ta...@ur...> - 2009-01-17 21:13:44
|
On Wed, 2009-01-14 at 18:53 +0100, tiqq wrote: > With some mkv files I had many discontinuity events. > I found out, that if changing the timecode_diff in demux_matroska.c > from int to int16_t fixes this problem. > Using int will never produce negative values if int is not 16 Bit.... I'm fairly certain (I haven't updated xine-lib yet to verify) that this has been plaguing me for a year or two. I never found the time to dig in and investigate, so I basically stopped using xine to play .mkv files. So thanks very much for tracking this down! (And thanks Darren for committing.) Cheers, Jason. |