[SOLVED] Convert Movies From a Digital Camera

Woodsman · 09-20-2009, 12:04 AM

My Canon PowerShot A590IS digital camera records movies with a format of:

Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 20 tbr, 20 tbn, 20 tbc
Stream #0.1: Audio: pcm_u8, 11024 Hz, mono, s16, 88 kb/s

For whatever reason, XBMC refuses to play the audio. Xine plays the audio but with a distressing static noise. MPlayer and Kaffeine play the files fine.

The bottom line is XBMC and Xine seem to dislike pcm_u8 audio, or the way the audio is streamed with the video.

I also cannot fast-forward the movies with some players, such as MPlayer or SMPlayer.

I haven't found whether I can select a different format with the camera, but to avoid player problems I'd like to convert the videos. My primary focus is playing in XBMC and Xine because I have both apps configured to be controlled with a remote control.

What is the most compatible format to convert? This is with 12.2 or 13.0. I have ffmpeg, mplayer, and mencoder installed and probably all or most codecs I could use.

I'm not much of a wiz with converting. Therefore I appreciate any syntax help too.

andrew.46 · 09-20-2009, 12:34 AM

Hi Woodsman,

Quote:

Originally Posted by Woodsman

Code:

Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 20 tbr, 20 tbn, 20 tbc
Stream #0.1: Audio: pcm_u8, 11024 Hz, mono, s16, 88 kb/s

[...]

What is the most compatible format to convert? This is with 12.2 or 13.0. I have ffmpeg, mplayer, and mencoder installed and probably all or most codecs I could use.

I feel a little odd proffering advice to a man whose website I have long pillaged for useful information

. However if you are after 'most compatible' the following might be a start:

Code:

ffmpeg -i <inputfile> -vcodec mpeg4 -sameq -vtag XVID -acodec libmp3lame -ab 88k outputfile.mp4

mpeg4 is pretty universal and -vtag XVID will ensure that Windows player will not choke (the FFmpeg fourcc is FFMP4 which can be a problem). mp3 sound is pretty common and you will need to specify a bitrate (-ab 88k) otherwise the default of 64k will be used. mp4 container should be common enough and it is a much better container than avi.

No doubt many others will have many other views

.

Andrew

Woodsman · 09-20-2009, 11:56 AM

Quote:

I feel a little odd proffering advice to a man whose website I have long pillaged for useful information.

Thanks for the compliment, but audio/video file conversions are voo-doo to me.

Besides, one of the great lessons I have accepted in life is that the more I learn the more I realize how little I know.

Quote:

if you are after 'most compatible' the following might be a start:

Hmm. I tried that option. ffmpeg refused to convert, not not liking the acodec option. I have the lame-3.98.2 package installed and never had problems before.

What did succeed was no parameters at all:

ffmpeg -i filename.avi -y filename.mp4

The resulting container:

Stream #0.0(und): Video: mpeg4, yuv420p, 640x480 [PAR 1:1 DAR 4:3], 20 tbr, 20 tbn, 20 tbc
Stream #0.1(und): Audio: aac, 11025 Hz, mono, s16

The original file size was 67.4 MB. The new file size is 3.4 MB. Is such a file size reduction normal?

With the converted files I seem to have no problems with fast-forwarding in the apps I use. Also, there is no longer any disorienting static hum when I play the converted video in Xine.

The big test was playing in XBMC because I want to play the movies for some guests. The converted files played okay there too.

Windows is not a big concern for me. The original camera files play fine in that system.

Unfortunately, video quality deteriorated with the converted files. Tolerable perhaps with a small LCD monitor but not with a larger HD TV.

Thus the conversion worked but at too high a price.

I tried the following:

ffmpeg -i filename.avi -vcodec copy filename.mp4

The sound stream converted but not the video.

Next I tried:

ffmpeg -i filename.avi -vcodec mpeg4 filename.mp4

That too converted but again the video quality was worse. The effect seems to always be a smudging/blurring of the video.

andrew.46 · 09-20-2009, 05:34 PM

Hi Woodsman,

Quote:

Originally Posted by Woodsman

Hmm. I tried that option. ffmpeg refused to convert, not not liking the acodec option. I have the lame-3.98.2 package installed and never had problems before.

In that case I suspect that your copy of FFmpeg has not been compiled against lame. The easiest way to test this is with:

Code:

andrew@skamandros~$ ffmpeg -formats | grep mp3
FFmpeg version SVN-r19920, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --prefix=/usr --mandir=/usr/man --disable-debug 
--enable-shared --disable-static --enable-postproc --enable-avfilter 
--enable-pthreads --enable-libtheora --enable-libvorbis 
--enable-x11grab --enable-libmp3lame --enable-libx264 
--enable-libschroedinger --enable-libfaac --enable-libfaad 
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3
 --enable-libgsm --enable-libspeex --enable-zlib --enable-nonfree --enable-gpl
  libavutil     50. 3. 0 / 50. 3. 0
  libavcodec    52.35. 0 / 52.35. 0
  libavformat   52.38. 0 / 52.38. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libavfilter    0. 5. 0 /  0. 5. 0
  libswscale     0. 7. 1 /  0. 7. 1
  libpostproc   51. 2. 0 / 51. 2. 0
  built on Sep 19 2009 20:06:20, gcc: 4.3.3
 DE mp3             MPEG audio layer 3
  EA    libmp3lame      libmp3lame MP3 (MPEG audio layer 3)
 D A    mp3             MP3 (MPEG audio layer 3)
 D A    mp3adu          ADU (Application Data Unit) MP3 (MPEG audio layer 3)
 D A    mp3on4          MP3onMP4
 text2movsub remove_extra noise mov2textsub mp3decomp mp3comp 
mjpegadump imxdump h264_mp4toannexb dump_extra aac_adtstoasc

and if the libmp3lame option is not present simply recompile with the appropriate ./configure option: --enable-libmp3lame.

Quote:

What did succeed was no parameters at all:

ffmpeg -i filename.avi -y filename.mp4

The resulting container:

Stream #0.0(und): Video: mpeg4, yuv420p, 640x480 [PAR 1:1 DAR 4:3], 20 tbr, 20 tbn, 20 tbc
Stream #0.1(und): Audio: aac, 11025 Hz, mono, s16

The original file size was 67.4 MB. The new file size is 3.4 MB. Is such a file size reduction normal?

I suspect what has happened is that since you have not specified either audio or video bitrates FFmpeg has chosen the defaults which are probably substantially lower than that of the input file. You have snipped the vital line, just above the 2 'Stream' lines that demonstrates the bitrate

.

Quote:

Unfortunately, video quality deteriorated with the converted files. Tolerable perhaps with a small LCD monitor but not with a larger HD TV.

Thus the conversion worked but at too high a price.

The easiest way to maintain quality without having to delve to far into the encoding parameters is to use the -sameq option which attempts to match the video input quality with the video output quality. This might be worth a try.

Quote:

I tried the following:

ffmpeg -i filename.avi -vcodec copy filename.mp4

The sound stream converted but not the video.

Seems a little odd, normally this would copy the video and not transcode the audio at all.

Quote:

Next I tried:

ffmpeg -i filename.avi -vcodec mpeg4 filename.mp4

That too converted but again the video quality was worse. The effect seems to always be a smudging/blurring of the video.

Again I suspect that FFmpeg has chosen the default bitrates and given you a sub-optimal transcode. You could try the -sameq option but if your copy of FFmpeg is recent there is a nice alternative.

I have misunderstood you a little perhaps when you mentioned that you were after a 'compatible' format to transcode to, and I mentioned the lowest common denominator of mpeg4 and mp3 in an mp4 container, although an avi container would have been even lower

. If however you are after a good-looking conversion for playback on your own computer and a few other screens you could not go past x264 encoding and the current presets make this very easy. Something like the following:

Code:

ffmpeg -i input.avi \
       -acodec libfaac -ab 128k -ac 2 \
       -vcodec libx264 -vpre hq -crf 22 \
       -threads 0 output.mp4

would serve you will as long as your copy of FFmpeg is recent and has been compiled against x264. This uses the high quality x264 video preset (-vpre hq) and one pass Constant Rate Factor quality (-crf 22) and this is the syntax I use for my own relatively quick conversions. The libfaac settings might need some adjustment depending on the quality of the input sound and the final output results.

I hope my disjointed meanderings have made a little sense, I find the area of video and audio transcoding absolutely fascinating but I am still very much a student of the area.

Andrew

Woodsman · 09-20-2009, 10:48 PM

Quote:

and if the libmp3lame option is not present simply recompile with the appropriate ./configure option: --enable-libmp3lame.

Yup, everything is there.

Quote:

Something like the following:
ffmpeg -i input.avi -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre hq -crf 22 -threads 0 output.mp4

That seems to work great.

I tried two camera files: one shrunk from 64.7 MB to 12.2 MB. The other shrunk from 153.7 MB to 20.4 MB. Such a huge change in file size!

No buzzing noise from Xine and MPlayer with fast-forward. Video quality seems the same too.

I tested the converted files with XBMC. Seems XBMC is happy with those files now too. So perhaps the file size shrinking is an insignificant issue.

Although, I admit my opinion of XBMC is dwindling each day. The app is buggy and crashes a lot. Seems the least little thing will cause the app to crash or freeze KDE. KDE freezes a lot too. Perhaps the problem is the interaction between the two. I'm going to recompile XBMC with the --disable-pulse option. I hope that helps.

Regardless, seems I now have a way to play my camera movies with XBMC and Xine. I should not have to convert all the files but that seems the only method to avoid cussing and swearing. Possibly future versions of XBMC will not be so persnickety.

Woodsman · 09-25-2009, 07:28 PM

Update: XBMC plays the camera movies fine if I use the DVI video connector and external speakers. The problem arises when I try to run audio through HDMI with my HD TV.

Woodsman · 03-22-2010, 03:40 PM

Update: I never really got back to troubleshooting the problem until recently because I had been always using XBMC on my HTPC. I think the problem with audio over HDMI is caused by the proprietary Nvidia drivers. Ever since I connected my TV to the DVI port rather than HDMI I no longer had any related problems.

Recently I used Xine on my office system to check some movies from my camera and the audio buzzing noise again appeared. I decided to investigate. I eliminated the buzzing problem with Xine by creating a new config file and then merging a handful of options from a backup copy. Something in the Xine config file caused the buzzing noise. Go figure.

So let's stamp this one solved.

H_TeXMeX_H · 03-23-2010, 03:51 AM

Code:

ffmpeg -i input.avi -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre hq -crf 22 -threads 0 output.mp4

Why 2 channels ? The audio is only 1 channel.

Code:

Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 20 tbr, 20 tbn, 20 tbc
Stream #0.1: Audio: pcm_u8, 11024 Hz, mono, s16, 88 kb/s

Also, with ffmpeg, I would specify things like the FPS (20 here), and the audio sample rate, because it doesn't use the originals.

I would do:

Code:

ffmpeg -i input.avi -vcodec libx264 -vpre hq -crf 23 -s 640x480 -r 20 -aspect 4:3 -threads 0 -acodec libfaac -ab 128k -ar 11024 -async 11024 -ac 1 output.mkv

or you can resample to say 44100 if you want.

andrew.46 · 03-23-2010, 04:38 AM

Hi H_TeXMeX_H,

Quote:

Originally Posted by H_TeXMeX_H

Why 2 channels ? The audio is only 1 channel.

Oops

. As well I see there has been something of an explosion in the x264 presets fairly recently, in the svn FFmpeg:

Code:

andrew@skamandros~$ ls /usr/share/ffmpeg
libx264-baseline.ffpreset	     libx264-max.ffpreset
libx264-default.ffpreset	     libx264-medium.ffpreset
libx264-fast.ffpreset		     libx264-medium_firstpass.ffpreset
libx264-fast_firstpass.ffpreset      libx264-normal.ffpreset
libx264-faster.ffpreset		     libx264-placebo.ffpreset
libx264-faster_firstpass.ffpreset    libx264-placebo_firstpass.ffpreset
libx264-fastfirstpass.ffpreset	     libx264-slow.ffpreset
libx264-hq.ffpreset		     libx264-slow_firstpass.ffpreset
libx264-ipod320.ffpreset	     libx264-slower.ffpreset
libx264-ipod640.ffpreset	     libx264-slower_firstpass.ffpreset
libx264-lossless_fast.ffpreset	     libx264-slowfirstpass.ffpreset
libx264-lossless_max.ffpreset	     libx264-ultrafast.ffpreset
libx264-lossless_medium.ffpreset     libx264-ultrafast_firstpass.ffpreset
libx264-lossless_slow.ffpreset	     libx264-veryfast.ffpreset
libx264-lossless_slower.ffpreset     libx264-veryfast_firstpass.ffpreset
libx264-lossless_ultrafast.ffpreset  libx264-veryslow.ffpreset
libx264-main.ffpreset		     libx264-veryslow_firstpass.ffpreset

which I for one have not even looked at yet...

Andrew

H_TeXMeX_H · 03-23-2010, 07:02 AM

I have my own preset called "special"

Code:

coder=1
flags=+loop
cmp=+chroma
partitions=+parti8x8+parti4x4+partp8x8+partb8x8
me_method=hex
subq=6
me_range=16
g=250
keyint_min=25
sc_threshold=40
i_qfactor=0.71
b_strategy=1
qcomp=0.6
qmin=10
qmax=51
qdiff=4
bf=3
refs=5
directpred=3
trellis=1
flags2=+wpred+mixed_refs+dct8x8+fastpskip+mbtree
wpredp=2

It's between hq and default, faster than hq, better quality than default.

hughetorrance · 03-23-2010, 07:34 AM

Besides, one of the great lessons I have accepted in life is that the more I learn the more I realize how little I know. Its the same for all reasonably honest folks,also the unknown is exactly the same whether you are looking for the Higgs Bosun or startx... LOL