Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.
Hi *,
ich habe grade (unabhängig von dem letzten patch, Danke fürs Übernehmen durchflieger!) eine interessante Entdeckung gemacht: Bei mir ändert sich das Systemverhalten (speziell bezüglich des unbefriedigenden Verhaltens beim Verschieben von HD-cutmarks) deutlich, wenn ich die Verbindung von vdr-sxfe (lokal) über udp (/usr/bin/vdr-sxfe --display=:0 "xvdr+udp://127.0.0.1:37890 ...) statt über tcp herstelle.
Mit udp funktioniert das Verschieben der HD-cutmarks (ÖR) bei mir gefühlt bei jedem möglichen frame. Bei tcp geschätzt nur ca. alle 2 -3 Sekunden. Leider ergeben sich mit udp andere Probleme, so gibts dann bei HD beim Zurückschalten von fastforward starke Pixelfragmente, ausserdem dauert das Starten von HD-Aufnahmen deutlich länger.
Ist also nicht die Lösung, aber mich wundert dass das Netzwerkprotokoll überhaupt eine Auswirkung an diesen Stellen hat.
@durchflieger: Was mich bei Dir als "Wissendem", der laut Sig auch xineliboutput verwendet interessieren würde: Hast Du eigentlich auch die allseits bekannten noch vorhandenen Probleme mit xineliboutput?
Grüße, Peter

Ich hatte bis jetzt noch keine Möglichkeit das zu testen, aber verbessert sich das Schnittmarken-Problem dadurch?
Wenn ich den Code richtig in Erinnerung habe, wird beim StillPicture der PTS auf 0 gesetzt.
Quoted
> 2.) When jumping to or moving cutmarks in SD, no picture is displayed.
> This makes cutting of SD content impossible right now. User maniac at
> vdr-portal.de has figured out that its fixed when in xine_input_vdr.c
> the comment signs in line 4848 are removed:
>
> /* delay frame 10ms (9000 ticks) */
> buf->content[12] = (uint8_t)((10*90) >> 7);
Interesting... Anyway, this code path is used only with vdr-1.6.0 (PES)
recordings. Similar hack for vdr-1.7.x recordings would need to go to
demux_xvdr.c. You need to add following line to function check_newpts():
if (video) {
int still_mode = (int)this->stream->metronom->get_option(this->stream->metronom, XVDR_METRONOM_STILL_MODE);
int trick_speed = (int)this->stream->metronom->get_option(this->stream->metronom, XVDR_METRONOM_TRICK_SPEED);
if (still_mode > 0 || trick_speed > 0) {
LOGMSG("Skipping new pts %"PRId64" (still=%d trickspeed=%d)", buf->pts, still_mode, trick_speed);
+ if (still_mode) buf->pts = 9000;
return;
}
}
Currently video frame PTS timestamp is not cleared, but it is also not
used to generate xine vpts. Maybe vdpau uses the original pts timestamp
for something ... ? That would cause problems.
> 3.) The same problem with jumping to or moving cutmarks also applies
> to HD video. It doesn't matter what xinelib decoder (normal h264 vdpau
> or the new "alter" one) is used. When using the xine-plugin from
> Robert Nissl, jumping to HD cutmarks or moving them is possible with
> the same system-setup.
> Right now no solution is know for xineliboutput, so it would be great
> if you could have an eye on it and eventually fix it.
What vdr version are you using ?
Moving cutting marks (still images) work perfectly well with software
decoders, so there must be something weird with timestamps. If you use
--verbose option, do you see any "frame dropped, too old..." or
"Skipping new pts"... etc. messages when moving cutting marks ?
OT: Schreib ihm mal das es Reinhard Nissl ist und nicht Robert... lol
Es gibt wieder Nachschub an der xine-lib Front...
Ich bin ja schon froh, dass sich überhaupt was tut.Ich froh nicht der einzige zu sein der dort den Überblick verloren hat, ich habe mir gestern diese Frage verkniffen, um nicht vor Euch als DAU dazustehenDas sind 2 wirklich sehr gute Fragen, ich habe den Überblick schon lange verloren.....
|
|
Source code |
1 2 3 |
git clone git://projects.vdr-developer.org/xine-lib.git cd /usr/local/src/xine-lib git checkout -b df-osd-handling+alter-vdpau-h264-decoder origin/df-osd-handling+alter-vdpau-h264-decoder |