http://bugs.xine-project.org/show_bug.cgi?id=381 Summary: Xine doesn't handle large A-V PTS differences (as in
some broadcasts) correctly
Product: xine-lib
Version: 1.1.19
Platform: AMD64/x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: Core / Backend
AssignedTo:
xine-bugs@...
ReportedBy:
mhej@...
Created an attachment (id=235)
--> (
http://bugs.xine-project.org/attachment.cgi?id=235)
PCR, PTS/DTS of video stream, and PTS of audio stream (where prefixed with
"AUDIO")
Some of DVB-T broadcasts with H.264 video (like these in Poland) have a large
difference between audio and video timestamps. In this case they are about 3
seconds.
When provided with stream (or file) of packets with that kind of difference
Xine plays it like a slideshow (with cutting audio or no audio at all).
Mplayer also has problems with default demuxer, however when used with -demuxer
lavf and -mc 4 (for max 4 second A-V difference) it plays the stream correctly.
When I applied a rather crude patch to substract about 3 seconds from video PTS
and DTS the stream play smoothly (of course with a 3 second difference between
what is on screen and what is on audio track).
This practically means that using xine here to view DVB-T channels or
vdr-xineliboutput is impossible.
Setting video and audio buffers to insanely high values (like 5000) and
video_num_frames to 200 also doesn't help.
--
Configure bugmail:
http://bugs.xine-project.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
xine-bugs mailing list
xine-bugs@...
https://lists.sourceforge.net/lists/listinfo/xine-bugs
