No reply at all.
Not even a rejection.
And no explaination why :-(
Well, as promised here comes v3 of my patch,
including an improved mpegts time display.
It really does fix some issues here (and on my brother's notebook, too).
For a complete description, see my earlier post.
BTW the correct kaffeine dvb feed address is
(got this wrong in the readme only, not in actual patch).
Maybe I should post this to Kaffeine forum instead??
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
From: Petri Hintukainen <phintuka@us...> - 2011-07-08 09:55:46
Torsten Jager wrote:
> I'm disappointed.
> No reply at all.
> Not even a rejection.
> And no explaination why :-(
> Well, as promised here comes v3 of my patch,
> including an improved mpegts time display.
There are multiple independent changes in the patch, you should split
it. For example, changes to mpeg_ts.c should be in two patches: "mpeg-ts
bitrate estimation" and "skip first incomplete frame".
Preferred method is to commit each change locally and either use "hg
email" or export the changesets with "hg export" and email resulting
files. This way patches (including your name+email and commit
descriptions) can be imported directly to version control system.
@ds: are patch submission guidelines documented somewhere ?
Some notes about the changes to mpeg-ts demuxer:
Rate estimation looks good, I'd like to see it included (it should
improve BluRay time display too).
Time tracking is based on (all) audio stream PTS values; how does this
work with multiple audio streams ?
Another option would be using PCR (see demux_ts_adaption_field_parse()
return value). That should also give more accurate bit rate over short
time perioids, as it represents the the time when packet was muxed.
Payload streams are typically VBR, and there are no strict rules when
each payload packet should be muxed. The locations of PTS timestamps in
the stream are only loosely related to "real" transmission time. PCR
should also be present if there is no audio stream(s) or audio is
Skipping first incomplete frame should be per stream, not for video and
audio. In DVB broadcasts multiple audio streams/languages are common;
also practically every BluRay disc has multiple audio streams.
Note that skipping first incomplete packet is already implemented:
corrupted_pes flag is set to 1 in initialization (demux_ts_pes_new())
and after seek (demux_ts_seek()). This causes all data to be discarded
until next PUSI.
I believe your problem is caused by preview buffers: beginning of 5 (?)
first PES packets is marked as PREVIEW, and not used by decoders. Rest
of the PES packet is fed to decoders as normal data. You can verify this
theory by setting corrupted_pes flag to 1 every time buffer is flagged
as HEADER or PREVIEW ; that should discard rest of the PES packet.
I wouldn't accept any hacks hiding it - instead the cause (preview
flagging the first buffers) should be fixed. It causes dropping of first
GOP of .ts files --> it makes BluRay still images impossible to