[Gstreamer-bugs] [Bug 99589] Changed - [PATCH] mpeg created with mplexhi -V exhibit choppy video

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=99589

Changed by rbultje at ronald.bitfreak.net.

--- shadow/99589	Fri Jan  2 19:50:50 2004
+++ shadow/99589.tmp.26333	Fri Jan  9 09:24:25 2004
@@ -1,17 +1,17 @@
 Bug#: 99589
 Product: GStreamer
 Version: HEAD CVS
 OS: other
 OS Details: 
-Status: REOPENED   
+Status: NEW   
 Resolution: 
 Severity: normal
 Priority: High
 Component: gst-plugins
-AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
+AssignedTo: rbultje at ronald.bitfreak.net                            
 ReportedBy: vishnu at pobox.com               
 QAContact: gstreamer-maint at bugzilla.gnome.org
 TargetMilestone: 0.4.0
 URL: 
 Cc: alexander.winston at comcast.net
 Summary: [PATCH] mpeg created with mplexhi -V exhibit choppy video
@@ -99,6 +99,28 @@
 MSMPEG4v3, which is one of the most compact formats too.
 
 
 ------- Additional Comments From alexander.winston at comcast.net  2004-01-02 19:50 -------
 Adding the PATCH keyword and upgrading the priority level to High
 because of the attached fix.
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2004-01-09 09:24 -------
+I'm fetching this one. Let's see, from the patch, I'm guessing that
+the real problem is the fact that the seeking in mpegparse assumes CBR
+(quite obviously, since it uses muxrate for this). I've got several
+VBR movies here, and the SCR (stream) & PTS (packet/content) values
+are identical, which means that they're correct (take that from me).
+Also, if I loop-seek to assure that the *PTS* (rather than the
+adjusted timestamp) is equal to the time that I need, I get the
+correct output. I can actually seek accurate up to a second or closer
+in highly-variable-bitrate videos of 24 hours.
+
+The whole timestamp-adjust-stuff (mpegparse->adjust) is broken, since
+it adapts the PTS to match the muxrate (and thereby moves timestamps
+back to how they would be if the stream was read as CBR) while
+actually, the PTS values (or SCR) should be used for timestamps
+without being adapted (that is correct). Without the adjust
+adaptations, it works fine. Then, however, seeking inside the
+mpegstream elements needs to be adapted to use this, too, else
+discontinuity events will be inprecise. I'm working on a full-blown patch.
+
+Joshua (or Wim), can you confirm all this?