wonkablog

Well, I found a way to convert a video from variable framerate to a standard one, and it’s actually pretty simple. Not only that, I found the example about it on transcode’s wiki entry for Matroska. Obviously the last place I would have been looking for it, since I know all about those two things, right?

The wiki says to pre-process the video with mencoder, by forcing the output fps to a certain rate. The command is simply something like this:

mencoder input.vob -ofps 24000/1001 -oac copy -ovc copy -o output.avi

That’s copying the audio and video directly, but dropping frames on the segments that are not 23.97. You would think that this would drop a lot of frames, but from most cases I’ve seen so far, there are only a few segments where it jumps back to 29.97, so it turns out pretty well, and the video looks good. There’s only a few problems, though.

First of all, mencoder doesn’t (or can’t, I’m not sure yet) create an AVI index in output.avi, so you can’t seek the file at all. You have to rebuild it first:

mplayer output.avi -saveidx avi.idx

That will do two things: build the index before playing, and use it while playing. Another way to play the file later is to load the index while playing the file:

mplayer output.avi -loadidx avi.idx

Then you can seek again.

The second problem is that it’s visibly noticable that you are dropping frames. On playback there are weird black blocks that show up when you do any kind of seeking. A small pain, I know, but that’s the price you pay. It’s really not that annoying, actually. My bigger concern is the index.

I’m playing with ways to get both fixed at once, and I’m hoping that transcode will either re-index the AVI and/or cleanup the funky blocks. Now that the video is all the same framerate, at the very least it won’t have any A/V sync issues. That’s the great part.

Another option is to get mencoder to somehow rebuild the index, but I’m going to have to do some research to find out that stuff. While I started on that though, I did find this great documentation on how to deal with progressive framerate video. Essentially, it looks like I’m on the right track. The bummer part is that there’s a little more to it than I thought, and I might have to do research for each TV series to see how they are encoded, as far as telecine and interlacing goes.

Either way, all this research boils down to one simple principle that I keep harping on: there’s really no solution that is going to work for every video you throw at it. You can come close, of course, with some generic encoding options that will fix 90% of what you have and make it viewable. But if you want best results, smallest filesize, and cleanest video, you’re just going to have to do some research. Personally, I think it’s worth it.

I’ve been very cautious about posting any progress reports about my transcoding adventures, because the arguments I use keep changing while I test things. In fact, I deleted the last two posts about transcode because I later proved myself to be completely wrong.

I have, however, found some settings when it comes to cartoons that has worked well on everything I’ve thrown at it so far, minus one. The only exception was Roger Ramjet, where I do a two-pass on it because it looks better.

Cartoon DVDs are the worst culprits of trying to encode video though. All the DVDs are variable framerate or 23.97 fps or detected incorrectly, and with some being so old, it’s easy to get visual artifacts if you’re not careful. Here’s what I’ve been using though:

transcode -x vob,vob –hard_fps -M 2 -R 3 -w 2 -B 3,9,16 -y xvid -A -N 0×2000 -a 0 -b 128,0,0 –write_pid transcode.pid -f 0,4 –export_frc 1 -J ivtc -J decimate -J 32detect=force_mode=5:chromathres=2:chromadi=9 -i $1 -o cartoon.avi

Ninety percent of that is from the framerate.txt doc that comes with the transcode page. The only thing that I added myself was to copy over the Dolby Digital audio tracks instead of encoding them to MP3, and then I added –write-pid which obviously isn’t going to affect anything.

If you look at the man page (which is very nicely laid out, btw) and lookup each argument I’m using, you’ll see what I’m doing here. If you don’t feel like it, I’ll cover it briefly.

Basically I’m forcing transcode to read it at 29.97 frames per second, but forcing it to export it to 23.97 instead. It sounds strange to specifically set those, I know, but doing just that won’t save your skin. It’s the filters I’m using as well that fix the framerate and deinterlace the video that fix it up as well and make it all clean and pretty. And even better, the audio and video are in sync — which, by the way, is really hard to look for on a cartoon.

Everytime I tried to do two passes on any cartoon, it really made it look nasty. The lines would be blurry, and it just looked low quality overall. Using this one pass makes them all look pretty darn nice.

One other magic trick that I do is I tell XviD to encode it as a cartoon. From what I’ve read, and seen, doing this increases the quality a little bit. To do that, just install xvid4conf, and save a vanilla file to ~/.transcode/xvid4.cfg. Then, just copy that to the directory where your ripped DVD’s VOB files are at, and edit it so that cartoon = 1. If you’re feeling lazy, here’s how to do it with sed: sed –in-place -e s/cartoon\ =\ 0/cartoon\ =\ 1/ xvid4.cfg

Once you’re ready, go ahead and encode it with transcode. I must say, I like the results that I’ve gotten every time. And for me not to complain … well, you know that’s a step in the right direction, since I’m super picky.

Encoding live action shows is a completely different beast altogether. Essentially, there is no magic bullet, but I’ll cover that in a later post. I’m cautiously optimistic about these settings though, at least for cartoons, and would tenatively recommend them for now.

Will the mythtv saga ever end? Will Steve ever be happy? Isn’t that way too many Twinkies in your cupboard? In answer to all three … probably not.

I have this strange little psychological tick that turns on anytime I encode video from a professionally formatted source (basically anything I didn’t make myself). I always think I can see that the A/V is out of sync. In reality, I can’t tell if it is or not. But after staring at people’s lips for a few hours straight, you’ll probably start to believe anything.

There actually is one legitimate problem though, and I know I’ve encountered these issues a long time ago and decided on using what I am now (transcode over ffmpeg / mencoder, an “fps” flag in the database, etc.) but for the life of me I can’t remember why.

The problem is that DVDs come in three different framerates: 29.97, 23.97 and a mix between the two. To handle the matter, I’ve got a trinary flag in the database. The default value will let transcode decide how to process the framerate. In most cases, that works just fine for me. Most DVDs are either 29.97 fps, or start off for a second or two in 23.97 and then switch to 29.97 for good.

Then there are my good friends that just switch back and forth between scenes from one framerate to the other — variable framerate. I know it sounds crazy, so here’s an example:

Starting playback...
VDec: vo config request - 720 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO: [xv] 720x480 => 720x540 Planar YV12
A:  44.8 V:  44.8 A-V: -0.007 ct:  0.076  16/ 13 ??% ??% ??,?% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:  62.3 V:  62.3 A-V: -0.002 ct:  0.296 203/200 11%  0%  2.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]    2.0% 0 0
A:  62.7 V:  62.7 A-V:  0.024 ct:  0.325 215/210 11%  0%  2.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:  63.9 V:  63.9 A-V:  0.009 ct:  0.386 246/240 11%  0%  2.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]    2.0% 0 0
A:  64.4 V:  64.4 A-V:  0.038 ct:  0.421 261/253 10%  0%  1.9% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:  74.3 V:  74.3 A-V:  0.013 ct:  0.182 672/664 11%  1%  4.5% 0 0
Exiting... (Quit)

Now, I can’t remember what I used to do about this problem. I think I used to force transcode to save the new file to 23.97 frames per second. I’d rather drop some frames on the 29.97 than try to stretch out the other ones, after all. Testing this stuff isn’t easy though. You have to stare at a lot of lips and try and convince yourself that you really can see a difference of a few milliseconds.

To solve my little problem (or to put my mind to rest, whichever’s easiest), I have three ideas:

1. Tell mplayer to fix the a/v sync on playback

MPlayer has an “autosync” feature (see the man page) that you can use to tweak how often it looks to see if the audio is delayed. I tried flipping it on on one pass, and I thought I could see an improvement (although, it was a cartoon so who knows if the lip sync was ever correct in the first place), and then I tried it while watching a live-action show with it turned on, and it seemed like the sync was off. So, who knows. One thing I’ve learned from all of this is that it’s not likely there’s going to be a setting that will work for every scenario.

2. Use some funky transcode flags

In transcode’s docs directory, theres a framerate.txt file that talks just about adjusting framerates. It even mentions the exact problem I’m running into … “Some video sources are not of constant framerate. This is mostly true for Anime and some DVD Releases of TV series.” Doh!

They then have this huge example using flags I’ve never even read up on before, so that seems kinda scary. There is one, though, that I noticed in the man page, –hard-fps, which will “disable smooth dropping (for variable fps clips)” and is off by default. That might be my ticket, too.

3. Don’t do anything

There’s always the exciting option of assuming that the developers of these multimedia applications are just a twinge more genius than I am, and that by using the defaults on everything, that things might just turn out fine. I’m not sure where the fun is in that, though.

When I’m encoding more than a thousand episodes of TV shows ranging from 6 to 60 minutes in length, I have a tendency to be a little picky. Eventually though, I’m sure I’ll just settle in and start watching the shows and not even realize that it’s transcoded from the original and that the A/V is off by 3/1000th of a second. And hopefully I’ll forget all about their lips, too.

Man, I’m stoked.

I spent all weekend repairing my MythTV box (which, btw, I have a lot of issues with the project as a whole … but that’s another post), and I finally got it to where I want it — working partially. Anyway, I just started playing around with mencoder to see how hard it would be to convert these files to something other than mythtv’s special nuv format (must … contain … rant…), and it actually turned out to be spectacularly simple. All I really have to do is just re-encode them so the AVI index is rebuilt.

The really cool part is coming up next though. I wanted to strip out the commercials myself, and at first I started thinking of how I could do that with mythtv’s commercial flagging. After all, it does just store the cutlist in the database, right? For the record: yes, it does, its in the recordedmarkup table, which took me a while to find out. Well, after my average research time of 2 seconds, I couldn’t find an easy intuitive way to use that to tell mencoder when to cut the video into pieces. I had heard of avidemux before, but last time I tried it (back when I was using Mandrake … eek. Nothing wrong with MDK, that was just a loooong time ago), it only crashed and burned horribly. I figured this was a good a time as any to give it a swirl.

And man, it works great. There’s this great feature it has “skip to next black frame” which pretty much finds the commercials for you. Then just set marker A and B at the start and stop of each break, cut it, and save the file and you’re done! All you need is about 15 minutes each to re-encode each NUV and then maybe 2 minutes to manually cut them, but you’ve got a great perfect looking pristine TV episode. Sweet.

I should mention that I already know about nuvexport, but I’ve never had much luck with that either. If anyone’s interested, here’s a raw howto I actually got this far:

1. Set mythtv to keep original recordings (they’ll be saved as foo.nuv.old) or just don’t transcode at all
2. Reencode from an MPEG4 NuppelVideo to an MPEG4 AVI, video only: mencoder foo.nuv.old -ovc lavc -oac copy
3. Run avidemux2 on the AVI, cut out commercials and reencode the audio to mp3 (usually PCM audio works too, but sometimes it gets scratchy).

My little dvd2mkv script is coming along. You can actually pop in a DVD, run the script and come back a few hours later and you’ll have a nice shiny Matroska file complete with chapters and all. I’m actually pretty proud of it, even though there is still a lot of bugs, and you can’t do the main feature I wanted yet, which is to queue movies.

The good thing though is that it’s down to mostly fixing bugs and fixing code far more than it is adding features and just plain getting it to work. That’s a good milestone, I’d say.

One thing I like a lot about it is I’m just plain learning to write some better code. This is my first really interactive php shell script, and writing the backend, I keep finding better ways to clean it up and make the code tighter.

Just running an interactive script by itself is very cool. I was really surprised when I found out how easy it was.

The hardest part in all of this has been the transcode arguments. Actually, the first 85% or so of it was really simple, using dvd::rip as a reference and then reading up on the excellent transcode man pages. Transcode comes with some really good tools, and I still prefer it over MEncoder even though it (mplayer) would make things generally *so* much simpler. For instance, I already prefer tcprobe to midentify as getting me some really good valid data. That’s not a fair comparison, I know, since they both return different types of data. I’ll probably end up using them both. Right now I rely heavily on them both. Mplayer to rip the VOB, transcode to encode it to an XviD, and in the future tcprobe to make sure I’m doing things right.

Good stuff.