andy vt's tools & blog

http://www.megaupload.com/?d=5UJ58HH3 (Version 11 is the latest version, please go to page 22 of this thread to see information about version 11: Here is the download link - http://babgvant.com/files/folders/misc/entry4003.aspx)

Above is a link to a version of MEncoder that can now read dvr-ms files natively.  A really BIG thank you goes to John Donaghy for all the hours he spent looking through Hex dumps, reverse engineering the dvr-ms format.  John put in a lot of time and deserves all the credit for making this happen.

We have this latest version working pretty well; however, I need to mention the demuxer options.  First, you could use the standard MPlayer demuxer.  However, we really struggled getting this thing debugged (we just couldn't get the AV to stay in sync).  As a result, John approached some ffmpeg developers he knew and they added DVR-MS support to the ffmpeg demuxer.  To use the ffmpeg demuxer in MPlayer/MEncoder you need to use the "-demuxer 35" switch.  You could test both demuxer's, however, I highly recommend you use the ffmpeg demuxer.

My goal for this project is to get MEncoder working well with dvr-ms files, then compiling it as a dll and integrating it into Dtb.  However, we could really use some help (this project is VERY time consuming).  If you would like to help, below are some things we could really use help with.

1) First, please just try converting different dvr-ms samples you may have. We tested with our samples, however, there are so many variations that can happen (especially with HD shows), we could mostly use help just testing with a variety of shows to make sure we are reading the dvr-ms format correctly.

2) Setup ShowAnalyzer to output MPlayer files (EDL files) as well as the Dtb XML files. Then use the -edl switch when calling Mencoder to test the automatic skipping of commercials while encoding. This process should be more efficient than today's process. Today Dtb creates a new dvr-ms file without the commercials before encoding.

3) **this is resolved, see post below**Figure out the best command line options for encoding (I included the man page in the zip file). There are so many options we can't possible support all of them when we integrate this into Dtb. We really need to know what works best. Also, you will notice below that I'm using a different command line to encode wide screen shows. I'm sure there is a way to only use one command line for both aspect ratios; however, I haven't taken the time to figure it out. If someone spent the time to look into all of this, it would really help. Below are the two command lines I'm currently using.

4:3 aspect ratio shows:

MEncoder -demuxer 35 "D:\Recorded TV\%~n1.dvr-ms" -quiet -vf scale=320:240,pp=lb -ofps 29.97 -ovc xvid  -xvidencopts fixed_quant=4 -oac mp3lame -lameopts abr:br=120 -o "D:\Xvid\%~n1.avi"

16:9 aspect ratio:

MEncoder -demuxer 35 "D:\Recorded TV\%~n1.dvr-ms" -quiet -vf scale=320:176,pp=lb -ofps 29.97 -ovc xvid  -xvidencopts fixed_quant=4 -oac mp3lame -lameopts abr:br=120 -o "D:\Xvid\%~n1.avi"

4) If anyone has experience with AAC sound and H.264 video I would like to hear from you. MPlayer has the ability to encode with AAC/H.264 however I don't have any experience with this (and no way to test it) so I'm not sure if it's working. More than likely I didn't compile the AAC and H.264 libraries correctly (compiling Linux libraries in Windows is a pain). So, if someone can test AAC and H.264 please let me know. I'd like to work with you to make sure I have the libraries working correctly.

One final thing I wanted to mention.  If you try to use this executable with Dtb, you will need to use the -quiet switch.

Thank you for any help you can provide.

Awesome, I'll try it out immediately and post my results and experiences!

Any chance to get Early Access in return for helping with this? I'd really like to get 1.2.0.4 now that it's out...

Edit:

I tried it out with the latest Survivor episode (HDTV 16:9), I used a file where commercials had been cut out with Dtb. I used the command line from above (for 16:9) but without the -quiet so that I can see what's going on. Here parts of the log:

MEncoder dev-SVN-r22200-3.4.4 (C) 2000-2006 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
success: format: 0 data: 0x0 - 0x95f51fbd
libavformat file format detected.
VIDEO: [DVR ] 1920x1080 0bpp 0.083 fps 18800.0 kbps (2294.9 kbyte/s)
[V] filefmt:35 fourcc:0x20525644 size:1920x1080 fps: 0.08 ftime:=12.0000
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
xvid: using library version 1.1.2 (build xvid-1.1.2)
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [pp=lb]
Opening video filter: [scale w=320 h=176]
==========================================================================
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
MP3 audio selected.
Writing header...
ODML: Aspect information not (yet?) available or unspecified, not writing vprp header.

[... many many repetitions of the last two lines cut out ...]

Pos: 129.0s      2f ( 0%)  0.09fps Trem: 277min  71mb  A-V:1.200 [0:117]
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.
Pos: 129.0s      3f ( 0%)  0.14fps Trem: 277min  71mb  A-V:2.367 [0:117]
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.
Writing header...

[... some more repetitions cut out ...]

VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
videocodec: XviD (320x176 fourcc=44495658 [XVID])
xvid: par=0/0 (vga11), displayed=320x180, sampled=320x176
xvid: Fixed Quant Rate Control -- quantizer=4/1=4.00
Writing header...
ODML: vprp aspect is 16:9.
Writing header...

It seems to me as if the beginning of the file (where the commercials that were still there before the actual show started) is "dirty" and MEncoder can't determine the aspect ratio correctly. Then at some point it seems to be picking up the 1080i resolution, but that also seems to go on and off. I didn't let it finish but aborted, the resulting video file showed the first frame of the video and then froze, but audio was there and sounded fine.

I will start playing around with the command line options and try it also with an unprocessed file (that still has commercials in it), maybe that will lead to better results.

One more edit:
I forgot to cut & paste the error log as well. There are lots and lots of error messages, most of them repeat over and over again. Here the beginning of the error log:

Using SSE optimized IMDCT transform
Using MMX optimized resampler
3508 duplicate frame(s)!
Too many video packets in the buffer: (124 in 8489342 bytes).
Too many video packets in the buffer: (124 in 8489342 bytes).
Too many video packets in the buffer: (124 in 8489342 bytes).
359 duplicate frame(s)!
Too many video packets in the buffer: (123 in 8447233 bytes).
Too many video packets in the buffer: (122 in 8425911 bytes).
3 duplicate frame(s)!
Too many video packets in the buffer: (122 in 8436399 bytes).
Too many video packets in the buffer: (122 in 8436399 bytes).
Too many video packets in the buffer: (122 in 8436399 bytes).
SwScaler: reducing / aligning filtersize 25 -> 24
SwScaler: reducing / aligning filtersize 25 -> 24
SwScaler: reducing / aligning filtersize 26 -> 25
SwScaler: reducing / aligning filtersize 26 -> 25
[swscaler @ 0xad3f00]SwScaler: BICUBIC scaler, from yuv420p to yuv420p using MMX2
[swscaler @ 0xad3f00]SwScaler: using n-tap MMX scaler for horizontal luminance scaling
[swscaler @ 0xad3f00]SwScaler: using n-tap MMX scaler for horizontal chrominance scaling
[swscaler @ 0xad3f00]SwScaler: using n-tap MMX scaler for vertical scaling (YV12 like)
[swscaler @ 0xad3f00]SwScaler: 1920x1080 -> 320x176
359 duplicate frame(s)!
Too many video packets in the buffer: (121 in 8395394 bytes).
Too many video packets in the buffer: (121 in 8416370 bytes).
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
3 duplicate frame(s)!

Update will follow.

Did another test with the X-Men 2 movie (this time 720p, the Survivor episode I tested before was 1080i), a lot of the messages looked the same as before, but this time the resulting video was actually playable, that is there was a picture with the audio.

However, the result was still unusable, the audio is normal like with Survivor, but the video is completely out of sync (yes I am using -demuxer 35), and not just seconds, but the video framerate looks like it is around 12 fps with audio running at normal speed. Also, the quality of the video is pretty bad, which I assume comes from the -vf scale with very low resolution.

I usually prefer using the bitrate=<value> option for xvid encoding, since it allows easily setting the file size of the resulting file to a fixed value, and then the encoder will determine the bitrate etc. Also, I prefer two-pass encoding, but I guess it really depends on how fast you want the encoding to be and what kind of quality the output should have. However, if I encode 1080i or 720p into xvid, obviously I want to preserve as much of the HD quality as possible.

Also, one thing I didn't mention before, all my testing is done on Vista. I don't have an XP machine to try and see which errors and messages might be Vista related.

Legend:

Did another test with the X-Men 2 movie (this time 720p, the Survivor episode I tested before was 1080i), a lot of the messages looked the same as before, but this time the resulting video was actually playable, that is there was a picture with the audio.

However, the result was still unusable, the audio is normal like with Survivor, but the video is completely out of sync (yes I am using -demuxer 35), and not just seconds, but the video framerate looks like it is around 12 fps with audio running at normal speed. Also, the quality of the video is pretty bad, which I assume comes from the -vf scale with very low resolution.

Thank you for testing, this is exactly the help we needed!  You are correct, the video is very low resolution because I was using the -vf scale switch.  I was encoding the show for a portable device (320x240 screen).  If you want to encode for playback on your PC then remove the -vf switch and you will get full resolution.  Is there any chance you could upload those two shows to www.megaupload.com?  They only allow you to upload 500mb at a time, so you have to use WinRAR to split the show into 500mb chunks.  After you upload it, can you post all the download links and the command line you were using to encode?

Legend:

 Also, one thing I didn't mention before, all my testing is done on Vista. I don't have an XP machine to try and see which errors and messages might be Vista related.

Vista won't matter...  I've performed testing on both XP and Vista and it works fine on either machine.  Did you have any success?  If not, that would be really surprising.  I’ve tested this with A LOT of HD shows and It work for all of my shows now.

 Again, thanks for testing, I’ll look forward to seeing your samples.

Legend:

I tried it out with the latest Survivor episode (HDTV 16:9), I used a file where commercials had been cut out with Dtb. I used the command line from above (for 16:9) but without the -quiet so that I can see what's going on. Here parts of the log:

MEncoder dev-SVN-r22200-3.4.4 (C) 2000-2006 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
success: format: 0 data: 0x0 - 0x95f51fbd
libavformat file format detected.
VIDEO: [DVR ] 1920x1080 0bpp 0.083 fps 18800.0 kbps (2294.9 kbyte/s)
[V] filefmt:35 fourcc:0x20525644 size:1920x1080 fps: 0.08 ftime:=12.0000

The last two lines above are really bad.  Notice it detected the fps as 0.083.  This is going to cause your AV sync issue.  It should correctly detect the fps.  I really need to see this sample.

 Edit:

If you would rather share the file via P2P, that will also work for me.  Just post the Torrent file and I'll download it using P2P.

Thanks for the feedback! Yes I tried a lot of other switches, especially for resolution and framerate, but was unable to get the fps issue fixed. I also tried using x264 and libavcodec, but I think you already mentioned that those weren't compiled into this build of mencoder, so that didn't get me very far.

Regarding uploading my samples somewhere, torrent is definitely the easier way, but with my cable modem upstream speed it will take a while to get the 6 GB for Survivor or even more for X-Men 2 (17 GB with commercials, 13 without) through the line. However, I don't see why it shouldn't work doing the same test with for example the first 500MB of each file, the result should be the same. Also, I will record some more HD programs today and capture some shorter shows, maybe that will yield different results as well.

I'll have to set up the torrents later, I'll post again once I'm ready. Thanks!

Below is a new command line that I'm using.

mencoder -demuxer 35 -lavdopts threads=2 "Input filename.dvr-ms" -vf expand=:::::4/3,scale=320:240 -ofps 29.97 -ovc xvid  -xvidencopts fixed_quant=4:threads=2 -oac mp3lame -lameopts abr:br=128 -o "Output filename.avi"

First, if you don't have a dual core, or HT, system, please don't use the two options threads=2.  These two options allow the decoding, and encoding to happen on both cores (in the case of a dual core system).

Second, the -vf expand=:::::4/3,scale=320:240 option allows us to use one command line for both 4/3 and 16/9 shows.  The first part "expand=:::::4/3" looks to see if the show is 4/3 aspect ratio.  If it isn't it adds the black bars on the top and bottom to make it 4/3.  The second part "scale=320:240" resizes the video.  I'm using these numbers because I encode to Xvid so I can watch shows on my portable device.  It has a 4/3 aspect ratio screen with a 320x240 resolution.  If your portible device has a wide screen, you could add the black bars to 4/3 contect by using the option "expand=:::::16/9".  Of course, if you don't want to adjust the aspect ratio, or the size of the video remove this whole option.

 Lastly, I've fixed a few more bugs I found, and I think I have AAC and H.264 working.  I want to perform some more testing before I post it, so you should see it in a day or two.  I haven't been able to work on the fps problem Legend reported because I don't see that error with any of my shows (and I've tested with a lot of HD shows).  If anyone is experiencing the same error, I would really appreciate an example.

onlydarksets:

I had the fps problem with (don't laugh) Rules of Engagement.  I don't know how to seed a torrent, so I guess I'll try to cut it up and upload it to Megaupload.

Was this a HD show?  If so, are you using ATSC, or was this firewire?  The reason I'm asking is because I've tested with the two Rules of Engagement shows that have aired and I didn't have any issues.  According to my show it was broadcast at 29.97 fps.  Can you try setting the fps manually with the -fps switch.  I've looked at quite a lot of HD shows and they seem to be either 29.97, 30, or 50 fps.

Legend:

Sorry for the long delay, I was sick for almost three days and could not continue my testing. In the meantime my MCE recorded a couple of other shows from different channels, so I will conduct a few more tests and post my results here before publishing a dvr-ms file. Hopefully I'll get better results than before!

I hope you feel better...

Before you and onlydarksets upload a 6GB file, one thing you can try is to use DVREdit to create a sample of the show under 500mb.  This will be much easier to upload (megaupload's limit is 500mb so you wouldn't have split up the file) .  Of course, before you upload it please test the conversion to make sure the small sample still has the fps issue (the issue might be in the header of the file which will be re-written when DVREdit recreates the new file).

So I did some more testing with the newest Survivor episode as well as some Comedy show I recorded the other night. Both work fine, fps is detected correctly and the xvid conversion works properly without synch issues. Then I tried the shows again which didn't work before, and they still don't work. I think my initial assessment was correct, it seems that shows which are "dirty" cause problems.

By "dirty" I mean the following scenarios: Commercials or another show in a different format before the actual show, so that the stream starts in a different format than that of the actual show. This shouldn't really cause problems for mplayer/mencoder, as I would imagine it should be able to detect the fps/resolution change and adjust accordingly, but somehow that doesn't seem to be the case. Instead it reports back a wrong fps.

Jelwood, I also still really don't like your command line arguments, most obviously because we have two very different target platforms. You want a nice small size for your 320x240 resolution, I instead want a high quality stream that conserves as much as possible of the original HD resolution and quality, but that plays nicely on my Xbox (which unmodified DVR-MS doesn't do at this point). But even when leaving the quality difference aside, your 4/3 letterboxing produces black bars on all sides in my case. For example: I recorded Suvivor in HD, the show is actually aired in 4:3 but recorded in 16:9, so it already has black bars at the left and right. Now with your command line it thinks the recoding is 16:9 and adds black bars at the top and bottom to make it 4:3 again. As a result you lose a lot of real estate to display something that was 4:3 to begin with. Eventually I think you would need something like most converters offer, which skips through some frames in the file and figures out the best crop/resolution values automatically.

The build of mencoder you have does not seem to be a svn build, is that code checked into the svn repository for mplayer/mencoder yet? I've played around with the latest mplayer/mencoder svn builds from Celtic Druid, but they don't seem to contain any dvr-ms capabilities yet, even though the build is from 2/14.

The question now is: Would you like the beginning of one of those "dirty" files I have? I think even if I give you the first 50MB it should be reproducible already. Just let me know, and I'll make it available for you.

Legend:

By "dirty" I mean the following scenarios: Commercials or another show in a different format before the actual show, so that the stream starts in a different format than that of the actual show. This shouldn't really cause problems for mplayer/mencoder, as I would imagine it should be able to detect the fps/resolution change and adjust accordingly, but somehow that doesn't seem to be the case. Instead it reports back a wrong fps.

You are correct, we tried to make mencoder change the fps rate, but obviously this isn't working correctly. 

Legend:

Jelwood, I also still really don't like your command line arguments, most obviously because we have two very different target platforms. You want a nice small size for your 320x240 resolution, I instead want a high quality stream that conserves as much as possible of the original HD resolution and quality, but that plays nicely on my Xbox (which unmodified DVR-MS doesn't do at this point). But even when leaving the quality difference aside, your 4/3 letterboxing produces black bars on all sides in my case. For example: I recorded Suvivor in HD, the show is actually aired in 4:3 but recorded in 16:9, so it already has black bars at the left and right. Now with your command line it thinks the recoding is 16:9 and adds black bars at the top and bottom to make it 4:3 again. As a result you lose a lot of real estate to display something that was 4:3 to begin with. Eventually I think you would need something like most converters offer, which skips through some frames in the file and figures out the best crop/resolution values automatically.

Wow, I didn't think about shows that are 4:3 but broadcast 16:9.  Can you point me to an application that "skips through some frames in the file and figures out the best crop/resolution values automatically"?  I'd really like to see how they are doing this.  You can do this manually by using the crop/zoom feature in MEncoder, but automatically determining when there are black bars to remove may be above my skills. 

Regarding the command line.  Maybe there are too many options to integrate this into Dtb.  I'll keep thinking about it, but it may be best to just keep it an executable that you can call from Dtb.

Legend:

The build of mencoder you have does not seem to be a svn build, is that code checked into the svn repository for mplayer/mencoder yet? I've played around with the latest mplayer/mencoder svn builds from Celtic Druid, but they don't seem to contain any dvr-ms capabilities yet, even though the build is from 2/14.

You are correct, it isn't a svn build.  We've submitted the changes to the ffmpeg and MPlayer developer list, but they haven't excepted them yet.  Hopefully once we finish debugging the changes they will get accepted.

Legend:

The question now is: Would you like the beginning of one of those "dirty" files I have? I think even if I give you the first 50MB it should be reproducible already. Just let me know, and I'll make it available for you.

Yes, I would like a sample, it will really help.  Thank you for all your help!