How to create AVCHD styled media from HDV

I have a camcorder that records AVCHD (ie x264 1080p) video which I can then put on an SD card and play in my blu-ray player.  This is very handy for showing home movies to my family that I've recorded.

But what about my older HDV movies?  It is much less convenient to hook up my older HDV camera and play the digital tapes on my TV.  I'd much rather use the same SD card trick that I use with my newer camcorder.

Here's how to convert HDV videos to a format that will work on my blu-ray player (and presumably others) and also my newer camcorder.

1 - download MultiAVCHD (see http://www.afterdawn.com/guides/archive/create_avchd_and_blu-ray_discs_with_multiavchd.cfm for a guide) .  I am using build 771.

2 - Get the test program and install dependency libs/programs from this link: http://multiforum.deanbg.com/viewtopic.php?f=7&t=17

Make sure the test program is passing all its tests.

3 - from the "Settings" tab, I used all defaults (except the destination folder).  You can mess with 64-bit x264 if you are brave.

4 - click on the "media" tab and "Add Video files".  Add your .m2t files you extracted with your HDV camera.

5 - your .m2t files should show up in a window below the "Add Video Files" button.  Select them all (might have to do this one by one) and click "Transcode"

6 - Change the "Resize" drop-down in the upper right to 1920x1080 (I had to scroll down).  UPDATE: Changing the resize default of 1440x1080 may not be necessary.

7 - The bitrate for mine defaulted to about 25000, I just left it at this default.

8 - As for quality, I've tried both "1 pass Turbo" and "2 pass VHQ" and both worked.  So if you are in a hurry, use 1-pass, if you want quality, use 2 pass.

9 - click "Apply"

10 - close the "properties" dialog by clicking "ok"

11 - click "Start"

12 - a new dialog will pop up.  Choose "TV / Camcorder (NTSC / 60 Hz)"

13 - good luck!

More data on "REPEAT" command behavior

So today I pulled out a random disc from my collection and it turned out to be Cliff Hanger.  I haven't played this disc in literally 10 years so I was nervous to see how it had held up.  Fortunately, it seems to be in the same condition it was 10 years ago; no rot!

This is the first time I've captured the VBI on Cliff Hanger, and I learned (to my surprise) that all of the frame numbers are stored in the second field of each frame, which is the same "trick" that Firefox and Freedom Fighter use (although I have to admit, I have never understood what the benefit of doing this is).  So it turns out that this disc was a good test for this situation.

Again, I told it to do two passes and to stop on frame 298 (because there is where a natural break in Cliffy's attract mode is).

When it gets to the track that houses frame 298, it displays the first field (which contains no frame number).  Then it displays the VBI for the second field (which DOES have the frame number 298) and displays the first few lines of the field, and then black.  For the purposes of Dexter, I feel comfortable always displaying a completely black field in this case.

It seems pretty evident that when the frame number is read from the VBI, that the search is intended to take place ASAP and no further fields are intended to be displayed.

Now, what does it do on the second pass?

It overshoots by 1 frame every time.

So in this case, if I tell it to stop on frame 298, it will stop on frame 299.  I've tested this by telling it to stop on frames 298, 299, and 300 and it always overshoots by 1.

Next I am going to test on a disc with conventional VBI (ie the frame numbers on the first field instead of the second) and hopefully with all of this data, I will be able to come up with an algorithm for predicting whether it will stop on the requested frame over overshoot by 1.

UPDATE : Just tried Dragon's Lair 2 disc and it is organized the same way as Cliff Hanger, with the frame number appearing on the second field.  Maybe something is wrong on my end!

UPDATE #2 : Just tried Time Traveler and the frame numbers come on the first field of the frame.  The disc still overruns by 1 frame when pausing.  So it looks like the 2:3 pulldown case is an exception which I will need to study a bit more before I can predict how it will behave.

UPDATE #3 : I just went back to the 2:3 pulldown disc and noticed it is also overrunning by 1 frame, but the frame it overruns into has no frame number which is why it appears to not overrun.  So that settles it.  It will always overrun into the next track no matter what!  Now to code this up and write some unit tests...

How "REPEAT" command on LDP-1450 works (detailed)

I didn't want to do any guesswork about how the REPEAT command works on the LDP-1450 so I set up a video capture of a disc running through a REPEAT sequence, complete with VBI lines.

First I search to frame 1 (0x43 0x30 0x30 0x30 0x30 0x31 0x40).

While in STILL frame mode, I issued a REPEAT command using the following bytes:

0x44 0x30 0x30 0x33 0x00 0x00 0x40 (from current position, play til frame 300)
0x30 0x32 0x40 (play through this sequence 2 times)

What this means is:
From frame 1, play until frame 300, then seek back to frame 1, and play again until frame 300 then pause in still mode.

But there are some unanswered questions.  Will it really pause exactly on frame 300?  And when it searches back to frame 1, will we see any of frame 300 before it performs the search?

Hence the reason for me video capture.

Here is what happens:

The full frame 1 is displayed (which makes sense since it was previously STILL'd) as are all the frame up to and including frame 299.  Then the VBI data for the field where frame 300 begins is displayed (I captured it successfully) but the image itself is blanked out and a search begins.  So the actual frame 300 is never shown.

On the second pass (the final pass), it's a little different.

Not only is the full frame 300 displayed, but the disc doesn't pause until it gets to frame 301.  (this struck me as a bit odd but I verified it on a real LDP-1450 so I don't know what to say except it must be right).

UPDATE : This behavior is different depending on which frame we tell it to repeat to.  And the disc I am testing with is a 2:3 pulldown disc which seems to have an effect.  If the frame number occurs in the second field of the frame, the STILL pauses on that frame.  But if the frame number occurs in the first field of the frame, it pauses on the next frame.  At least that's what I've observed.  I guess I will need to test with some other discs.

Added some more LDP-1450 commands

In order to add support for text overlay to my LDP-1450 code, I decided to get Dexter working with Dragon's Lair 2. As it turns out, Dragon's Lair 2 sends a bunch of commands upon bootup to the LDP-1450 to make sure it is in a sane default state. I don't actually have to do any processing of these commands (like I said they just put the player into a default state which I am already in) but I do need to acknowledge them anyway. The commands I now acknowledge include: 0x62 (motor on) 0x6E (CX on) 0x27 (video on) 0x28 (picture stop code enable) 0x55 (frame mode) 0x24 (audio on) Dragon's Lair 2 also issues a 0x67 (status inquiry) command which I do not have documentation for. I confirmed (by using my real LDP-1450) that when the player is playing, it will return 0x80 0x00 0x10 0x00 0x01 and when the player is paused (still frame mode) it will return 0x80 0x00 0x10 0x00 0x20. I can't think of what other state the player possibly could be in except maybe in the middle of a search and playing backward or at a different speed. I am not sure how much I need to explore this since DL2 probably just wants to know if the disc is playing or paused and other games probably don't care at all. I guess this is one thing I can leave barely implemented for now and add richer support for later if it becomes required. After adding the bare bones status inquiry response, I can get wookin' on the text overlay stuff.

Dexter can now emulate a Sony LDP-1450!

I've been working hard (lately) on adding support for players that use a serial interface and the first one I decided to tackle was the Sony LDP-1450 (and 1000A).


I haven't quite finished with this.  The items left to be done are:
- Add support for the "repeat" command which is used in some games
- Add support for the text overlay used in Dragon's Lair 2 and Space Ace '91 (this should be fun, I am looking forward to it)

How voltage divider works

I spend a lot of time trying to figure out how a "voltage divider" works, so I've written down everything I've learned and am uploading it here.  I am using a voltage divider to hook the Dexter board up to the Raspberry Pi so this info is relevant to Dexter.

Worked on serial I/O over the weekend, verified LDP-1450 command

I improved the serial I/O code over the weekend for Dexter and optimized it a bit more.  I also plugged in my real LDP-1450 to my PC and wrote a small "game" driver to talk to it.  My main purpose was to test the "repeat" command on the 1450 to see if it behaved similarly as it does on the LDP-1000A (which I do not have).  I did indeed verify that the "repeat" command seems to be identical on the 1450 as it is on the 1000A.  I also discovered that the 1450 won't work correctly if DTR is disabled.  I am trying to move in the direction of adding support to Dexter for the 1000A/1450 players.  But "real life" stuff keeps getting in the way.  Maybe I'll have some more time over the holiday vacation coming up.