andy vt's tools & blog

Yesterday the ffmpeg source code was updated so it now natively supports DVR-MS files.  Now you can use a build of ffmpeg from anyone you would like (as long as it’s build r9976 or later).  I’m supplying build r9976 for anyone that is interested (the download link is below).

http://babgvant.com/files/folders/misc/entry4997.aspx

Improvements in this build verses my BETA version 1:

1) ffmpeg will now read thru corruption in the dvr-ms file much better as long as you use the “–async 1” switch.  Actually, ffmpeg’s ability to read thru corruption is now at least as good as Mencoder – and in my opinion ffmpeg is better.

2) All the changes to properly read DVR-MS files have been integrated in the ffmpeg SVN, so this version doesn’t have any special code from me.

Below are the command lines that I tested.

General Divx5/Xvid with MP3:

ffmpeg -benchmark -y -i "input.dvr-ms" –async 1 -deinterlace -vcodec mpeg4 -s qvga -qscale 4 -vtag DX50 -acodec libmp3lame -ac 2 -ab 128000 -f avi "output.avi"

Xvid with MP3:

ffmpeg -benchmark -threads 2 -y -i "input.dvr-ms" –async 1 -deinterlace -s qvga -vcodec libxvid -qscale 4 -vtag DX50 -acodec libmp3lame -ac 2 -ab 128000 -f avi "output.avi"

X264 with AAC:  This was tested with QuickTime, It should work with the IPod, but I don't have one to test with

ffmpeg -y -benchmark -threads 2 -i "input.dvr-ms" –async 1 -deinterlace -s qvga -vcodec libx264 -b 384000 -bufsize 384 -coder 0 -level 13 -acodec libfaac "output.mp4"

This is a profile specifically for the Blackbery 8830:

ffmpeg -y -benchmark -i "input.dvr-ms" –async 1 -deinterlace -s 320x240 -vcodec mpeg4 -r 25 -b 512000 -acodec libfaac -ac 2 -ab 96000 "output.mp4"

Windows Media Version 8:

ffmpeg -benchmark -y -i "input.dvr-ms" –async 1 -deinterlace -s qvga -vcodec wmv2 -qscale 4 -acodec wmav2 -ac 2 -ab 128000 "output.wmv"

x264/AAC profile does indeed work with iPod, I'd recommend the following to ensure a max bitrate of 768k and better audio quality:

 <profile>
    <name>X264 with AAC</name>
    <description>X264 with AAC (Ipod)</description>
    <extension>mp4</extension>
    <video>-async 1 -deinterlace -vcodec libx264 -b 384k -maxrate 768k -bufsize 384 -coder 0 -level 13</video>
    <audio>-acodec libfaac -ab 128k</audio>
<addswitch>-threads 2</addswitch>
  </profile>

 

It's pretty fast. Not blazingly fast like AVIVO, but still pretty good.  Takes about 7 minutes to do a half-hour show.
 

Coyote:

x264/AAC profile does indeed work with iPod, I'd recommend the following to ensure a max bitrate of 768k and better audio quality:

 <profile>
    <name>X264 with AAC</name>
    <description>X264 with AAC (Ipod)</description>
    <extension>mp4</extension>
    <video>-async 1 -deinterlace -vcodec libx264 -b 384k -maxrate 768k -bufsize 384 -coder 0 -level 13</video>
    <audio>-acodec libfaac -ab 128k</audio>
<addswitch>-threads 2</addswitch>
  </profile>

 

It's pretty fast. Not blazingly fast like AVIVO, but still pretty good.  Takes about 7 minutes to do a half-hour show. 

Thank you for testing this...  It really helps knowing it will actually work on an IPod (I just didn't have one to test with).

Coyote:

x264/AAC profile does indeed work with iPod, I'd recommend the following to ensure a max bitrate of 768k and better audio quality:

 <profile>
    <name>X264 with AAC</name>
    <description>X264 with AAC (Ipod)</description>
    <extension>mp4</extension>
    <video>-async 1 -deinterlace -vcodec libx264 -b 384k -maxrate 768k -bufsize 384 -coder 0 -level 13</video>
    <audio>-acodec libfaac -ab 128k</audio>
<addswitch>-threads 2</addswitch>
  </profile>

 

It's pretty fast. Not blazingly fast like AVIVO, but still pretty good.  Takes about 7 minutes to do a half-hour show.
 

AVIVO cheats (drops frames) when it does the conversion; makes it good for small screen devices, not so good for archiving.

If you have "Handheld Frame Rate" selected in the ATI Video Encoder properties, it will drop frames to get 15 fps.
Believe me, it's still noticable on a small screen...

However, this is only the default for the low bitrate preset (along with no B-frames). I think it's off in the .GRF I use to export to iPod.

If you can find where AVIVO drops frames all the time, that would be interesting. There's no reason for a non-realtime transcoder to drop frames.

Coyote:

If you have "Handheld Frame Rate" selected in the ATI Video Encoder properties, it will drop frames to get 15 fps.
Believe me, it's still noticable on a small screen...

However, this is only the default for the low bitrate preset (along with no B-frames). I think it's off in the .GRF I use to export to iPod.

If you can find where AVIVO drops frames all the time, that would be interesting. There's no reason for a non-realtime transcoder to drop frames.

I remember seeing this when I was working on the Mencoder project.  I noticed when I looked at the Divx file AVIVO created the header said 29.97 fps, but there was actually only 26.something frames, and the shows with 59.96 fps only really had 53.something fps (it was a long time ago, I don't remember what the decimal point was).  When I watched the shows I couldn't detect any quality loss at all (I don’t notice the slight differences in audio and video quality that others do, so maybe it was just I couldn't detect it), but as I counted the frames in libavcodec's parser.c I noticed roughly a 10% frame drop.  I don't know if this happened for all formats because I was only looking at Divx/Xvid (I was comparing the quality to see if I could mirror the AVIVO quality/speed thru the Mencoder command line).  I think ATI clearly did good work because even accounting for the 10%, they were still faster than Mencoder and I couldn’t find any other differences.  I still think ATI clearly did a great job with these codecs.

does/will ffmepeg support reading edl files during the encoding process?

mithican 

mitchican:

does/will ffmepeg support reading edl files during the encoding process?

mithican 

No, you have to use Mencoder for that.  However, you can use the Dtb action to create a new DVR-MS file without commercials and then use ffmpeg to encode it.

• 4:3 aspect shows

-y -benchmark -threads 2 -i "%CutDvrmsFile%" -async 1 -deinterlace -croptop 0 -cropbottom 4 -cropleft 8 -cropright 6 -s 704:480 -vcodec libx264 -b 832k -maxrate 960k -bufsize 384k -coder 1 -level 13  -flags +loop -cmp +chroma -partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -flags2 +wpred+mixed_refs+8x8dct+brdo -me umh -trellis 2 -bidir_refine 1 -refs 3 -b_strategy 1 -directpred 2 -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -aspect 4:3 -acodec libfaac -ab 128k "%OutputFile%"

• 16:9 aspect shows

-y -benchmark -threads 2 -i "%CutDvrmsFile%" -async 1 -deinterlace -croptop 56 -cropbottom 60 -cropleft 8 -cropright 6 -s 704:368 -vcodec libx264 -b 832k -maxrate 960k -bufsize 384k -coder 1 -level 13  -flags +loop -cmp +chroma -partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -flags2 +wpred+mixed_refs+8x8dct+brdo -me umh -trellis 2 -bidir_refine 1 -refs 3 -b_strategy 1 -directpred 2 -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -aspect 16:9 -acodec libfaac -ab 128k "%OutputFile%"

Couple of things about using ffmpeg in DTb 1.2.0.9. These didn't happen with 1.2.0.8+fpmeg package:

 - ffmpeg appears to default to very verbose output now. Before, it was quiet with only the benckmark output. This really clutters up the logs. I can fix this by adding "-v 0" to the <addswitch> line of the profile, but can we get a "quiet" checkbox in the config dialog (like mencoder?)

- occasionally, DVRMStoMPEG will hang or quit during the Convert with Ffmpeg action. This seems to happens after ffmpeg.exe terminates normally: it just never proceeds to the next action.

I don't know if these problems are in the DTb action or the included build of ffmpeg...

Coyote:

Couple of things about using ffmpeg in DTb 1.2.0.9. These didn't happen with 1.2.0.8+fpmeg package:

 - ffmpeg appears to default to very verbose output now. Before, it was quiet with only the benckmark output. This really clutters up the logs. I can fix this by adding "-v 0" to the <addswitch> line of the profile, but can we get a "quiet" checkbox in the config dialog (like mencoder?)

- occasionally, DVRMStoMPEG will hang or quit during the Convert with Ffmpeg action. This seems to happens after ffmpeg.exe terminates normally: it just never proceeds to the next action.

I don't know if these problems are in the DTb action or the included build of ffmpeg...

i can add a quiet, but it will break any profiles that use the action.  you can mitigate that by removing the action before installing the new rev.

if you convert the same file again does it break again?  if i can repro it, I should be able to fix it, but I haven't been able to here. 

no, the same file will complete if run again. It seems to me that DVRMStoMPEG doesn't always detect that ffmpeg.exe has exited. Are you watching the PID or something else?

there's a class (asyncprocess) that wraps the use of external processes, it sets up the shelling and spins waiting for the process to end.  while it is spinning it reads data that is output and uses an event to publish the data.  my guess is that it is detecting that the process is ended but ffmpeg doesn't close the output stream properly when it executes, but I'm just guessing at this point.  that class has been around for a long time, and it's used all over the place (including the GUI tool; that's how it reads the output from dvrmstompeg.exe and writes it to the textbox).  I need to be able to repro it to code around whatever is causing the issue.

well, DVRMStoMPEG runs ffmpeg with the -benchmark switch, so it generates a final line you should be able to look for? I know the ffmpeg output used to just say "bench utime=xxxx" and now I get error/status lines, even with the -v 0 suppressing most of it. I don't get the "bench" line. Did something change in the ffmpeg build?

nothing changed in the build, i wasn't wiring up the output correctly before.  ffmpeg writes it's output to stderr, i was polling stdout before. 

maybe I should just add an option to not capture output at all, maybe that will "fix" it.