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 - grrrrs. Yeah. What he said: "grrrrs". > 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 wonder how long that will last. (Being serious here, not at all facetious.) > Improve quality - that means higher quality at the same bitrate or > you can lower the bitrate and maintain the quality level. I might give those a shot. I wrote in a previous message: > > I am currently using: > > > > vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:vhq:vqmin=2:ildct > > 'vhq' has been deprecated as I understand it. Certainly possible. > it is equivalent to > 'mbd=1' and the current advice is to use 'mbd=2' I will look into that too. > Ah, ok - so at that size I'd think 1500 to 2000 kbits/sec would be > more than sufficient for good quality. I have lowered my default full frame size/rate to 2000. I just finished a transcode and the quality is "so-so". I think 2500 would have given a bit cleaner results. There was some visible blockiness and loss of sharpness around edges/sharp transitions. But using your suggestions for higher quality might take care of that. > Good to know the verbosity wasn't excessive ;) Not at all too verbose. Not even nearly so. I hung on your every word. I hope our discussion has been valuable to somebody else too. > Cheers, Right back at ya! b. -- My other computer is your Microsoft Windows server. Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
