Re: Fixing mplex (was: mpeg2enc)

--Boundary-00=_rPffMYDFejrb8q8
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit

On Wednesday 01 September 2010 01:45:37 Steven Boswell II wrote:
> --- On Tue, 8/31/10, Andrew Stevens <[email protected]> wrote:
[...]
> >>>>[4] The most-recent mplex code seems to have serious trouble with
> >>>>A/V sync.
> >
> >Thats really *weird* .  mplex-internally its hard to see how audio
> >could first drift and then stop drifting.
> 
> I don't know either, but it was really pronounced.  Once you're done with a
> round of bug-fixing, I'll redo that project (which will take a week or
> so...I didn't save the denoised video from that one, sadly) and see if
> it's still off.  If so, I'll have to figure out how to get the ISO to
> you.  I don't know if KTorrent can act as its own tracker, but if so,
> maybe I can make a private torrent for you.  Otherwise, snail-mail!
> 
[...]
> Steven Boswell

Hi Steven,

if you still find A/V sync issues  after applying Andrew's patches, you may 
want to try the attached patch. I issued the patch early in May, but Andrew 
and me dismissed it as  it obviously does not solve any known bug (until you 
popped up).
Basically the patch ensures that Audio packages can be muxed into the stream 
even if a Video GOP is not yet finished.
(if your dvd in question has large GOPs, this might solve your mplex-problem)

Steven, please keep us informed about your findings,

  Roland





--Boundary-00=_rPffMYDFejrb8q8
Content-Type: text/x-patch;
  charset="UTF-8";
  name="multiplexor.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="multiplexor.diff"

--- mplex/multiplexor.cpp	2008-05-10 12:56:04.000000000 +0200
+++ mplex.new/multiplexor.cpp	2010-03-06 07:15:06.000000000 +0100
@@ -1255,8 +1267,19 @@
 		//
 		ElementaryStream *despatch = 0;
 		clockticks earliest = 0;
-		for( str = estreams.begin(); str < estreams.end(); ++str )
+		// hmm... the original code gives video precedence over all other streams
+		// regardless of their DTS timestamp. This forces all non-video streams
+		// to be appended after a GOP ends. That behaviour may cause an underrun
+		// in the decoder's buffer
+		// original code:
+		//
+		// for( str = estreams.begin(); str < estreams.end(); ++str )
+		//
+		// solution: simply go backwards through the stream vector
+		str =estreams.end();
+		do 
 		{
+		 --str;
 #ifdef STREAM_LOGGING
             if( (*str)->MuxCompleted() )
                 mjpeg_debug( "%02x: complete", (*str)->stream_id );
@@ -1271,6 +1294,7 @@
                             
 				    );
 #endif
+			
 			if( (*str)->MuxPossible(current_SCR) && 
 				( !video_first || (*str)->Kind() == ElementaryStream::video )
 				 )
@@ -1281,7 +1305,7 @@
 					earliest = (*str)->RequiredDTS();
 				}
 			}
-		}
+		} while (str != estreams.begin());
 		
 		if( underrun_ignore > 0 )
 			--underrun_ignore;

--Boundary-00=_rPffMYDFejrb8q8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--Boundary-00=_rPffMYDFejrb8q8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Mjpeg-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-developer

--Boundary-00=_rPffMYDFejrb8q8--