Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On 4 Jan 2004, Florin Andrei wrote: MPEG2 without B frames makes some DVD players choke. The default What player is so braindamaged and standards non-compliant as to choke on an *optional* part of the MPEG-2 specs? (B frames are optional). Are you sure that was the cause or was it pusing the bitrate too high and generating streams out of spec on the peaks? As I recall the stuttering was caused by -b 9000. That can work with commercial pressed DVDs but some players have problems with RECORDABLE media at high bitrates due to the lesser reflectivity of the media. What would be the new -R setting to imitate the old behaviour? Would it be -R 2? Yep, that's the old behaviour. I have a hunch that any problems with -R 0 are due to other factors and not the lack of B frames. Hmmm - having said all that it might be that DPME (Dual Prime Motion Estimation) might be a possible problem area - can't recall if that was required or not. It is possible to have no B frames and not use DPME (but no B frames are a requirement to use DPME - at least at [EMAIL PROTECTED]). If anything I'd have expected an old portable (Audiovox) to have a problem with no B frame based SVCD and it sailed right thru. Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sun, 2004-01-04 at 17:23, Steven M. Schultz wrote: On 4 Jan 2004, Florin Andrei wrote: MPEG2 without B frames makes some DVD players choke. The default What player is so braindamaged and standards non-compliant as to choke on an *optional* part of the MPEG-2 specs? (B frames are optional). Are you sure that was the cause or was it pusing the bitrate too high and generating streams out of spec on the peaks? As I recall the stuttering was caused by -b 9000. Ok, i can't reproduce the problem now, and i'm using 8500 kbps, so perhaps you're right. -- Florin Andrei http://florin.myip.org/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On 4 Jan 2004, Florin Andrei wrote: Are you sure that was the cause or was it pusing the bitrate too high and generating streams out of spec on the peaks? As I recall the stuttering was caused by -b 9000. Ok, i can't reproduce the problem now, and i'm using 8500 kbps, so perhaps you're right. AH, ok - I was hoping my memory hadn't developed a parity error ;) But, you also may be right... Believe it or not I've created a DVD that hardware/standalone players have absolutely no trouble with but software players (such as Ogle and Apple's DVD Player) either spew errors about or artifact badly. I think Xine will do ok since it uses libmpeg2 for the decoding. A query has been sent asking if an option can be added to disable DPME upon request. It is not required to implement DPME in the no B frame case and it seems that some _software_ players do not implment DP. Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
Hi Steven, On Sat, 2004-01-03 at 01:49, Steven M. Schultz wrote: No, there was a bug in configure.in that caused autoheader to never be run. That was not a bug. ;). It was added by Bernhard some time ago. I forgot why. Ronald -- Ronald Bultje [EMAIL PROTECTED] Linux Video/Multimedia developer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, Jan 02, 2004 at 05:19:41PM -0800, Steven M. Schultz wrote: On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote: [...] Now make fails: With a libtool related error. /bin/sh ../../libtool --mode=compile --tag=CC /bin/sh ../../strip_fPIC.sh /usr/bin/nasm -f elf -o mblock_bsad_mmx.lo mblock_bsad_mmx.s libtool: unrecognized option `--tag=CC' [...] Any clues? Of course ;) libtool-1.5 is, apparently, now a requirement. The --tag capability is from libtool 1.5 and was needed for building the shared libraries (the core of the encoder is now a shared lib that can be used by other programs). I have just ommitted the --tag=CC option from the call to libtool in the files utils/mmxsse/Makefile and mpeg2enc/Makefile and then compilation went ok. Should I expect any problem with the software as a consequence of that? mpeg2enc and mplex seems to be working right. I quick run show that they are working. I think that the shared libraries has been built successfully: # ls -Gg /opt/mjpegtools.cvs/lib/ total 5756 lrwxrwxrwx1 23 Jan 3 06:45 liblavfile-1.6.so.0 - liblavfile-1.6.so.0.1.1 -rwxr-xr-x156116 Jan 3 06:45 liblavfile-1.6.so.0.1.1 -rw-r--r--154316 Jan 3 06:45 liblavfile.a -rwxr-xr-x1 908 Jan 3 06:45 liblavfile.la lrwxrwxrwx1 23 Jan 3 06:45 liblavfile.so - liblavfile-1.6.so.0.1.1 lrwxrwxrwx1 23 Jan 3 06:45 liblavjpeg-1.6.so.0 - liblavjpeg-1.6.so.0.1.1 -rwxr-xr-x128723 Jan 3 06:45 liblavjpeg-1.6.so.0.1.1 -rw-r--r--124382 Jan 3 06:45 liblavjpeg.a -rwxr-xr-x1 798 Jan 3 06:45 liblavjpeg.la lrwxrwxrwx1 23 Jan 3 06:45 liblavjpeg.so - liblavjpeg-1.6.so.0.1.1 lrwxrwxrwx1 23 Jan 3 06:45 liblavplay-1.6.so.0 - liblavplay-1.6.so.0.1.1 -rwxr-xr-x151253 Jan 3 06:45 liblavplay-1.6.so.0.1.1 -rw-r--r--145732 Jan 3 06:45 liblavplay.a -rwxr-xr-x1 748 Jan 3 06:45 liblavplay.la lrwxrwxrwx1 23 Jan 3 06:45 liblavplay.so - liblavplay-1.6.so.0.1.1 lrwxrwxrwx1 22 Jan 3 06:45 liblavrec-1.6.so.0 - liblavrec-1.6.so.0.1.1 -rwxr-xr-x1 106848 Jan 3 06:45 liblavrec-1.6.so.0.1.1 -rw-r--r--170238 Jan 3 06:45 liblavrec.a -rwxr-xr-x1 741 Jan 3 06:45 liblavrec.la lrwxrwxrwx1 22 Jan 3 06:45 liblavrec.so - liblavrec-1.6.so.0.1.1 -rw-r--r--132128 Jan 3 06:45 libmjpegutils.a lrwxrwxrwx1 26 Jan 3 06:45 libmpeg2encpp-1.6.so.0 - libmpeg2encpp-1.6.so.0.1.1 -rwxr-xr-x1 875687 Jan 3 06:45 libmpeg2encpp-1.6.so.0.1.1 -rw-r--r--1 1601946 Jan 3 06:46 libmpeg2encpp.a -rwxr-xr-x1 769 Jan 3 06:45 libmpeg2encpp.la lrwxrwxrwx1 26 Jan 3 06:45 libmpeg2encpp.so - libmpeg2encpp-1.6.so.0.1.1 lrwxrwxrwx1 22 Jan 3 06:45 libmplex2-1.6.so.0 - libmplex2-1.6.so.0.1.1 -rwxr-xr-x1 985878 Jan 3 06:45 libmplex2-1.6.so.0.1.1 -rw-r--r--1 1864540 Jan 3 06:45 libmplex2.a -rwxr-xr-x1 741 Jan 3 06:45 libmplex2.la lrwxrwxrwx1 22 Jan 3 06:45 libmplex2.so - libmplex2-1.6.so.0.1.1 drwxr-xr-x2 4096 Jan 3 06:46 pkgconfig libtool-1.5 is much better than 1.4.x (especially when C++ shared lib building is involved - and on OS/X 10.3 libtool-1.5 comes pre-isntalled and integrated which helped me a lot on that system). The newer version of libtool has not introduced any compatibility problems at all for me (on any of 3 or 4 different operating systems) so my suggestion would be to install libtool-1.5 I would not like to replace a basic system tool myself, without support from the OS community. Gentoo Linux does not have an ebuild for libtool 1.5 in portage yet. Unless the replacement is really necessary. Thanks. Romildo --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 3 Jan 2004 [EMAIL PROTECTED] wrote: I do not think 1.6.1.92 is that old. If I am not wronk, it has been released by the end of November. Maybe it just _feels_ old ;) Seems that the next release candidate has been real soon now for a long time. spead things up. I have been using them. I have also been using the -E n with n being a value between -15 and -4, in order to get smaller files. Do you think this is a good idea? Definitely a good idea.Values in the -10 range are quite conservative (I tend to use either -8 or -10). It seems that the small (in absolute value) values for n dos not affect the quality that much. Very true - the visual quality is not reduced but the size of the file is smaller (sometimes considerably smaller). What does change in CVD compared to SVCD encoding? Only the frame size? The only thing that changes is the encoded frame size. SVCDs use a coded frame size of 480x480 which is expanded on playback to 640x480 (4/3) or 854x480 (16/9) (and yes, 16/9 is valid for SVCDs but the hardware players I've tried do not know about it). CVDs are encoded at 352x480 (which is also a valid DVD size) and get expanded to 640x480 or 854x480 on playback. a frame size of 672x504. Then I resize it to 480x480 and set the aspect ratio to 4:3. What would be the procedure for a CVD target in this example? If you're using 'y4mscaler' to do the scaling then all you need to do is change the -O preset=SVCD to -O preset=CVD and it will perform the necessary magic for you. Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 3 Jan 2004 [EMAIL PROTECTED] wrote: I have just ommitted the --tag=CC option from the call to libtool in the files utils/mmxsse/Makefile and mpeg2enc/Makefile and then compilation went ok. Should I expect any problem with the software as a consequence of that? mpeg2enc and mplex seems to be working If the compilation and linking went ok then I would not expect an (bad) consequences. On some systems (OS/X) libtool-1.5 was required to get the C++ based shared libraries to build. I would not like to replace a basic system tool myself, without support from the OS community. Gentoo Linux does not have an ebuild for libtool 1.5 in portage yet. Unless the replacement is I wonder what is taking so long. libtool-1.5 has been available for almost a year now. On the other hand it is not necessary to replace parts of the system (although I do it constantly). Install the new version in a different directory and then put that directory first in $PATH when you want to use the new version. If the system's libtool is in /usr/bin then installing the new version into /usr/local/bin is safe and won't affect/overwrite the system version. The replacement's only necessary, in this case, if you want to avoid editing the generated Makefiles each time you run ./configure or ./autogen.sh Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 2004-01-03 at 00:58, Steven M. Schultz wrote: As the toolbox is becomes more complete the management gets simpler. Assuming the tools are all interchangeable. It's when you have some software that wants automake 1.4 and others than want 1.6/7 and some software wants one version of a lib and some software wants another version, and so on and so forth. I'd just as soon let the distro vendor handle all the crap and work on more fun stuff myself. If I felt I did not have list of stuff that I want to do a mile long, I might me more inclined to manage software, but life is just too short. strange - given recent vintage automake/autoconf/libtool tools it should have been a simple matter of ./cvs_bootstrap and make. Except that for some reason any version of automake that I have here barfs on the indentation of variable assignments in some of mpeg4ip's Makefile.am files. I just don't care to know enough about autoconf/automake to know why this is a problem and fix the tool. As it was, I took a stab and removing the indent and things moved along. Unfortunately, mp4creator did not like trying to add an mencoder produced divx/avi file to an mp4: $ /usr/src/mpeg4ip/server/mp4creator/mp4creator -create=test.divx -rate=29.97 test.mp4 MP4ERROR: MP4WriteCountedString: Length is 2852: Numerical result out of range And yields a file with the digital equivalent of white noise. Maybe it's the issue of streams in containers vs raw streams again. I dunno. Down that path lies a bit more madness than you've already encountered. Actually, once I got the bootstrap_cvs madness sorted out, building mp4creator (and it's 3 or 4 prerequisite mpeg4ip supplied libraries) built was relatively straightforward. As I recall from talking to the creators of the project you'll need a couple of the shared libs such as libmp4v2 and libmp4av at least Yeah, there was an avi lib as well as another one or two. Like I said that part was a cakewalk compared to sorting out the autoconf/automake/aclocal and assorted mess. Once the ./configure problem(s) are taken care of it's as easy to build the whole thing with 'make' than it is to pickchoose. Could be. I was looking for the path of least resistance (time included in resistance) to see if mp4creator was even the tool I needed/wanted before I invested time in building the whole project. Not at all. At the moment MPEG-2 is most useful on standalone hardware players simply because there are no units (not quite true - I think there are 2) that handle anything else. You can't put MPEG-4 onto a DVD, take the disc and go into Circuit City (or wherever) and expect it to play on anything except a computer. OK then. Just as I suspected. You are merely saying that MPEG4 simply does not exist in hardware (STB) devices (yet). Is there even a standard (i.e. comparible to the DVD standard) on how to put MPEG4 on a disc for STB manufacturers to even build against? I always had the impression that MPEG4 was designed for bitrate constrained applications (like network streaming for example) and sacrificed some picture quality to achieve that. So much so that even using typical MPEG2 bitrates still did not achieve the picture quality of mpeg2. Maybe that is all folklore. No. Feel free to use whatever suits your fancy on your computer. For DVD sized data I use MPEG-2, for the smaller resolutions I might use MPEG-4. Why use resolution as your decision point? My main preference for MPEG2 is that I was under the impression that MPEG4 could not do field based encoding as well as MPEG2, which for progressive (i.e. film based) sources, who cares, but for video tape based sources, is more important. MPEG-4 does better at the lower bitrates (smaller files) than MPEG-2 though so if smaller files (to get under the 2GB limit) is the goal then MPEG-4 is a better choice. Once you get up around 4Mb/s there's nothing really to be gained with MPEG-4 - the files are just as big their MPEG-2 counterparts. Interesting point to note. Size is always of importance, especially when it's material that I am only going to view once. One drawback of MPEG-4 at the present time is that at the higher resolutions Resolutions? Or bitrates? If the former then I think you have just answered my question above. :-) the current software decoders begin using a lot of cpu. At what resolution do you feel the breaking point is in CPU consumption? MPEG-2 decoders are more mature and there are hardware assists - some video cards have MPEG-2 decoders built in and the nVidia one I'm using comes with libraries that ffmpeg/mplayer use to talk to the hardware decoder (only works for MPEG-2 though). Those damn nVidia guys :-) As much as I try to avoid using them due to the whole closed source video drivers thing,
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 3 Jan 2004, Brian J. Murrell wrote: Except that for some reason any version of automake that I have here barfs on the indentation of variable assignments in some of mpeg4ip's Hmmm, which automake do you have? I'd been using 1.7.3 for a long time with good results. A couple weeks ago decided to install 1.7.9 and didn't have any problems. Unfortunately, mp4creator did not like trying to add an mencoder produced divx/avi file to an mp4: $ /usr/src/mpeg4ip/server/mp4creator/mp4creator -create=test.divx -rate=29.97 test.mp4 MP4ERROR: MP4WriteCountedString: Length is 2852: Numerical result out of range Maybe it's the issue of streams in containers vs raw streams again. I dunno. Yes, that's what it is. mencoder adamantly insists on putting things into a container - sigh. I think it's possible to use ffmpeg to create a 'raw' m4v file - haven't tried it. What I do with the output of mencoder is use another utility from the mpeg4ip project: avi2raw mencoder ... -o foo.avi avi2raw --video foo.avi foo.m4v mp4creator -c foo.m4v -rate=XX.YY foo.mp4 mp4creator -c foo.aac foo.mp4 where XX.YY is usually 29.97 but may need to be 23.976 if you've done a 3:2 pulldown from telecined source. Adding the audio track is the second mp4creator command, in the example it was AAC audio, but .mp3 is also valid. mp4creator also has the --use64bits option but the usage summary suggests it's not QuickTime player compatible - i.e. won't play on an Apple). OK then. Just as I suspected. You are merely saying that MPEG4 simply does not exist in hardware (STB) devices (yet). Is there even a Yep - that about sums it up. Which effectively means that MPEG4 is only interchangeable (i.e. I could create a video and send it to someone) between computers (not send 'em a DVD). standard (i.e. comparible to the DVD standard) on how to put MPEG4 on a disc for STB manufacturers to even build against? Sort of.The MP4 container format was one idea that was brought up for the next generation DVD format The AVI container is used by the one portable player I saw (but who wants to watch a movie on a 1.5 LCD? ;)). I always had the impression that MPEG4 was designed for bitrate constrained applications (like network streaming for example) and sacrificed some picture quality to achieve that. So much so that even True - that is one of the intended applications. The low picture quality isn't MPEG-4's fault of course but of the low rates. Most of MPEG-4 isn't used/realized yet - the concepts of multiple layers and objects for example. For something like a football game the static background would be one object and compressed, the players and the 'ball' would be separate objects and compressed handled separately, etc. At the moment the MPEG-4 encoders are very simple (the lower profiles/capabilities) For DVD sized data I use MPEG-2, for the smaller resolutions I might use MPEG-4. Why use resolution as your decision point? Because software playback of DVD sized MPEG-4 files is marginal on all but the fastest computers at the moment. That's one reason. The other is that once at the DVD size I'll put it on a DVD+R disc and play it on my portable DVD player, or the one hooked up to the TV ;) Then too at smaller sizes and lower bitrates MPEG4 is great for encoding up a cartoon and making it availble for FTP (email's not practical since a lot folks have quotas or similar on mail). One drawback of MPEG-4 at the present time is that at the higher resolutions Resolutions? Or bitrates? If the former then I think you have just answered my question above. :-) Same thing, or rather related. With similar quality a larger resolution will require a higher bitrate.Yes, you could create a 1Mb/s DVD sized movie but I don't think you'd want to watch it ;) At what resolution do you feel the breaking point is in CPU consumption? 1280x768p was the point at which the systems/players didn't have trouble. As far as I know, in Southern California, only 1 TV station is broadcasting in the 1280 HDTV format - the others are using the 1920x1080i http://www.pchdtv.com I'm going to order one up before the new FCC regulation about the 'broadcast copy' flag goes into effect - gs. Those damn nVidia guys :-) As much as I try to avoid using them due to the whole closed source video drivers thing, there is always a reason to look at them again. They may be closed source but they're extremely responsive and supportive.You can get *any* of their
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 2004-01-03 at 18:47, Steven M. Schultz wrote: Hmmm, which automake do you have? Both 1.4 and 1.7. Due to the mixture of requirements out there, Mandrake includes both. I am not sure if their automake is s'posed to work the same way, but their autoconf is actually only a wrapper to try to decide to use autoconf 1.4 or 1.7 heuristically. Here is the comment from the top of it: # Executes the correct autoconf version. # # - defaults to autoconf-2.13 # - runs autoconf-2.5x if it exists and... # - envvar WANT_AUTOCONF_2_5 is set to `1' # -or- # - configure.ac is present # -or- # - `configure.in' contains AC_PREREQ and the value's 3 first letters # are stringwise greater than '2.1' # -or- # - `configure' is already present and was generated by autoconf greater than '2.1' # -or- # - `Makefile.in' was generated by automake-1.6 or superior, which specifically needs autoconf-2.5x # -or- # - `aclocal.m4' contains AC_PREREQ and it says we require a more recent than 2.1 version # Fiddling with their switches and forcing the use of autoconf-1.7 and automake-1.7 is what was finally successful in making the portions of mpeg4ip that I tried to build. Yes, that's what it is. mencoder adamantly insists on putting things into a container - sigh. Indeed. I think it's possible to use ffmpeg to create a 'raw' m4v file - haven't tried it. Right. But remember, I want some of the mencoder filters. Particularly the detc filter. I have not seen an other inverse-telecine filter do as well as it does with noisy analog cable captures. What I do with the output of mencoder is use another utility from the mpeg4ip project: avi2raw mencoder ... -o foo.avi avi2raw --video foo.avi foo.m4v mp4creator -c foo.m4v -rate=XX.YY foo.mp4 mp4creator -c foo.aac foo.mp4 where XX.YY is usually 29.97 but may need to be 23.976 if you've done a 3:2 pulldown from telecined source. Adding the audio track is the second mp4creator command, in the example it was AAC audio, but .mp3 is also valid. Excellent! I will give that a try too. mp4creator also has the --use64bits option but the usage summary suggests it's not QuickTime player compatible - i.e. won't play on an Apple). No tears here over that. :-) No offense intended. An Apple is just within the realm of my concern. Yep - that about sums it up. Which effectively means that MPEG4 is only interchangeable (i.e. I could create a video and send it to someone) between computers (not send 'em a DVD). Right. Most of MPEG-4 isn't used/realized yet - the concepts of multiple layers and objects for example. For something like a football game the static background would be one object and compressed, the players and the 'ball' would be separate objects and compressed handled separately, etc. Cool! At the moment the MPEG-4 encoders are very simple (the lower profiles/capabilities) Indeed. 1280x768p was the point at which the systems/players didn't have trouble. OK. Well below what I am doing here, so I might just continue to use mpeg4, certainly for the 2hrs content. I'm going to order one up before the new FCC regulation about the 'broadcast copy' flag goes into effect - gs. Yeah. What he said: gs. They may be closed source but they're extremely responsive and supportive. So I keep hearing. I've never configured TVout but yes, it will their cards will do it (the FX5200 I bought came with an S-Video output as well as a DVI and analog VGA connectors - and 128MB of memory, all for $80 or so). Nice price for the the hardware, but presence of an S-Video output doesn't mean the (Linux) driver will fully support it. They may be feeling the same pressure all the other card vendors are feeling from the copyright consortium to not make TV-Out terribly easy on an Open Source platform. Do they do anything other than X drivers? The sad fact as far as I understand it is that clean TV-Out is just not possible in X due to the player (i.e. mplayer, xine, whatever) not knowing when to flip pages because software cannot get notification of the vsync pulse from X. Ideally, nVidia need to produce a framebuffer (preferably with DirectFB support) driver. Who want to use X in an STB? It's also the reason I got the nVidia card - I have a ~15-20 clip (the transport stream example from www.pchdtv.com's download area) that the matrox card choked on. I'm a long time fan of the Matrox products but everything up thru the G550 has a dinky Xv X11? I don't use my G400 with X. Is the dinky Xv (overlay) still relevant in that situation? 720x480? I don't know of any 720x640 formats. Oops. :-) Yes, 720x480. I get my HDTV off the air I
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Thu, 1 Jan 2004, Brian J. Murrell wrote: I am using mencoder (libavcodec in reality I guess) to create an mpeg1 Hmmm, I knew ffmpeg had mpeg1 encoding capability (from libavcodec) and it can, if you say the right magic words, produce MPEG1 ES (Elemental Stream) files. I am fairly sure that the problem is that mencoder produces AVI files - they're already muxed and definitely not MPEG1 ES files and that is why mplex can't recognize them. INFO: [mplex] mplex version 2.2.2 ($Date: 2003/05/13 20:27:15 $) **ERROR: [mplex] File test.mpeg1 unrecogniseable! INFO: [mplex] File test.mp3 looks like an MPEG Audio stream. **ERROR: [mplex] Unrecogniseable file(s)... exiting. Right - the file's already multiplexed, into an avi stream. The video portion is MPEG1 but it's inside a container format and mplex doesn't mplex avi files. Is there anything I can do to discover more about what mplex does not like about this mpeg1 file? If you're determined to avoid mpeg2enc then you might use 'ffmpeg' to do the encoding - it can produce ES files rather than AVI files. Something like this (suitably modified for your situation of course) might work better. I was testing the mpeg2 encoding capability so for mpeg1 you'd change the 'mpeg2video' to be 'mpeg1video' and of course set the bitrate and bufsize down to reasonable values: ffmpeg -f yuv4mpegpipe -i susi_120.y4m -b 7000 -ilme -ildct \ -aspect 4/3 \ -top 1 -g 15 -maxrate 7500 -f mpeg1video -vcodec mpeg2video \ -bufsize 1840 -y xxx MPEG1's most commonly used for VCD (352x240) - is that what you're doing? Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2004-01-02 at 02:01, Steven M. Schultz wrote: Hmmm, I knew ffmpeg Indeed. I have seen some of your traffic on the ffmpeg-devel list. had mpeg1 encoding capability (from libavcodec) and it can, if you say the right magic words, produce MPEG1 ES (Elemental Stream) files. Right. I think mencoder can leverage on that too. I am fairly sure that the problem is that mencoder produces AVI files Steven! I had hoped you'd have given me more credit than that. :-) I know that by default mencoder does produce avi contained files (which I am trying with great effort to get the hell away from. However, it has a switch -of which you can set to mpeg, to get an mpeg container. - they're already muxed and definitely not MPEG1 ES files and that is why mplex can't recognize them. I don't think so. Mplayer tells me this about the file (if there is a better utility to determine the parameters of an MPEG file, I would be more than glad to use it rather than mplayer): Playing test.mpeg1. [file] File size is 19034112 bytes STREAM: [file] test.mpeg1 STREAM: Description: File STREAM: Author: Albeu STREAM: Comment: based on the code from ??? (probably Arpi) Checking for YUV4MPEG2 DEMUXER: freeing demuxer at 0x84ab820 ASF_check: not ASF guid! DEMUXER: freeing demuxer at 0x84ab820 Checking for NuppelVideo DEMUXER: freeing demuxer at 0x84ab820 Checking for REAL DEMUXER: freeing demuxer at 0x84ab820 Checking for SMJPEG DEMUXER: freeing demuxer at 0x84ab820 DEMUXER: freeing demuxer at 0x84ac088 Searching demuxer type for filename test.mpeg1 ext: .mpeg1 Checking for MOV DEMUXER: freeing demuxer at 0x84ac088 Checking for VIVO header block 1 size: 0 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 DEMUXER: freeing demuxer at 0x84ac088 Checking for PVA DEMUXER: freeing demuxer at 0x84ac088 Checking for MPEG-TS... TRIED UP TO POSITION 70963, FOUND 47, packet_size= 0, SEEMS A TS? 0 DEMUXER: freeing demuxer at 0x84ac088 Checking for LMLM4 Stream Format Invalid packet in LMLM4 stream: ch=0 size=553648376 LMLM4 Stream Format not found DEMUXER: freeing demuxer at 0x84ac088 system stream synced at 0xB (0)! == Found video stream: 0 MPEG-PS file format detected. Too many video packets in the buffer: (4096 in 8302122 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. ds_fill_buffer: EOF reached (stream: audio) MPEG: No audio stream found - no sound. Searching for sequence header... OK! VIDEO: MPEG1 352x480 (aspect 2) 29.970 fps0.0 kbps ( 0.0 kbyte/s) [V] filefmt:2 fourcc:0x1001 size:352x480 fps:29.97 ftime:=0.0334 Mplayer seems to think it's an MPEG-PS stream, without audio even. I also tried mencoder with -nosound to ensure there was no audio stream. INFO: [mplex] mplex version 2.2.2 ($Date: 2003/05/13 20:27:15 $) **ERROR: [mplex] File test.mpeg1 unrecogniseable! INFO: [mplex] File test.mp3 looks like an MPEG Audio stream. **ERROR: [mplex] Unrecogniseable file(s)... exiting. Right - the file's already multiplexed, into an avi stream. No it's not. It's an MPEG file. It could be multiplexed already with a null soundtrack perhaps. How can I determine if that is what mplex is complaining about? If you're determined to avoid mpeg2enc Well, as we have discussed here before, I have no inherent issues with mpeg2enc other than it takes waay too long to encode. Granted it's a very nice encoding when it does finally finish, but I don't have the CPU bandwidth to spend 8 hours to convert 1 hour of video that I am only going to watch once and then delete. then you might use 'ffmpeg' to do the encoding - it can produce ES files rather than AVI files. Mencoder can produce mpeg files too. See above. I would use ffmpeg, but I want some of the filters mencoder/mplayer has. Specifically the --detc filter, and crop (I know ffmpeg can crop, but it does not have the equivalent of --detc AFAIK) Something like this (suitably modified for your situation of course) might work better. I was testing the mpeg2 encoding capability so for mpeg1 you'd change the 'mpeg2video' to be 'mpeg1video' Actually, my ultimate target is MPEG2, but I thought I would play with mpeg1 first. and of course set the bitrate and bufsize down to reasonable values: ffmpeg -f yuv4mpegpipe -i susi_120.y4m -b 7000 -ilme -ildct \ -aspect 4/3 \ -top 1 -g 15 -maxrate 7500 -f mpeg1video -vcodec mpeg2video \ -bufsize 1840 -y xxx MPEG1's most commonly used for VCD (352x240) - is that what you're doing? Not really. Playing back on a television, which is why I am truely more interested in mpeg2. b. -- My other computer is
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
Hi Brian, On Fri, 2004-01-02 at 16:10, Brian J. Murrell wrote: I don't think so. Mplayer tells me this about the file (if there is a better utility to determine the parameters of an MPEG file, I would be more than glad to use it rather than mplayer): [..] system stream synced at 0xB (0)! [..] No it's not. It's an MPEG file. It could be multiplexed already with a null soundtrack perhaps. How can I determine if that is what mplex is complaining about? It's indeed mpeg, and a system stream (so a muxed mpeg file, not an elementary video stream). You need to demux them in some way. I don't know how to do that with mplayer/ffmpeg. With GStreamer, it's gst-launch filesrc location=file.mpg ! mpegdemux .video_00 ! filesink location=file.m1v. I'm sure Steven knows the proper ffmpeg command, and others will know the right mplayer command. Ronald -- Ronald Bultje [EMAIL PROTECTED] Linux Video/Multimedia developer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004, Brian J. Murrell wrote: Indeed. I have seen some of your traffic on the ffmpeg-devel list. Then you'll also have seen that the speed difference isn't as great has been bandied about at times (well, at least for the cvs version - RC4's delayed until mplex can get fixed for MPEG1 muxing) I know that by default mencoder does produce avi contained files (which I am trying with great effort to get the hell away from. However, it It is a Pain isn't? has a switch -of which you can set to mpeg, to get an mpeg container. But you don't want a container. You want an ES stream not a PS stream! - they're already muxed and definitely not MPEG1 ES files and that is why mplex can't recognize them. I don't think so. Mplayer tells me this about the file (if there is a better utility to determine the parameters of an MPEG file, I would be Mplayer seems to think it's an MPEG-PS stream, without audio even. I And what did I say about PS vs ES a little bit earlier? :-) :-) No it's not. It's an MPEG file. It could be multiplexed already with a True - but it's packetized into a ProgramStream Well, as we have discussed here before, I have no inherent issues with mpeg2enc other than it takes waay too long to encode. Granted it's ~20% speed difference for the encoding isn't all that much. Where some more speedup happens is ffmpeg/mencoder's ability to do the DV decoding internally rather than running thru a pipeline. On the other hand I've found smil2yuv+y4mscaler to seemingly do a better 411 to 420 conversion. CPU bandwidth to spend 8 hours to convert 1 hour of video that I am only going to watch once and then delete. Using the Video/TV-out on a video card? For that type of use I would use MPEG-4. For computer playing that's the better/faster format. MPEG-2 is for set top boxes. At least that's the guidline that's been useful for myself. Actually, my ultimate target is MPEG2, but I thought I would play with mpeg1 first. Going to write it to DVD or SVCD perhaps? If not then mencoder to MPEG4 will do a great job. There are a couple set top boxes that supposedly can handle MPEG4 but I haven't seen at the stores I frequent. Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004, Ronald Bultje wrote: It's indeed mpeg, and a system stream (so a muxed mpeg file, not an elementary video stream). You need to demux them in some way. I don't know how to do that with mplayer/ffmpeg. With GStreamer, it's gst-launch filesrc location=file.mpg ! mpegdemux .video_00 ! filesink location=file.m1v. I'm sure Steven knows the proper ffmpeg command, and others will know the right mplayer command. I'm not an ffmpeg expert - in fact my use of it for encoding is quite recent (primary use was libavcodec for DV decoding). For demuxing I've used 'mpgtx' for quite a while http://mpgtx.sf.net transcode as a tool also I believe - tcdemux - that could be used. ffmpeg can produce ES streams, but I'm not sure about mencoder (I've used it to create divx/avi files but not any mpeg1/2 ones). Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2004-01-02 at 12:54, Steven M. Schultz wrote: Then you'll also have seen I just tuned in in the last couple of days, so I haven't seen much. that the speed difference isn't as great has been bandied about at times (well, at least for the cvs version - RC4's delayed until mplex can get fixed for MPEG1 muxing) Perhaps with the CVS version that is the case, but historically, I have not been able to get more than 5fps with mpec2enc whereas libavcodec gives me closer to 20fps. I know that by default mencoder does produce avi contained files (which I am trying with great effort to get the hell away from. However, it It is a Pain isn't? Yeah, both dealing with avi and trying to not have to deal with it. What a bag of crap avi is. has a switch -of which you can set to mpeg, to get an mpeg container. But you don't want a container. You want an ES stream not a PS stream! Indeed. The difference is only just becoming clear with this thread. I now understand that I want the MPEG stream that would be in the container that mencoders -of mpeg spit's out. I might take a look at the demuxing tool you mentioned in the other message in this thread. And what did I say about PS vs ES a little bit earlier? :-) :-) Yes, indeed. Until the last few hours, the difference between an MPEG-ES and an MPEG-PS was unclear. ~20% speed difference for the encoding isn't all that much. Perhaps mpeg2enc has gotten _a_lot_ more efficient recently, but historically, the best I have seen out of mpeg2enc on my hardware is 5fps. Using the Video/TV-out on a video card? Yes, using DirectFB on a Matrox G400 with it's excellent CRTC2 support. For that type of use I would use MPEG-4. Which is what I am using currently, but so far, the only containers I have been able to put that into is avi and ogm, as far as mplayer playing from either of those, it sucks rocks. For computer playing that's the better/faster format. OK. MPEG-2 is for set top boxes. What exactly is your distinction here? A set-top box is a computer. Perhaps your distinction is between hardware and software decoding? At least that's the guidline that's been useful for myself. My impressions have always been that for interlaced television output, MPEG2 is the best. Going to write it to DVD or SVCD perhaps? If not then mencoder to MPEG4 will do a great job. And other than having to use either an avi or ogm container, I would continue to be happy with it. But both avi and ogm has issues (at least where mplayer is concerned) with files 2G. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell signature.asc Description: This is a digitally signed message part
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004, Brian J. Murrell wrote: Perhaps with the CVS version that is the case, but historically, I have cvs update works wonders ;) not been able to get more than 5fps with mpec2enc whereas libavcodec gives me closer to 20fps. Part of that is that ffmpeg/mencoder can do the conversion internally rather than having external programs and pipes to get the 420 needed by the encoder. now understand that I want the MPEG stream that would be in the container that mencoders -of mpeg spit's out. I might take a look at the demuxing tool you mentioned in the other message in this thread. There are several demuxing tools around - pick the one that works the easiest for you. Yes, using DirectFB on a Matrox G400 with it's excellent CRTC2 support. Ah, ok - that was what I thought might be the case. Which is what I am using currently, but so far, the only containers I have been able to put that into is avi and ogm, as far as mplayer playing from either of those, it sucks rocks. I put the stuff into MP4 containers with AAC audio and MPEG4 video. Not only useable with mplayer but ALSO with Apple's Quicktime player. The couple things you'll need are the AAC encoder (faac from www.audiocoding.com I believe) and 'mp4creator' (a small part of the rather large MPEG4IP project). What exactly is your distinction here? A set-top box is a computer. Perhaps your distinction is between hardware and software decoding? No, a set-top box is the DVD player that John Q. Public gets at Best Buy or Fry's or whatever. A computer is not considered a STB. My impressions have always been that for interlaced television output, MPEG2 is the best. I thought ffmpeg's mpeg4 encoding was interlaced aware. And other than having to use either an avi or ogm container, I would continue to be happy with it. But both avi and ogm has issues (at least where mplayer is concerned) with files 2G. With mpeg4 though you can cut the bitrate down considerably below what mpeg2 requires. ~2000 kbits/sec is more than enough for general mpeg4 use and that's a _long_ movie at 2GB Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2004-01-02 at 14:28, Steven M. Schultz wrote: cvs update works wonders ;) Indeed, if you have the time to manage software in such a manner. I put the stuff into MP4 containers with AAC audio and MPEG4 video. MP4 containers huh? I will have to take a look. Do they overcome 2G file limitations? Not only useable with mplayer but ALSO with Apple's Quicktime player. The couple things you'll need are the AAC encoder (faac from www.audiocoding.com I believe) and 'mp4creator' (a small part of the rather large MPEG4IP project). Thanx! No, a set-top box is the DVD player that John Q. Public gets at Best Buy or Fry's or whatever. A computer is not considered a STB. Yeah, but I am not talking about semantics here. Why is a STB/DVD player more suited to MPEG2 than a computer? Or are you just reflecting the current status in the STB market? I thought ffmpeg's mpeg4 encoding was interlaced aware. I am not sure to tell the truth. My results sure do look interlaced. I just don't know how well suited to field based encoding mpeg4 is. I had always understood that mpeg2 was more suited to field based encoding like television destined material. With mpeg4 though you can cut the bitrate down considerably below what mpeg2 requires. ~2000 kbits/sec is more than enough for general mpeg4 use I use 2500 kbits/sec on full frame (i.e. no cropping, no inverse-telecining), and reduce appropriately from there (i.e. 2000 kbits/sec when inverse-telecined). and that's a _long_ movie at 2GB 1 full hour is slightly more than 1GB, so anything 2+ hours blows the 2GB limitations. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell signature.asc Description: This is a digitally signed message part
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
Hi Brian, On Fri, 2004-01-02 at 21:06, Brian J. Murrell wrote: MP4 containers huh? I will have to take a look. Do they overcome 2G file limitations? MP4 = quicktime, IIRC, so yes. Ronald -- Ronald Bultje [EMAIL PROTECTED] Linux Video/Multimedia developer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004, Brian J. Murrell wrote: Indeed, if you have the time to manage software in such a manner. If a couple minutes to save hours of encoding time doesn't make it worth the small amount of time then nothing will. MP4 containers huh? I will have to take a look. Do they overcome 2G file limitations? Supposedly but since the most common (that I have seen) use of the MP4 container (aka Quicktime) is for 320x240 web movie sized images I don't know if the players will have problems with large files or not. The couple things you'll need are the AAC encoder (faac from www.audiocoding.com I believe) and 'mp4creator' (a small part of Thanx! Welcome! Uh, mpeg4ip is a big project - useful to have though. Yeah, but I am not talking about semantics here. Why is a STB/DVD player more suited to MPEG2 than a computer? Or are you just reflecting And neither am I. Current usage differentiates between computer software playback and a box that sits on top of the TV. Go to any video forum/mailinglist/whatever - you'll see that STB means standalone unit and not a computer. I use 2500 kbits/sec on full frame (i.e. no cropping, no If it's clean material that's a bit on the high side. There are options to ffmpeg/mencoder that will allow the use of a considerably lower bitrate. Mencoder can do the cropping without a speed penalty and that would save some bits. I've done some encoding at ~1500 which came out looking more than acceptable for casual viewing. 1 full hour is slightly more than 1GB, so anything 2+ hours blows the 2GB limitations. Yep - but most TV shows are well less than that (most movies too except for the occasional epic length ones). Hmmm, MPlayer can handle multiple files I believe so that would be another way to handle the long movies - use 2 files perhaps. Cheers, Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, Jan 02, 2004 at 12:29:33PM -0800, Steven M. Schultz wrote: On Fri, 2 Jan 2004, Brian J. Murrell wrote: Indeed, if you have the time to manage software in such a manner. If a couple minutes to save hours of encoding time doesn't make it worth the small amount of time then nothing will. Currently I am using mjpegtools 1.6.1.92 to convert movies to SVCD. How faster is the CVS version compared to the version I have installed? Is it stable for SVCD production? I am thinking about installing it and trying it. Regards. Romildo --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, Jan 02, 2004 at 11:28:23AM -0800, Steven M. Schultz wrote: On Fri, 2 Jan 2004, Brian J. Murrell wrote: Perhaps with the CVS version that is the case, but historically, I have cvs update works wonders ;) Decided to try the CVS version. Fetched the mjpeg_play module. But ./autogen.sh fails with the error: [...] config.status: creating mjpegtools.spec config.status: creating config.h config.status: error: cannot find input file: config.h.in Am I missing something here? Romildo --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote: Decided to try the CVS version. Fetched the mjpeg_play module. But ./autogen.sh fails with the error: [...] config.status: creating mjpegtools.spec config.status: creating config.h config.status: error: cannot find input file: config.h.in Am I missing something here? config.h.in should be generated by autoconf. What version of autoconf/automake is installed on the system? When I run ./autogen.sh it looks like this: moe.836- ./autogen.sh **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. processing . Running libtoolize... Running aclocal ... Running automake --gnu ... Running autoconf ... Running ./configure --enable-maintainer-mode --enable-compile-warnings ... checking build system type... i386-pc-bsdi4.3.1 ... checking x86 sub-architecture settings... -mcpu=i686 -march=i386 checking what warning flags to pass to the C compiler... -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align -Wwrite-strings -Wcast-qual -Wmissing-prototypes -Wpointer-arith -Wcast-align -Wwrite-strings -Wcast-qual configure: creating ./config.status config.status: creating Makefile config.status: creating debian/Makefile config.status: creating docs/Makefile config.status: creating lavtools/Makefile config.status: creating yuvdenoise/Makefile config.status: creating yuvfilters/Makefile config.status: creating mpeg2enc/Makefile config.status: creating aenc/Makefile config.status: creating mplex/Makefile config.status: creating scripts/Makefile config.status: creating utils/Makefile config.status: creating utils/altivec/Makefile config.status: creating utils/mmxsse/Makefile config.status: creating mjpegtools-config config.status: creating mjpegtools.pc config.status: creating mjpegtools.spec config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands MJPEG tools 1.6.1.93 build configuration : - X86 Optimizations: - MMX/3DNow!/SSE enabled : true - cmov support enabled: true * NOTE:* * The resultant binaries will ***NOT*** run on a K6 or Pentium CPU * - video4linux recording/playback: false - software MJPEG playback : true - MPEG Z/Alpha : false - Quicktime playback/recording : true - PNG input support : true - AVI MJPEG playback/recording : true (always) - libDV (digital video) support : true - libDV PAL YV12 read support : false - Gtk+ support for glav : true Now type `make' to compile The Linux Audio Video tools Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, Jan 02, 2004 at 04:49:15PM -0800, Steven M. Schultz wrote: On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote: Decided to try the CVS version. Fetched the mjpeg_play module. But ./autogen.sh fails with the error: [...] config.status: creating mjpegtools.spec config.status: creating config.h config.status: error: cannot find input file: config.h.in Am I missing something here? No, there was a bug in configure.in that caused autoheader to never be run. I have checked in the fix. You can, temporarily (until Sourceforge catches up in a couple hours) work around the bug by running 'autoheader' manually. Then config.h.in will be generated and ./autogen.sh will work. That worked. Now make fails: $ make make all-recursive make[1]: Entering directory `/var/tmp/mjpeg_play' Making all in utils make[2]: Entering directory `/var/tmp/mjpeg_play/utils' Making all in mmxsse make[3]: Entering directory `/var/tmp/mjpeg_play/utils/mmxsse' /bin/sh ../../libtool --mode=compile --tag=CC /bin/sh ../../strip_fPIC.sh /usr/bin/nasm -f elf -o mblock_bsad_mmx.lo mblock_bsad_mmx.s libtool: unrecognized option `--tag=CC' Try `libtool --help' for more information. make[3]: *** [mblock_bsad_mmx.lo] Error 1 make[3]: Leaving directory `/var/tmp/mjpeg_play/utils/mmxsse' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/mjpeg_play/utils' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/mjpeg_play' make: *** [all] Error 2 Any clues? Romildo --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Fri, 2 Jan 2004 [EMAIL PROTECTED] wrote: No, there was a bug in configure.in that caused autoheader to never be run. catches up in a couple hours) work around the bug by running 'autoheader' manually. Then config.h.in will be generated and That worked. Ah, good! Now make fails: With a libtool related error. /bin/sh ../../libtool --mode=compile --tag=CC /bin/sh ../../strip_fPIC.sh /usr/bin/nasm -f elf -o mblock_bsad_mmx.lo mblock_bsad_mmx.s libtool: unrecognized option `--tag=CC' Try `libtool --help' for more information. make[3]: *** [mblock_bsad_mmx.lo] Error 1 make[3]: Leaving directory `/var/tmp/mjpeg_play/utils/mmxsse' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/mjpeg_play/utils' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/mjpeg_play' make: *** [all] Error 2 Any clues? Of course ;) libtool-1.5 is, apparently, now a requirement. The --tag capability is from libtool 1.5 and was needed for building the shared libraries (the core of the encoder is now a shared lib that can be used by other programs). libtool-1.5 is much better than 1.4.x (especially when C++ shared lib building is involved - and on OS/X 10.3 libtool-1.5 comes pre-isntalled and integrated which helped me a lot on that system). The newer version of libtool has not introduced any compatibility problems at all for me (on any of 3 or 4 different operating systems) so my suggestion would be to install libtool-1.5 Good Luck! Steven Schultz --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder
On Sat, 3 Jan 2004, Brian J. Murrell wrote: The actual build, once you got everything right, yes you are right. It's the management of this depends on that, so build that, which As the toolbox is becomes more complete the management gets simpler. depends on the other so build the other and so on and so forth (like my current fight with mpeg4ip -- all kinds of gripes from automake/autoconf, etc.). It's just so much easier when the distro strange - given recent vintage automake/autoconf/libtool tools it should have been a simple matter of ./cvs_bootstrap and make. The bundled version of the SDL is the only thing that gave me a struggle on one of my systems (heck, even got mpeg4ip to build on OS/X except for the mp4player program which the developers tell me wouldn't work on OS/X anyhow. but mp4creator and other programs run ok and I find them easier to use than Apple's gui programs for manipulating Quicktime files). Not even to mention the mess of a system you wind up with when you can't track the origin of a given file (like you can for example when you do an rpm -qf `which mpeg2enc`). I've got 600+ files in /usr/local/lib and know where everything came from ;) Welcome! Uh, mpeg4ip is a big project - useful to have though. So I am discovering. I am going to attempt to build just mp4creator and see if it's useful before I try to build the whole beast. Down that path lies a bit more madness than you've already encountered. As I recall from talking to the creators of the project you'll need a couple of the shared libs such as libmp4v2 and libmp4av at least - so you can try building those first, then into the server/util directory, there are some very useful utilities in that (and of course the mp4creator program). Once the ./configure problem(s) are taken care of it's as easy to build the whole thing with 'make' than it is to pickchoose. Right. I agree. But I want to clarify if you are asserting that mpeg2 only belongs in a (trying very hard to not use the term STB) dedicated hardware device (and not on a software device) or if that is just the Not at all. At the moment MPEG-2 is most useful on standalone hardware players simply because there are no units (not quite true - I think there are 2) that handle anything else. You can't put MPEG-4 onto a DVD, take the disc and go into Circuit City (or wherever) and expect it to play on anything except a computer. But are you asserting that mpeg2 should not be used in a computer running software to be the equivalent of an STB (i.e. No. Feel free to use whatever suits your fancy on your computer. For DVD sized data I use MPEG-2, for the smaller resolutions I might use MPEG-4. MPEG-4 does better at the lower bitrates (smaller files) than MPEG-2 though so if smaller files (to get under the 2GB limit) is the goal then MPEG-4 is a better choice. Once you get up around 4Mb/s there's nothing really to be gained with MPEG-4 - the files are just as big their MPEG-2 counterparts. One drawback of MPEG-4 at the present time is that at the higher resolutions the current software decoders begin using a lot of cpu. MPEG-2 decoders are more mature and there are hardware assists - some video cards have MPEG-2 decoders built in and the nVidia one I'm using comes with libraries that ffmpeg/mplayer use to talk to the hardware decoder (only works for MPEG-2 though). By the time you get up to the HDTV (1920x1080) size even a 3GHz cpu was down in the low single digit frames/sec range (at least in the one test that one of the video magazines ran) when playing back MPEG-4. At one time there was mention of MPEG-4 being used for the HD-DVD format but that seems to have faded in favor of MPEG-2 and different lasers. Patent issues and/or greed I think are what effectively relegated MPEG-4 to niche areas (and geeks). Agree. It's analog cable however, and not very clean at that. Ah, ok. Digital cable can be quite a bit cleaner but it's not as widely available. options to ffmpeg/mencoder that will allow the use of a considerably Yeah, I know. But unfortunately I don't understand enough about video encoding to understand (some of) them. They are also not very well documented. '-vf hqdn3d,trell' are two that come to mind. Mencoder can do the cropping without a speed penalty Right. ISTR that I lower the bitrate when I crop. I know I do when I The other thing that can be done is to downscale. Mplayer (perhaps ffplay as well) know how to deal with the coded frame size being different than the
