This entry was posted
on Thursday, January 24th, 2008 at 3:37 am and is filed under Uncategorized.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.
At the bottom of the posting you’ll see a little rectangular graphic that says ‘Video AVI’. Right-click this and ‘Save Link As…’ and you can save the AVI as before. Also you can right-click the ‘Download’ link that is right beside it. In any case, *left*-clicking the links might try to view the AVI instead of downloading it.
I don’t think we could make the download link exactly the same as before when we moved to WordPress. When I say we couldn’t, I mean that it might be possible but it’s not within our limited grasp of WordPress at the moment. 😉
Heathenx must be going Ubuntu since that button looks a little brown and chocolatey. 😉
Just like Richard has already explained, we are now using podPress to handle our AVI videos. It works very well within WordPress and automatically formats our RSS feed for video. This saves us a little work and plays quite nicely with Miro and eventually iTunes when and if we ever leave the AVI container behind for a proper MP4 container. In other words, podPress helps us to future proof some of our content.
Subscribing to our “episode” RSS feed might make it easier for some of you to get the AVI’s. Our flash videos are still there and still working but just slightly hidden. Clicking the above image will send you to our flash page.
When we converted our site over to WordPress we tried to keep it as close to our old static site as possible. Obviously everything cannot be converted and some things were better to have than other things. Sorry for the inconvenience.
Pizazz to a project are nice but a sparkling gold tooth is the icing on the cake. I like those little surprises.
What is holding you back to use an MP4 container? You are already encoding to H264. In general people are struggling with video and audio codecs whereas the container is more or less a piece of cake, to stay in terms of food.
Actually, if we really wanted to we could put our videos inside of an MP4 container now. I was waiting on some things to happen first.
One: I would like the new flash player to be released so that MP4 videos are supported. That way we won’t have to use flv files anymore. We could stream the MP4 as well as offering the MP4 for download. Of course that has to be proven first.
Two: Perhaps it is now but I would like Mencoder to export directly into the MP4 container. That way Richard and I do not have to change our work flow. The last time that I looked into it I think I had to use MP4Box or use h264enc 100% of the time. Maybe I need to start researching this again. To get a fully compatible MP4 video, I think I should use AAC audio as well. Hmm…
Three: Waiting on the US election to be over with.
Okay, I was just joking about that third thing but that gave me another excuse to drag my feet for another year. 😀
Need I remind you of the place we seem to have recently vacated… Encoding Hell ™. ? It’s a slippery slippery slope man. 😉
I have no problem using an mp4 container. Whatever will work for the most people. I agree about waiting for the flash player to simplify things. In any case, changing workflow is not that big a deal to me. I create these things so few and far between that I have to re-learn it every time anyway! 😉
Well, encoding to AAC is a breeze. Default values for the options will very probably work, in other words -oac faac will likely do the job.
Although mencoder allegedly supports the MP4 and MKV containers now, it seems that the lavf muxer is buggy. Nevertheless, it has triggered me to check how far my mileage varies. I am curious myself and could use it myself if MKV works.
Flash Player supports MP4 now although I doubt Linux is supported. I couldn’t find a recent version of the flash plugin. Anyway, also worthwhile to check myself.
Yeah but I got so used to being in Encoding Hell that I bought a cottage there. I’m also going to apply for citizenship. That way I’ll feel more at home.
I agree. Putting them into AAC format is a cake walk. Video will be a little trickier because I would be interested in 100% compatibility with the Quicktime Player.
So far I can convert an AVI/MP3 video to MP4/AAC with Avidemux quite easily. But, it doesn’t appear to be Quicktime compatible. I can hear sound but can’t see video. VLC and a slight adjustment to K-Lite H.264 codec works but I still feel uncomfortable about it.
Haven’t tried mencoder yet. I’ll give that a try next.
The most recent flash plug-in can be found at Adobe Labs. I had it running on my openSUSE 10.3 rig for a while but it only works with Firefox. It broke my other browsers so I went back to the official release.
PS. Won’t vote until November. I normally don’t talk politics because I could care less about other people’s opinions. Although, I wouldn’t mind seeing Barack Obama as our next President if that clues you in on how I lean. 😉
I am not in front of my suse box with my svn version of mencoder/mplayer so I haven’t tried mencoder yet. Although, I tried ffmpeg on my WinXP box and got a compatible mp4/acc video that Quicktime plays. I used this ffmpeg command:
MEncoder does not seem to work. Although I get nice files, only MPlayer seems capable of playing them. I would suggest not to use MEncoder (which hurts me as it is my favorite encoder).
FFmpeg creates files which seem indeed to work. I cannot say anything about the quality you get but the example I used on my machine, was good and was at most a bit slower than MEncoder or Avidemux. I noticed that you use a lot of options. Did you start from zero and finally arrived at these options for the best result possible? One could try -startq or use double pass encoding which should make a difference. But as Richard mentioned, Encoding Hell is lurking here.
Avidemux astonished me. I rarely use it but I had a closer look now and I must admit, it seems to become very capable. Most striking is that its MP4 files were playable by my flash player (flowplayer) in my browser!
This brings me to the flash player. Yes, I must conclude it plays MP4 files with H264 video and AAC audio. That is also good news for me. By the way, the link above to Adobe Labs point to this page. In the mail that I received, however, the link was correct.
Last remark. Quicktime is, or at least was up to and including version 7.0, not capable of coping with all H264 options, notably High Profile options. For example, 8x8DCT and more than 2 B-frames is (was?) a problem. Maybe something to pay attention to when using for example Avidemux with all its preset options. I do not have Quicktime, so I cannot test it.
Actually, it’s very important to me that mencoder works. Although I would switch in a heart beat to something else that was easier to use and faster to encode (maybe Avidemux) but I haven’t found anything yet.
Last night I found some time to encode with mencoder and mp4box. It was successful. My finished mp4 file played perfectly in Quicktime 7+ on WinXP. I have not attempted to fully produce a video yet. So far I only converted an episode without our intro.
I have made a bash script that converts an ogg file made with recordmydesktop, convert to avi, and then convert the container from avi to mp4. You’ll need mplayer/mencoder, and gpac install. The last package will give you mp4box.
Here is what I have done:
# packages needed gpac (MP4Box), mplayer/mencoder
# this script creates a mp4/aac video from an ogg screencast
Of course I have not settled or tweaked any of the switches in my 2 pass avi conversion. They are pretty basic at the moment. I used 1 channel audio too so Richard will want 2 channel for his ‘casts. Fps need to be adjusted back to 29. Also, I may be wrong but I think I can only use 1 b-frame when using mp4 files. In other words there is some tweaking to do. I went rather quickly to get things working.
I referenced this link and used mp4box instead of mp4creator.
I was indeed not clear when I wrote that “MEncoder does not seem to work”. The x264 and faac codec of MEncoder do not pose any problem. It is the MP4 container generated by use of “-of lavf -lavfopts format=mp4” which is buggy. In fact, I am puzzled by this behaviour because MEncoder uses FFmpeg which can spit out proper MP4 containers. The point seems to be B-frames. Tomorrow I will check in more detail what happens if I explicitly turn off B-frames.
I have never used MP4box but in my opinion you have arrived at a very decent workflow. All work is essentially done by MEncoder and, as I expected, the container work is straightforward: dumping and remuxing. As usual one encounters the biggest issues in the video encoding.
You could gain speed by turning down/off some options in the first pass. The first pass is rather an information collector to determine where most bits are needed. For that, it does not need the highest settings. For example, turning off me=umh (default is hex) would not probably hurt. Or set turbo=1 (default is 0) in the first pass to disable some CPU intensive options. One has to experiment here; no hard rules exist.
As far as I know, the standard does not restrict the MP4 container to 1 B-frame. It has more to do with profiles. Quicktime does/did not support the High Profile fully. I think that is where the maximum of 1 B-frame came from (or maybe even legacy from AVI). One could just walk on the safe side and stick to 1 or use 2 and check the result with the Quicktime player.
By the way, nice discussion. It has been some time since I fiddled with encoding options. It triggers me to have a look again at my own workflow.
Yup, I’m with you regarding tweaking the mencoder settings. Richard and I don’t do a 2-pass encode (at least I don’t think he does) on our videos now. However, if we move to mp4 then I may go that route if it increases quality. Our videos are not the best in terms of clarity sometimes. We do the best with what we have.
I am pretty much settled on the fact that I can make a Quicktime compatible mp4 file. My next challenge will be merging or joining two mp4 files (our intro and our screencast) together. So far I haven’t had much luck with MP4Box’s -add or -cat switches. That has been the only show stopper.
Moreover, not sure how Flash compatible these mp4’s will be. I may wait until that plugin is officially released.
The secret is aglobal=1 and vglobal=1. They take care of where global headers are to be written (in this case in extradata). I cannot find further information on that, so I have no idea what exactly happens; my wild guess would be that it has something to do with hinting for streaming media. FYI, a value of 3 works also. Because these options have to be set, I could not use -oac faac or -ovc x264. But this is a minor problems as their respective options can easily be translated into those for lavc.
I added vmax_b_frames=0 to make it explicit that no B-frames are to be used. This is just an MEncoder quirk and has nothing to do whatsoever with the MPEG-4 standard. My input file does not have B-frames either. I am not sure what would happen if it did. Of course I did not pay attention here at all to the quality. I just tried to figure out the essential options for a working, streamable MP4 file.
As mentioned previously, I do not have a Quicktime Player. Because of that I have no idea about its compatibility.
If this works for you also, I think your concatenation will be solved at the same time. I just assume MEncoder will correctly handle that.
That’s great news, Serge! However, I’m having a tricky time getting your script to work on my ubuntu box with mplayer 1.0 rc1. It’s only on my opensuse box that i have an svn version of mplayer (which i think is rc2 now). Are you using an svn version?
Serge, your script works on my opensuse box. Although, the video plays a little faster than normal and I don’t get any sound. 🙁 Interesting anyway.
Just realized my mistake:
Scratch the above. Ok, I think I’m too tired to concentrate. Sound does work except that it’s out of sync with the video. Apparently I had audacity running and that was interfering with the sound earlier. Dumb ass attack on my part…sorry.
Ha! Man, I must have been tired last night. It wasn’t audacity interfering it was audacious. I was listening to music at the same time that I was fiddling with mencoder.
Yes, I still get syncing issues. I think the audio is on cue…it’s the video that plays slightly faster. I didn’t notice any output errors in my terminal after the encode either. Of course I might have been distracted by my daughter cart-wheeling all last night…Daddy? Whatch this…Daddy? Watch this…Daddy? Watch this…:)
Well, if your daughter has a good time, who cares about encoding 😉
I checked with a chunk of 5 minutes (XviD and MP3 in AVI container so different than the format of your screen recording) on my system and I did not experience sync issues in the final MP4 film. Is the video slowly getting more and more out of sync or is there an initial delay/advance which is constant during the rest of the film? Which media player has problems or do they all show sync problems?
Options which could help: -vf harddup, -mc 0, -ofps , -noskip
Did you notice that 21 fps? Odd isn’t it? I can control the a/v sync by changing this frame rate. Too high of a frame rate (25 or 30) and the video speeds up. Too low of a frame rate (15, 20) and the video slows down like slow motion. 21 fps seems to be the sweet spot.
I converted episode ep034-1.avi to mp4 with the above script and it plays great in smplayer and vlc. If you get a chance to, maybe you can download the same episode and run the above script back to convert it. Hopefully you can let me know how it plays for you. This might be the answer to how Richard and I could convert our avi’s to mp4’s in the future.
Indeed, audio and video were out of sync due to lots of duplicate frames. Then I added -vf harddup and the video worked fine (!) both in MPlayer, Totem with Gstreamer backend and FlowPlayer (a Flash media player) in the browser window. Adding -mc 0 or -ofps 21 did not make a difference: the video stayed in sync.
Unfortunately is VLC on my system broken. There are issues with the latest FFmpeg and those will not be resolved until version 0.9 of VLC. That is really a pity now. Audio works however, and I noticed in View -> Stream and Media Info that VLC thinks that the audio bit rate is 705 kb/s which is way to high. When I use the original AVI file, it shows the correct 128 kb/s. Adding abitrate=128 to -lavcopts or something like -af channels=1 did not help. VLC shows also that the AAC audio file has the SBR extension but as far as I know that should not be a problem.
What can I say? I am puzzled by -ofps 21. How did you find this out by the way? It does not make any sense to me and I think we are looking at an artefact. Is it needed only for VLC or also for smplayer and Quicktime? Are there differences in the messages that VLC shows in View -> Messages depending on whether -ofps is or is not used? Does aglobal=3 and vglobal=3 help?
Conclusion: it seems safe to say that your script works although I am not totally comfortable with that -ofps 21. I wonder what happens if you use the original Theora files of recordmydesktop.
I wasn’t really happy about that 21 fps switch either. Seemed like a half-assed way to go about it. Just supplying the -vf harddup switch is the answer. I swear I tried that last night but maybe I didn’t.
Nevertheless, I think you have it all figured out for me. I’ll run your script back on a few other episodes and check for errors.
This gives me a good foundation to work with. I’m not sure if it makes sense to continue encoding in the avi format and then convert to mp4 or just go straight to mp4. It’s easier to work with the avi’s in terms of adding our intro and Richard’s “speedcasts”. Joining mp4’s is still a mystery to me.
I think what I’ll do is offer up some mp4 samples for our viewers to download. Best way I know to find out how the video plays on all kinds of computers. 😉
No problem, even the Flash media player played the resulting MP4 fine in the browser window. But I would avoid a lot of transcoding. It will hurt quality. Maybe it is better to use the original files (AVI, Theora) and concatenate those at once in the final MP4 video.
And now for something completely different. I just now noticed that the size of the video is 800×600. For optimal compression dimensions which are a multiple of 16, are to be preferred. In this case 768×576 for example which has the same aspect ratio as 800×600. It is not a big deal but will help to reduce size and avoid compression artefacts.
Sweet! I’ll have to try that. I have to get some things out of the way this morning so hopefully I can try it soon. This is why I love mencoder. Just when I think something won’t work I get a surprise in the end.
I’m thinking if I just hold out long enough you’ll make Inkscape tutorials too. 😛
Yes, I am fully aware of the 800×600, divisible by 16 thing. We had a perfect reason for choosing that resolution when we first started. I forget now. Actually, I would like to go bigger and not smaller. This was something that I was going to tackle when Inkscape 0.46 was officially released. The application dimensions will change so I will be forced to do something about it. It’s important for us to stay absolutely consistent no matter the video scale that we choose. If compression suffers a little then it’s just a minor thing. It’s very important then when you screencast that your application window (Inkscape) is identical or close to the dimensions or resolution of your final video. So for instance, if our Inkscape window size is 800×600 and we output to 800×600 video then the video will be crisp. You’ll notice that some of my opensuse/Inkscape screencast are sometimes a little blurry. That is because I cannot get an 800×600 application window. I get something more like 865×649 in KDE 3.5.7. In WinXP I can get an Inkscape window of 800×600 and that’s why my final video looks so sharp. There is no scaling needed on my WinXp machine. (I would rather screencast in Linux because I get better sound than I do in Windows)
Great set of comments here. This has been pretty valuable information. I really appreciate your efforts, Serge. I definitely owe you a beer or two. By the way, where th hell were you when we first started?
Making tutorials, well, who knows. I like computer graphics very much but most of the time I spend now on photo retouch/post processing. I wish I had more time to explore other areas in more depth. Fortunately thanks to your tutorials at least vector graphics gets a boost.
Where was I? You started at the end of 2006 which by very coincidence is the time when I launched my site and had my fair share of Encoding Hell. Very probably I would not have been much of help at that time. Bit by bit I acquired some knowledge of codecs and formats since then. A lot of time I have spent by experimenting with the endless amount of options. But in the end it has earned me a couple of beers, so I can’t complain. 😉
Never ever use -mc 0 NEVER. -mc 0 completely disables the A/V sync of MEncoder so you could be screwed in the end. Further, Serge was talking about global headers, those are the SPS and PPS headers which need to be at the beginning of a MP4 H.264 video stream if you are producing video for streaming. Also, someone was talking about QuickTime not fully supporting High profile, I don’t know that but High profile has nothing to do with how many B-Frames one can use or not use. Profiles are there to indicate which H.264 features are allowed to be used. For example, the difference between High and Main profile is only 8x8dct which is not allowed in Main profile – you can use up to 16 B-Frames in High and Main. H.264 Levels are there to restric resolutions and bitrate/buffer requirements and frame sizes 🙂
Ah, great to get some input from you, microchip. For those who don’t know, microchip is the one who helped us figure out how to encode our current avi’s and flv’s last year. He’s pretty much an authority on video/audio encoding. I take his advice seriously. 😉
Thanks for the tip on “-mc 0”. Luckily it’s not part of the mp4 scripts that we settle on. Serge figured out what it took to make them work in the end. I really appreciated his help.
If and when Richard and I are ready to go mp4 maybe I can bother you with another round of questions. Your input was important to me in the past. Maybe I can get Serge to jump in too. Even though Richard and I have been producing screencasts for a while now, we still could use some education in regard to video encoding.
“In WinXP I can get an Inkscape window of 800×600 and that’s why my final video looks so sharp. There is no scaling needed on my WinXp machine. (I would rather screencast in Linux because I get better sound than I do in Windows)”
Per chance was this screencst done in WinXP. I’m getting a horrible background hum throughout this, and only this, screencast. I too, would prefer a slightly blurry video than a humming noise, if that’s the case. Thanks for your screencasts.
Yup, I know exactly what you mean. I hear the hum too. Unfortunately I had broken my Logitech USB mic that I used on my WinXP machine. Had to use my old pedistal mic (euphemism for super shitty microphone) which picks up a lot of noise. Since the original sound was quiet I had to increase the sound level by nearly 200% for this episode. So basically, I had to play some games with the audio. It’s possible that I could have toned that down a little in audacity. I had another Logitech USB mic but I didn’t have it in my procession at the time of the recording. Can’t say it won’t happen again but at least I know what causes it. 😉
Maybe I can get Richard to help adjust the sound and re-upload it to the site. Matter of fact, let us work on it. When it’s done I’ll post back here.
I’m using .48 now and things just seem a little wonky. When I try to do a gradient in the fill, I still get the right angle instead of a straight line so I can’t make it change like you say to do. I’m a first timer with Inkscape so please be patient with me !
Is it because you are using a radial gradient where you should be using a linear gradient? If you are having trouble with a particular step in the video then can you give me a time stamp so I know where to go? For instance, if you go to the 5:00 mark you’ll see that I have the linear gradient switch check in the upper left hand corner.
By the way, I no longer apply gradients this way…like I did in this video. Now I apply gradients directly to the object by selecting the gradient tool and double-clicking an object. It’s much easier and faster. 😉