andy vt's tools & blog

jelwood:

Are you saying that you have some shows where Mencoder detects it as 59.97 fps, but it is really 25 fps?  If so, can I have a sample?

Sure, here's a 4-min sample (90 MB):

http://www.megaupload.com/?d=PW29UO3S

I'm looking forward to finding out what the root problem is with these sources!

-Hecks

Hecks:

jelwood:

Are you saying that you have some shows where Mencoder detects it as 59.97 fps, but it is really 25 fps?  If so, can I have a sample?

Sure, here's a 4-min sample (90 MB):

http://www.megaupload.com/?d=PW29UO3S

I'm looking forward to finding out what the root problem is with these sources!

-Hecks

Are you using the -demuxer 35 option?  The reason I'm asking is when the fps detection logic was added to the MPlayer demuxer it should default every show to 1000 fps and let the detection logic adjust it.  Of course, this means that you have to set you output fps for every conversion because we don't know what the real fps is, but it was the only way to solve the problem of streams that change fps.

In your sample I'm getting 1000 fps if I use the MPlayer demuxer and I'm getting 8fps if I use the -demuxer 35 option.

jelwood:

Are you using the -demuxer 35 option?  The reason I'm asking is when the fps detection logic was added to the MPlayer demuxer it should default every show to 1000 fps and let the detection logic adjust it.  Of course, this means that you have to set you output fps for every conversion because we don't know what the real fps is, but it was the only way to solve the problem of streams that change fps.

In your sample I'm getting 1000 fps if I use the MPlayer demuxer and I'm getting 8fps if I use the -demuxer 35 option.

Hmm, the plot thickens.  Using mplayer.exe, with -demuxer 35, I get this:

libavformat file format detected.
VIDEO:  [DVR ]  704x576  0bpp  25.000 fps  10000.0 kbps (1220.7 kbyte/s)

Without -demuxer 35 I get:

ASF file format detected.
VIDEO:  [DVR ]  704x480  0bpp  59.940 fps    0.0 kbps ( 0.0 kbyte/s)

The latter needs -fps 25 to play at a proper rate, although with aspect problems, but the former doesn't.   Hmm, this seems to be related to a problem I've been having with ffdshow, which I can never get to work via a graph because everything outputs at 60 fps.  Bit of a puzzle, really.

-Hecks 

Hecks:

Hmm, the plot thickens.  Using mplayer.exe, with -demuxer 35, I get this:

libavformat file format detected.
VIDEO:  [DVR ]  704x576  0bpp  25.000 fps  10000.0 kbps (1220.7 kbyte/s)

Without -demuxer 35 I get:

ASF file format detected.
VIDEO:  [DVR ]  704x480  0bpp  59.940 fps    0.0 kbps ( 0.0 kbyte/s)

The latter needs -fps 25 to play at a proper rate, although with aspect problems, but the former doesn't.   Hmm, this seems to be related to a problem I've been having with ffdshow, which I can never get to work via a graph because everything outputs at 60 fps.  Bit of a puzzle, really.

This doesn’t make sense…  What version of Mencoder are you using?  Also, please make sure you are testing this on the exact same file you uploaded to me.  If you are doing your testing on the full version, that could throw off some of the values.  Lastly, what is the exact command line you are using (I’ll try it to see if it makes a difference).

jelwood:

This doesn’t make sense…  What version of Mencoder are you using?  Also, please make sure you are testing this on the exact same file you uploaded to me.  If you are doing your testing on the full version, that could throw off some of the values.  Lastly, what is the exact command line you are using (I’ll try it to see if it makes a difference).

Sorry, that was what mplayer.exe was reporting, here are my results from both your 5a version and orc1-3.4.2 of mencoder.exe with the same sample as I uploaded:

Settings 1:
"C:\mplayer\mencoder.exe" "Input.dvr-ms" -ofps 25 -sws 2 -vf pp=md,scale=624:-2 -oac mp3lame -lameopts fast:preset=medium -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:v4mv:vbitrate=950:autoaspect -ffourcc DX50 -noodml -o "Output.avi"

With 5a, I get this:

ASF file format detected.
VIDEO:  [DVR ]  0x0  0bpp  1000.000 fps    0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:6  fourcc:0x20525644  size:0x0  fps:1000.00  ftime:=0.0010

With orc1, I get this:

ASF file format detected.
VIDEO:  [DVR ]  704x480  0bpp  59.940 fps    0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:6  fourcc:0x20525644  size:704x480  fps:59.94  ftime:=0.0167

Settings 2:
"C:\mplayer\mencoder.exe" "Input.dvr-ms" -demuxer 35 -fps 25 -ofps 25 -sws 2 -vf pp=md,scale=624:-2 -oac mp3lame -lameopts fast:preset=medium -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:v4mv:vbitrate=950:autoaspect -ffourcc DX50 -noodml -o "Output.avi"

With 5a, I get this:

libavformat file format detected.
VIDEO:  [DVR ]  704x576  0bpp  8.333 fps  10000.0 kbps (1220.7 kbyte/s)
[V] filefmt:35  fourcc:0x20525644  size:704x576  fps: 8.33  ftime:=0.1200
Input fps will be interpreted as 25.00 instead.

With orc1, I get this:

libavformat file format detected.
VIDEO:  [DVR ]  704x576  0bpp  25.000 fps  10000.0 kbps (1220.7 kbyte/s)
[V] filefmt:35  fourcc:0x20525644  size:704x576  fps:25.00  ftime:=0.0400
Input fps will be interpreted as 25.00 instead.

I was able to get good results with both settings using 5a, although I'd say that the audio synch was marginally better with the second, which is a big improvement on the problems with orc1.  Making sure that -fps and -ofps are the same is crucial to getting demuxer 35 to work, it seems.

-Hecks 

Hecks:

Sorry, that was what mplayer.exe was reporting, here are my results from both your 5a version and orc1-3.4.2 of mencoder.exe with the same sample as I uploaded:

Ok, this makes sense.  One word of warning.  The –demuxer 35 option will have issues detecting the fps, plus it will not detect AC3 sound.  All the work John and I have been doing is implemented in the MPlayer demuxer (to use the MPlayer demuxer don’t use the –demuxer 35 switch).

One last question…  I found it interesting that you think the AV sync is better with the ffmpeg demuxer (–demuxer 35 option).  Can you manually set the input fps using the MPlayer demuxer and see if it improves the AC sync?  We have logic in the MPlayer demuxer to detect the fps “on the fly” because in some HD shows the fps will change when the station switches from SD content to HD content.  Maybe we don’t have this logic working perfectly and the fps we are detecting is off just a little.

I am having audio sync issues but I am guessing its because I get dropped frames. Being a DVB-T source its always going to have missing frames etc. I am using the following code.

 mencoder -lavdopts threads=4 %filename% -delay 0.2 -vfm ffmpeg -vf pp=md,scale=704:480,harddup -ovc xvid -xvidencopts fixed_quant=2:threads=4 -ffourcc XVID -oac mp3lame -ofps 25 -o %filename%.avi

 I am about to set the audio bit rate to constant to see if that is it. Unless you think otherwise.

Also sorry for asking this if it has already been answered, but if I use the mencoder-ac3 version can I just set -oac copy to get audio preserved in what ever format it comes in?

In Australia (dont know if this is the same in other parts of the world) the audio signal changes program to program so it is very likely not only that a recording could start on stero then change ac3 but vise versa. There is also wide differences in between stations here.

jelwood:

Ok, this makes sense.  One word of warning.  The –demuxer 35 option will have issues detecting the fps, plus it will not detect AC3 sound.  All the work John and I have been doing is implemented in the MPlayer demuxer (to use the MPlayer demuxer don’t use the –demuxer 35 switch).

One last question…  I found it interesting that you think the AV sync is better with the ffmpeg demuxer (–demuxer 35 option).  Can you manually set the input fps using the MPlayer demuxer and see if it improves the AC sync?  We have logic in the MPlayer demuxer to detect the fps “on the fly” because in some HD shows the fps will change when the station switches from SD content to HD content.  Maybe we don’t have this logic working perfectly and the fps we are detecting is off just a little.

The differences only really show up at the start of the file, where the ffmpeg demuxer locks into sync earlier.  For the rest. the differences are so small that another person might not even notice.  I don't have the means right now to test more accurately, so I wouldn't take my word for it.  In any case, it's a luxury to be quibbling over these details when compared with the awfulness of synching in orc1!  Many thanks again for your work on the new build, and your help with this issue.

-Hecks 

After messing about with the -oac mp3lame vs -oac copy options (even though -oac copy didnt work) I noticed that there was a pretty bit difference in the coversion frame rate. With the -oac copy option my processing frame rate doubled. Of course there is less work to do if it is just copying the audio, but as the audio is a small part of each frame. I thought it would be worth a mention.

Maybe a lot of performance tuning could be gained from looking at the mp3lame side of things.

Command lines used where:

MP3

mencoder -lavdopts threads=4 %filename% -delay 0.2 -vfm ffmpeg -vf pp=md,scale=704:480,harddup -ovc xvid -xvidencopts fixed_quant=2:threads=4 -ffourcc XVID -oac mp3lame -lameopts cbr:br=256 -ofps 25 -o %filename%.avi

Copy

mencoder-ac3 -lavdopts threads=4 %filename% -delay 0.2 -vfm ffmpeg -vf pp=md,scale=704:480,harddup -ovc xvid -xvidencopts fixed_quant=2:threads=4 -ffourcc XVID -oac copy -ofps 25 -o %filename%.avi

Try:

 -lameopts fast:preset=medium

-Hecks 

mrknockoff:

I am having audio sync issues but I am guessing its because I get dropped frames. Being a DVB-T source its always going to have missing frames etc. I am using the following code.

 mencoder -lavdopts threads=4 %filename% -delay 0.2 -vfm ffmpeg -vf pp=md,scale=704:480,harddup -ovc xvid -xvidencopts fixed_quant=2:threads=4 -ffourcc XVID -oac mp3lame -ofps 25 -o %filename%.avi

More than likely you will get dropped frames, this isn't because of DVB-T - everyone is going to see dropped frames.  I've cleaned this up a little in my current version (it isn't released yet), but in Version 5 you will see dropped frames - don't worry, they won't be causing the AC sync issue.  What happens if you don't use the -delay 0.2?  The reason I'm asking is because we added some code that should automatically adjust the fps to keep AV sync.  However, if you use the -delay switch, this overrides our logic (when you use the -delay switch you are saying you know what the AV sync is so the code won't try to detect it).  Also, have you tried using something other than 'fixed_quant=2'?  If you need this high of quality I highly suggest you use a two pass option.  I've read some comments in the source code about problems with fixed quant values higher than 3.

mrknockoff:

Also sorry for asking this if it has already been answered, but if I use the mencoder-ac3 version can I just set -oac copy to get audio preserved in what ever format it comes in?

Sorry, but I haven't tested the -oac copy option.  I really have no idea what will happen.

mrknockoff:

In Australia (dont know if this is the same in other parts of the world) the audio signal changes program to program so it is very likely not only that a recording could start on stero then change ac3 but vise versa. There is also wide differences in between stations here.

John almost has his new code working (there are just a few more tweeks we need to make).  This new code will automatically detect the audio stream and adjust it "on the fly".  Basically, this code is going to adjust the audio as you are encoding, just like we are adjusting the video fps to keep the AV in sync.  Once we have this code working your audio problems should be solved (at least that's the theory).

Hecks:

The differences only really show up at the start of the file, where the ffmpeg demuxer locks into sync earlier.  For the rest. the differences are so small that another person might not even notice.  I don't have the means right now to test more accurately, so I wouldn't take my word for it.  In any case, it's a luxury to be quibbling over these details when compared with the awfulness of synching in orc1!  Many thanks again for your work on the new build, and your help with this issue.

Ok, if it's just at the beginning of shows, then that is "normal"  With the MPlayer demuxer there is a chance it will take a few seconds for the AV to lock in.  Like I said, there is logic to automatically adjust the fps (we needed this because some HD shows will adjust fps as the broadcast goes from the commercial to the actual show).  For example, I have quite a few samples where the commercials are 29.97 fps, but the show is 59.97 fps.  Needless to say this causes havoc on the AV sync.  So, for shows that chance their fps the -demuxer 35 isn't a good demuxer.  Of course, the downside to this is at the beginning of shows, or when a show changes fps, or thru a piece of show that is corrupted (I've seen a lot of this in the samples everyone is sending me) it may take a second or two for the AC to get back in sync.  However, I thought the few second to get things back in sync is worth it.  Once we get some of the other big items working (like auto adjustment of the audio), I'll go back and see if there is anyway we can make these adjustments faster.

Edit:  One thing I forgot to say, right now if you use any build other than the builds I'm posting, you won't have all the dvr-ms changes we have been making.  None of the changes have been accepted by the MPlayer developers yet.  Hopefully they will get accepted soon and then all the other builds will also have better dvr-ms support (at least this is our goal).

Hecks:

jelwood:

Are you saying that you have some shows where Mencoder detects it as 59.97 fps, but it is really 25 fps?  If so, can I have a sample?

Sure, here's a 4-min sample (90 MB):

http://www.megaupload.com/?d=PW29UO3S

I'm looking forward to finding out what the root problem is with these sources!

-Hecks

I've been playing with this for a bit and haven't had any issues. The command line I'm using is:

c:\mplayer\mencoder -quiet -lavdopts threads=2 %1 -vf scale=624:-2 -ofps 25 -ovc xvid -xvidencopts fixed_quant=4:threads=2 -oac mp3lame -lameopts abr:br=128 -ffourcc DX50 -o "%~dp1%~n1.avi"

Scaling scale704,-2 works fine as well.Once I accidentally used -ofps 29.97 and  event that worked.

-Scott

http://www.megaupload.com/?d=LS12AYWJ

Above is the link to the latest version of Mencoder (version 6).  This version will need some testing (and please provide feedback if you see problems) because there have been some major changes.  Again, a really BIG Thank You to John Donaghy and the endless hours he has put into this project.  In this version he created a function that automatically detects the type of audio for our friends in Australia.

Also, please remember to NOT use the –demuxer 35 option.  All the dvr-ms changes have been made to the MPlayer demuxer (to use the MPlayer demuxer just don’t use the –demuxer switch).

Improvements in this version are:

1)     You shouldn’t see as many “dropped frames” or “duplicate frames”.  I did some work in this area to try and improve the AV sync.

2)     The Audio type will be automatically detected.

I do have to mention three things.  First, we are automatically detecting a lot of values “on the fly” because we’ve found the dvr-ms header is incorrect sometimes (fps, audio, bit rate, resolution, aspect ratio).   Because of this, you may see some issues in the first few seconds of a show.  Please give me some feedback on this.  We’ve done our best to adjust these values as quickly as possible.  However, if you have shows where it just isn’t acceptable please let me know.  I’d like to see the samples, maybe I can improve it.

Secondly, because we are detecting everything “on the fly” you have to pick an output fps (for example: -ofps 29.97 or –ofps 25).  Sorry, I know people would like to keep the fps of the original broadcast, but we just don’t know what the fps is when we start the encoding (the encoder needs this to encode even the first frame).  I don’t know any way around this – at least not yet…

Third, please don’t use the –delay or -fps switches with the MPlayer demuxer.  If you use these switches it will override the automatic detection.

Below is the command line I used for all of my testing.

XVID/MP3:

mencoder -lavdopts threads=2 "input.dvr-ms" -vf scale=320:-2 -ofps 29.97 -ovc lavc -lavcopts vcodec=mpeg4:vqscale=4:threads=2 -ffourcc XVID -oac mp3lame -lameopts fast:preset=medium -o "output.avi"

H.264/AAC

mencoder -lavdopts threads=2 "input.dvr-ms" -vf scale=320:-2 -ofps 29.97 -ovc x264 -x264encopts crf=4:threads=4 -oac faac -faacopts br=128 -o "output.avi"

jelwood:

I didn't know anyone was having trouble with the Mplayer demuxer.  I would love to see this.  Do you have a show where it always locks up in the same place?  Does the show lockup if you remove the -edl option?  If you have a show that always locks up, and it even locks up without the -edl option, can you upload it to www.megaupload.com for me to look at?

• mencoder -priority idle -lavdopts threads=2 "R:\Backpackers - _23_03_2007_23_00_03.dvr-ms" -vf crop=704:464:10:8,scale=622:-2,pp=lb -ofps 29.97 -ovc xvid -xvidencopts fixed_quant=4:threads=2 -oac mp3lame -lameopts abr:br=128 -ffourcc DX50 -o "V:\Backpackers - _23_03_2007_23_00_03.avi"

• mencoder -priority idle -demuxer 35 -lavdopts threads=2 "R:\Backpackers - _23_03_2007_23_00_03.dvr-ms" -vf crop=704:464:10:8,scale=622:-2,pp=lb -ofps 29.97 -ovc xvid -xvidencopts fixed_quant=4:threads=2 -oac mp3lame -lameopts abr:br=128 -ffourcc DX50 -o "V:\Backpackers - _23_03_2007_23_00_03.avi"