From: Michael R. <mr...@us...> - 2004-05-29 15:18:52
Attachments:
ffmpeg-sync.patch.bz2
|
Hi team, I was in contact with the ffmpeg team and managed to get a lot of warning fixes and things that help xine into the official libavcodec. Many thanks to Michael Niedermayer from here. Now, to have some benefit from that, I synced our ffmpeg copy to the ffmpeg CVS from two days ago. It works fine here, but my collection of ffmpeg test streams is rather limited. Therefore, before I commit any of this, I want to ask, if someone with a larger collection of test streams could try the attached patch. Michael -- panic("Lucy in the sky...."); 2.2.16 /usr/src/linux/arch/sparc64/kernel/starfire.c |
From: Daniel M. <xi...@zo...> - 2004-05-29 15:52:19
|
On Sat, May 29, 2004 at 05:18:43PM +0200, Michael Roitzsch wrote: > Now, to have some benefit from that, I synced our ffmpeg copy to the ffmpeg > CVS from two days ago. It works fine here, but my collection of ffmpeg test > streams is rather limited. Therefore, before I commit any of this, I want to > ask, if someone with a larger collection of test streams could try the > attached patch. Applies and builds cleanly here, all streams I tested work fine like before the patch. Unfortunately, this still does not fix the problem I described in my posting yesterday - I had some hope it would ;) If someone else would like to have a look - I put a small snipplet of the stream which causes trouble to http://www.zonque.org/test.ps (~512 kb) It contains about one second of video which is displayed on Linux but not on MacOSX, like I described. Daniel |
From: Daniel M. <xi...@zo...> - 2004-05-29 17:00:26
|
On Sat, May 29, 2004 at 05:51:55PM +0200, Daniel Mack wrote: > If someone else would like to have a look - I put a small snipplet of > the stream which causes trouble to http://www.zonque.org/test.ps (~512 kb) > It contains about one second of video which is displayed on Linux but > not on MacOSX, like I described. It would be especially interesting if this problem also occurs on Linux/PPC or any other big-endian system - just to know which type of bug we're hunting. Daniel |
From: James Courtier-D. <Ja...@su...> - 2004-05-29 17:06:09
|
Daniel Mack wrote: > On Sat, May 29, 2004 at 05:51:55PM +0200, Daniel Mack wrote: > >>If someone else would like to have a look - I put a small snipplet of >>the stream which causes trouble to http://www.zonque.org/test.ps (~512 kb) >>It contains about one second of video which is displayed on Linux but >>not on MacOSX, like I described. > > > It would be especially interesting if this problem also occurs on > Linux/PPC or any other big-endian system - just to know which type > of bug we're hunting. > > Daniel > Would it be possible to post a longer stream? 30 seconds of stream would be ideal. Cheers James |
From: Daniel M. <xi...@zo...> - 2004-05-29 21:49:54
|
On Sat, May 29, 2004 at 06:06:08PM +0100, James Courtier-Dutton wrote: > >It would be especially interesting if this problem also occurs on > >Linux/PPC or any other big-endian system - just to know which type > >of bug we're hunting. > > Would it be possible to post a longer stream? > 30 seconds of stream would be ideal. Of course: http://www.zonque.org/test-long.ps (~34MB) Daniel PS: Don't complain about the content, please - this is what german TV broadcast stations use to tantalise their consumers all day long ;) |
From: Michael R. <mr...@us...> - 2004-05-30 11:39:23
|
Hi Daniel, > > If someone else would like to have a look - I put a small snipplet of > > the stream which causes trouble to http://www.zonque.org/test.ps (~512 > > kb) It contains about one second of video which is displayed on Linux but > > not on MacOSX, like I described. > > It would be especially interesting if this problem also occurs on > Linux/PPC or any other big-endian system - just to know which type > of bug we're hunting. I believe that this does not happen on other PPC systems, because the video decoder is libmpeg2. No PPC user would be able to watch a DVD if that was broken and I guess we would have heard complaints. Michael -- God is real unless declared integer |
From: Daniel M. <xi...@zo...> - 2004-05-31 01:13:37
|
On Sun, May 30, 2004 at 01:39:18PM +0200, Michael Roitzsch wrote: > I believe that this does not happen on other PPC systems, because the video > decoder is libmpeg2. No PPC user would be able to watch a DVD if that was > broken and I guess we would have heard complaints. Hmm, doesn't the message 'ffmpeg_video_dec: increasing buffer ...' tell me that it's ffmpeg decoding the stream? I'm not quite sure how often a muxed transport stream occurs with video data in it which is decoded by ffmpeg. There is definitely some different behaviour on Linux/x86 and Darwin, that's what I know - since it's obviously not an endian problem, I wonder what else could cause the trouble. Daniel |
From: Mike M. <mel...@pc...> - 2004-05-31 01:58:23
|
On Mon, 31 May 2004, Daniel Mack wrote: > Hmm, doesn't the message 'ffmpeg_video_dec: increasing buffer ...' tell > me that it's ffmpeg decoding the stream? I'm not quite sure how often > a muxed transport stream occurs with video data in it which is decoded > by ffmpeg. > There is definitely some different behaviour on Linux/x86 and Darwin, > that's what I know - since it's obviously not an endian problem, I > wonder what else could cause the trouble. Indeed, I was wondering why ffmpeg was taking over in your case. libmpeg2 is supposed to handle MPEG-1/2 duty by default. Team, try this experiment: Go into the xine engine configuration and bump ffmpeg's video decoder priority up above libmpeg2's priority. Play Daniel's sample file. You will see something like... ffmpeg_video_dec: increasing buffer to 142369 to avoid overflow. ffmpeg_video_dec: increasing buffer to 216363 to avoid overflow. ffmpeg_video_dec: increasing buffer to 327403 to avoid overflow. [...] And this is on x86. So the glue code between xine and ffmpeg's MPEG-1/2 decoder must not be perfect...actually, I just tried the latest ffmpeg snapshot and it can't open the file at all. I don't know if that's a demuxer or decoder issue. Daniel M.: Next task is to figure out why ffmpeg is taking default precedence over libmpeg2 for MPEG-1/2 data. Check if xineplug_decode_mpeg2.so is being compiled and installed (from the src/libmpeg2 directory). Then, make sure it has a higher priority than ffmpeg (they should all be 0 by default which will somehow make libmpeg2 take priority over ffmpeg per the default installation). Hope this helps... -- -Mike Melanson |
From: Daniel M. <xi...@zo...> - 2004-05-31 02:38:05
|
Hi Mike, On Sun, May 30, 2004 at 08:06:44PM -0600, Mike Melanson wrote: > And this is on x86. So the glue code between xine and ffmpeg's MPEG-1/2 > decoder must not be perfect...actually, I just tried the latest ffmpeg > snapshot and it can't open the file at all. I don't know if that's a > demuxer or decoder issue. From other tests I know that ffmpeg is able to decode the video part of the stream in question if it is extracted by a demuxer. > Daniel M.: Next task is to figure out why ffmpeg is taking > default precedence over libmpeg2 for MPEG-1/2 data. Check if > xineplug_decode_mpeg2.so is being compiled and installed (from the > src/libmpeg2 directory). Then, make sure it has a higher priority than > ffmpeg (they should all be 0 by default which will somehow make libmpeg2 > take priority over ffmpeg per the default installation). Ok, xineplug_decode_mpeg2.so is build and installed just fine. The easiest way was to delete xineplug_decode_ff.so so it can't jump in at all. xine then tells me the stream has an unsupported codec; so we are faced with two different problems: a) ffmpeg MPEG 1/2 is broken and b) libmpeg2 does not like to take the stream on MacOSX, for whatever reason. Which decoder was used when testing the stream on Linux/PPC, btw? Daniel |
From: Daniel M. <xi...@zo...> - 2004-05-31 02:54:46
|
On Mon, May 31, 2004 at 04:37:59AM +0200, Daniel Mack wrote: > > And this is on x86. So the glue code between xine and ffmpeg's MPEG-1/2 > > decoder must not be perfect...actually, I just tried the latest ffmpeg > > snapshot and it can't open the file at all. I don't know if that's a > > demuxer or decoder issue. > > From other tests I know that ffmpeg is able to decode the video part of > the stream in question if it is extracted by a demuxer. To make this clearer: That works on MacOSX with ffmpeg used natively, not with xine - so it must be the glue code, not libavcodec/ffmpeg itself. Daniel |
From: Mike M. <mel...@pc...> - 2004-05-31 03:40:43
|
On Mon, 31 May 2004, Daniel Mack wrote: > Ok, xineplug_decode_mpeg2.so is build and installed just fine. > The easiest way was to delete xineplug_decode_ff.so so it can't jump > in at all. xine then tells me the stream has an unsupported codec; so > we are faced with two different problems: a) ffmpeg MPEG 1/2 is broken > and b) libmpeg2 does not like to take the stream on MacOSX, for whatever > reason. > Which decoder was used when testing the stream on Linux/PPC, btw? My wager is the libmpeg2 decoder was used on the Linux/PPC testing. Right about now, I'm guessing that libmpeg2 is not being loaded on your system because there are some unresolved symbols. Next experiment: Run 'ld' on the shared object: ld /path/to/xineplug_decode_mpeg2.so It should only complain about not finding the _start symbol; that's normal. If anything else is missing, we need to figure out why. -- -Mike Melanson |
From: Daniel M. <xi...@zo...> - 2004-05-31 23:08:18
|
On Sun, May 30, 2004 at 09:49:09PM -0600, Mike Melanson wrote: > My wager is the libmpeg2 decoder was used on the Linux/PPC > testing. Right about now, I'm guessing that libmpeg2 is not being loaded > on your system because there are some unresolved symbols. Next experiment: > Run 'ld' on the shared object: Aargh, that was it, yes. Sorry - I forgot to also if-def the referencences to the altivec code I disabled on my platform which of course lead to unresolved symbols. My stupidness - I indeed could have checked this before bordering you guys! But anyway, since libavcodec is told to be even faster on decoding MPEG 1/2 I took it for given that it's ffmpeg which us used all the time... Daniel PS: So forget the altivec-disabler-patches I posted - I will come up with a larger patch fixing some more MacOSX related issues in the next days. |
From: Bill F. <bil...@mi...> - 2004-05-31 03:47:48
|
On Mon, 31 May 2004, Daniel Mack wrote: > On Sun, May 30, 2004 at 08:06:44PM -0600, Mike Melanson wrote: > > And this is on x86. So the glue code between xine and ffmpeg's MPEG-1/2 > > decoder must not be perfect...actually, I just tried the latest ffmpeg > > snapshot and it can't open the file at all. I don't know if that's a > > demuxer or decoder issue. > > From other tests I know that ffmpeg is able to decode the video part of > the stream in question if it is extracted by a demuxer. > > > Daniel M.: Next task is to figure out why ffmpeg is taking > > default precedence over libmpeg2 for MPEG-1/2 data. Check if > > xineplug_decode_mpeg2.so is being compiled and installed (from the > > src/libmpeg2 directory). Then, make sure it has a higher priority than > > ffmpeg (they should all be 0 by default which will somehow make libmpeg2 > > take priority over ffmpeg per the default installation). > > Ok, xineplug_decode_mpeg2.so is build and installed just fine. > The easiest way was to delete xineplug_decode_ff.so so it can't jump > in at all. xine then tells me the stream has an unsupported codec; so > we are faced with two different problems: a) ffmpeg MPEG 1/2 is broken > and b) libmpeg2 does not like to take the stream on MacOSX, for whatever > reason. > Which decoder was used when testing the stream on Linux/PPC, btw? libmpeg2. There might possibly be alignment issues. The compilers for Linux/PPC and MacOS X may handle alignment of shorts, ints, longs, etc in structs differently. And #ifdefs in the source code could also conceivably have an effect. -Bill -Bill |
From: Daniel M. <xi...@zo...> - 2004-07-01 11:53:49
|
On Sun, May 30, 2004 at 08:06:44PM -0600, Mike Melanson wrote: > Team, try this experiment: Go into the xine engine configuration > and bump ffmpeg's video decoder priority up above libmpeg2's priority. > Play Daniel's sample file. You will see something like... > > ffmpeg_video_dec: increasing buffer to 142369 to avoid overflow. > ffmpeg_video_dec: increasing buffer to 216363 to avoid overflow. > ffmpeg_video_dec: increasing buffer to 327403 to avoid overflow. > [...] > > And this is on x86. So the glue code between xine and ffmpeg's MPEG-1/2 > decoder must not be perfect...actually, I just tried the latest ffmpeg > snapshot and it can't open the file at all. I don't know if that's a > demuxer or decoder issue. Did anybody have a look at this issue again? Daniel |
From: Mike M. <mel...@pc...> - 2004-05-29 19:27:26
|
On Sat, 29 May 2004, Michael Roitzsch wrote: > Now, to have some benefit from that, I synced our ffmpeg copy to the ffmpeg > CVS from two days ago. It works fine here, but my collection of ffmpeg test > streams is rather limited. Therefore, before I commit any of this, I want to > ask, if someone with a larger collection of test streams could try the > attached patch. I applied the patch and ran a bunch of my fringe media through. Everything seems to check out all right. Have you tried any VP3 media? I'm having some trouble there. But I don't know if it's a problem with the VP3 decoder or somewhere else in xine. Thanks... -- -Mike Melanson |
From: Michael R. <mr...@us...> - 2004-05-30 19:21:32
|
Hi Mike, > > Now, to have some benefit from that, I synced our ffmpeg copy to the > > ffmpeg CVS from two days ago. It works fine here, but my collection of > > ffmpeg test streams is rather limited. Therefore, before I commit any of > > this, I want to ask, if someone with a larger collection of test streams > > could try the attached patch. > > I applied the patch and ran a bunch of my fringe media through. > Everything seems to check out all right. Thanks for testing. The new ffmpeg is now in CVS. > Have you tried any VP3 media? I'm having some trouble there. But I > don't know if it's a problem with the VP3 decoder or somewhere else in > xine. I just tested a VP3 file here. It works with the win32 decoder, but with ffmpeg it displays only garbage. This is, however, the same with the old ffmpeg, so it is not a result of my sync. Michael -- "The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense." -E.W. Dijkstra |
From: Siggi L. <si...@us...> - 2004-05-30 12:04:26
|
On Sun, 30 May 2004, Michael Roitzsch wrote: > > > If someone else would like to have a look - I put a small snipplet of > > > the stream which causes trouble to http://www.zonque.org/test.ps (~512 > > > kb) It contains about one second of video which is displayed on Linux but > > > not on MacOSX, like I described. > > > > It would be especially interesting if this problem also occurs on > > Linux/PPC or any other big-endian system - just to know which type > > of bug we're hunting. > > I believe that this does not happen on other PPC systems, because the video > decoder is libmpeg2. No PPC user would be able to watch a DVD if that was > broken and I guess we would have heard complaints. Additionally, I can confirm that your test.ps plays fine on Linux/ppc (Apple iBook G3/600, Kernel 2.4.20-ben10) So it's definitely neither an Endianness issue nor anything else that's specific to the processor architecture. It could still be something like the OS not handling AltiVec extensions properly, though. (Sorry, don't have a G4 with linux...) Cheers, Siggi |
From: Bill F. <bil...@mi...> - 2004-05-30 16:50:50
|
On Sun, 30 May 2004, Siggi Langauf wrote: > On Sun, 30 May 2004, Michael Roitzsch wrote: > > > > > If someone else would like to have a look - I put a small snipplet of > > > > the stream which causes trouble to http://www.zonque.org/test.ps (~512 > > > > kb) It contains about one second of video which is displayed on Linux but > > > > not on MacOSX, like I described. > > > > > > It would be especially interesting if this problem also occurs on > > > Linux/PPC or any other big-endian system - just to know which type > > > of bug we're hunting. > > > > I believe that this does not happen on other PPC systems, because the video > > decoder is libmpeg2. No PPC user would be able to watch a DVD if that was > > broken and I guess we would have heard complaints. > > Additionally, I can confirm that your test.ps plays fine on Linux/ppc > (Apple iBook G3/600, Kernel 2.4.20-ben10) > > So it's definitely neither an Endianness issue nor anything else that's > specific to the processor architecture. > It could still be something like the OS not handling AltiVec extensions > properly, though. (Sorry, don't have a G4 with linux...) It plays fine on a dual 500 MHz G4 running YellowDog Linux with a 2.4.20-ben10 SMP kernel. -Bill |