On Wed, Sep 07, 2011 at 04:27:28PM +0100, Ken Moffat wrote: > Thanks, I'd not thought of this! Got too hung-up on the "maintain > the quality" suggestions on the recent youtube pages (supposedly, > everything gets recoded for html5). Some things I've downloaded > (with the youtube_dl Python prog/script) show all sorts of different > codecs, but the video bitrates are typically 3000k or less, and audio > never exceeds 125k bits. My original .mov files are typically > 31000k video and 512k audio (but only 16KHz sampling frequency). > > What I'm doing now is to use ffmpeg to convert .mov to .mp4 with > lower bitrates. When ffmpeg is told to produce .mov or .mp4 it > converts the input mjpeg with mp3 to mpeg and aac. Both xine and > totem play these output files correctly. Maybe I'll even do this in > future for initial review, the outputs are more sensible sizes. > > Still experimenting with bitrates : -b 3000k -ab 64k is as good as > I need [ 3000k+ video bits, nominal 64k audio bits ] but I'm still > playing with the numbers. Will need to upload an example at what I > think is a good compromise size (my upload is *slow*), then see what > results. > And then there was almost a month of silence on this thread, accompanied by extremely loud swearing as my attempts to upload all produced rubbish (as in - no relationship to either the audio or video that I uploaded). Luckily, I got a response at http://www.google.com/support/forum/p/youtube last weekend, and tonight, on my shiny new LFS-6.8 system I've successfully uploaded a 20 second clip.
In case anyone hits this in a search engine, here's a few of the things I've learned along the way: 1. Higher video bitrates than 3000k ARE necessary. For my 1280x720 upload, 5500k is mostly adequate (when upscaled to fullscreen on my 1600x1200 monitor). So far, I've only looked at the 480p webm version at youtube (my net is slow, must upgrade somewhen), and at that size I doubt high bitrates make a difference. 2. libx264 is a key factor in creating an mp4 file that youtube can process. I was pointed to 'mediainfo' (sf.net - command-line version) to check the file details, and that tells me that ffmpeg-0.8.4 uses the avc1 codec for this. 3. For some codecs, 2-pass encoding in ffmpeg seems to make sure both streams (video, audio) are the same length. With aac (which is what I've created), there is still a difference, 16mS in this case. Conversely, my original .mov file is supposedly 2h57m of audio, and 20s of video (it's actually just 20s, give or take). 4. The expected audio standard is 44k1 sampling. My bridge camera (Panasonic DMC-FZ45 set to produce mjpeg files) samples at 16kHz so I've resampled, with secret rabbit code (libsamplerate) in my ffmpeg build. 5. mp4 (and mov) files might *need* to be 'fast start'. With ffmpeg-0.8.4 the supplied tools/qt-faststart builds (I was previously on the 0.6 series, and it refused to link). There is a separate Python program for this which appeared to work on the previous system. Oddly, the python version can handle my .mov file from the camera (77MB - tried uploading that - the top of the picture was ok, but the rest was garbage) but the version from ffmpeg-0.8.4 doesn't like it. 6. totem (now that I've built it - it's right at the end of my desktop scripts) can play these files happily, as can ffplay. xine thinks it can, but the avc1 video mostly comes out as black and white, with coloured noise bands across the bottom of the picture. Hmm, if I hadn't just downloaded another symphonic video, I might drop xine - previous experience showed the audio on xine with a particular format, probably vorbis, was much better than with totem. Horses for courses. So, the commands I'm using now are: $ffmpeg -i input.mov -s 1280x720 -vcodec libx264 -vpre baseline -b 5500k -pass 1 -an -y output.mp4 So, a few more video bits than the baseline which was about 4800k. The 'lossless' ffmpeg presets for libx264 produce a much lower quality. $ffmpeg -i input.mov -s 1280x720 -vcodec libx264 -vpre baseline -b 5500k -pass 2 -acodec aac -strict experimental -ac 2 -ar 44100 -ab 96k -y output.mp4 ffmpeg-0.8.4 supplies its own aac encoder, so libfaac is not needed, but it demands '-strict experimental' to enable it. I'm not sure if I need to specify 2 channels, but it does no harm. So, one video now uploaded, nearly time to try rebuilding this desktop on current LFS, just got to finish testing applications. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
