video "judder" issue on DVR-MS conversion

[beteljuice]

See comment:21 for a short summary
---

Good afternoon!

I'm attempting to use FFmpeg to convert a DVR-MS file into a MP4 file; I'm using the following command to perform this action:

ffmpeg -i "xyz.dvr-ms" -y -c:v libx264 -crf 23 -strict experimental -c:a aac "xyz.mp4"

After the conversion completes, and I play the MP4 file in QuickTime to view it, I note that the video "judders"; that is to say, the images don't flow smoothly, as it appears as though every other frame is missed.

I've uploaded a copy of the debug log from the conversion attempt, as well as a sample of the original dvr-ms file (I've named it "no_judder.dvr-ms") and the resulting output file from the conversion attempt (named "judder.mp4"). The size of the log was too big for me to include in this ticket description. Any assistance you may be able to provide would be greatly appreciated.

Thanks!

[beteljuice]

This is the debug logfile from my conversion attempt; it represent approximately 90 seconds of video.

[Carl Eugen Hoyos]

Is this only reproducible with -vcodec libx264 or also with -vcodec mpeg4?

[beteljuice]

The file I just uploaded "judder.mp4" is a 18 second sample of the conversion output; it fits under the size restriction for upload, but should be long enough in duration to demonstrate the issue I've described. I'll try the other vcodec option now.

[beteljuice]

Using "-vcodec mpeg4" (in place of "c:v libx264 -crf 23") results in a mp4 which exhibits the same issue.

[beteljuice]

I was unable to upload the original 18 second dvr-ms file sample, as its filesize is 12.5 MB.

[Carl Eugen Hoyos]

Replying to beteljuice:

I was unable to upload the original 18 second dvr-ms file sample, as its filesize is 12.5 MB.

Either read ​http://ffmpeg.org/bugreports.html (there is *no* filesize limit) or upload to ​http://www.datafilehost.com/

Please remember not to upload output files (if not requested), this often leads to confusion.

[beteljuice]

Input file "no_stutter.dvr-ms" has been uploaded to ​http://www.datafilehost.com/d/2192ca2a

[Carl Eugen Hoyos]

Could you test the complete (or at least a longer) sample either with version 0.11 or git version 15e4bd65 and the following command line?

$ ffmpeg -i input -vcodec mpeg4 -acodec ac3 -qscale 2 out.avi

Does the output file play in-sync?

[beteljuice]

I am using a Windows static build of FFmpeg. I've looked over the static builds available in Zeranoe's archive, and I don't see one that's labeled with a git version of "15e4bd65". According to ffmpeg.org/releases, 0.11 was released on May 25, 2012; Zeranoe has a Windows 32-bit static build called "ffmpeg-20120525-git-e02e58f-win32-static.7z" which was posted on that date. There is also a "ffmpeg-20120527-git-9c27f29-win32-static.7z" from May 27, 2012. Will one of these versions suffice for the test?

[Carl Eugen Hoyos]

Please test ​ffmpeg-20120810-git-633b90c-win32-static

[beteljuice]

Using ffmpeg w/ git 633b90c, I found that the resulting output (as an .avi file) played back properly with no judder. However, I did note the following when playing back the files using Windows Media Player 11:

• the audio on the .avi was quieter than the .dvr-ms (had to increase the volume to compensate)
• Using MediaInfo to evaluate the properties of each file, I found that both files showed a resolution of 720x480 and an aspect ratio of 16:9. However, the video stream for the .avi reported 59.940 fps, while the .dvr-ms reported 23.976fps.
• When playing the files in fullscreen, the height of the black bars above and below the .avi was less than the height of the black bars for the .dvr-ms. As an example: the spinning globe at the beginning of the .dvr-ms file is perfectly round, while the globe in the .avi file is oval (left and right sides of the globe pressed inwards).

Are these expected side effects of the test?

[beteljuice]

This is the logfile for the recent ffmpeg test using git 633b90c

[beteljuice]

I've attached the logfile from the git 633b90c test; this was on a 60 second file sample.

[Carl Eugen Hoyos]

Replying to beteljuice:

Using ffmpeg w/ git 633b90c, I found that the resulting output (as an .avi file) played back properly with no judder.

Could you confirm that A/V sync is ok for the output file?
(You have to test a significantly longer sample than the one you uploaded.)

[beteljuice]

I ran the test against the whole .dvr-ms file (2h12m), and confirmed that audio and video in the resulting .avi output file was in sync all the way through. How should we apply these findings towards use of the current version of FFmpeg, taking into account the observations I made in comment 10 of this thread?

[Carl Eugen Hoyos]

When encoding to avi, this is a regression since c5ea3a00 - related to ticket #1627

[Carl Eugen Hoyos]

Replying to beteljuice:

Using ffmpeg w/ git 633b90c, I found that the resulting output (as an .avi file) played back properly with no judder. However, I did note the following when playing back the files using Windows Media Player 11:

• the audio on the .avi was quieter than the .dvr-ms (had to increase the volume to compensate)

This seems completely unrelated.

• Using MediaInfo to evaluate the properties of each file, I found that both files showed a resolution of 720x480 and an aspect ratio of 16:9. However, the video stream for the .avi reported 59.940 fps, while the .dvr-ms reported 23.976fps.

In which situation is this a problem?

• When playing the files in fullscreen, the height of the black bars above and below the .avi was less than the height of the black bars for the .dvr-ms. As an example: the spinning globe at the beginning of the .dvr-ms file is perfectly round, while the globe in the .avi file is oval (left and right sides of the globe pressed inwards).

Is this reproducible with current git head?

[beteljuice]

Using git 785dc14 from 20140115 and the command ffmpeg -i "xyz.dvr-ms" -vcodec mpeg4 -acodec ac3 -qscale 2 "xyz.avi", then watching the .avi file in Windows Media Player 11, I found that:

• the judder has returned, and
• the image is compressed vertically (cited earlier as an example, the globe at the beginning of the file is oval (left and right sides of the globe pressed inwards)) instead of round.

[Carl Eugen Hoyos]

Replying to beteljuice:

• the image is compressed vertically (cited earlier as an example, the globe at the beginning of the file is oval (left and right sides of the globe pressed inwards)) instead of round.

Is this reproducible with vlc?
I just tried with different media players (but not WMP) and the globe is always round.

[beteljuice]

Using VLC player v2.1.2, I am finding that the globe is round for both the git 633b90c and 785dc14 output .avi files (so the vertically compressed image seems to be an issue with the way in which WMP 11 plays back the file). However, I'm still seeing the judder ("stuttering frames") in the git 785dc14 output .avi file when using VLC.

[beteljuice]

As a side note: The filesize of the source .dvr-ms file is 5.4 GB. The filesize of the 633b90c output .avi file is 5 GB, and the filesize of the 785dc14 output .avi file is 3.1 GB.

[beteljuice]

Upon further review: While the .avi file created as a result of the conversion using the 633b90c version of FFmpeg plays back much smoother than the newer 785dc14 version, I have noted some dropped frames on occasion during a review of the playback. This may be attributed to errors that display during 633b90c conversion (as shown in the following example):

frame=114699 fps=140 q=2.0 size= 2652870kB time=01:19:43.77 bitrate=4542.9kbits/
DTS 4783879, next:4784012000 st:2 invalid dropping
PTS 4783879, next:4784012000 invalid dropping st:2
DTS 4783929, next:4784062000 st:2 invalid dropping
PTS 4783929, next:4784062000 invalid dropping st:2

I believe that this is a bug which was corrected in newer versions of FFmpeg, as I don't see these errors when using 785dc14.

[Carl Eugen Hoyos]

The following command did not drop any frames before c5ea3a00 - related to ticket #1627

$ ffmpeg -i no_stutter.dvr-ms -qscale 2 out.avi
ffmpeg version N-61339-g7d7487e Copyright (c) 2000-2014 the FFmpeg developers
  built on Mar 13 2014 08:20:43 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52. 66.101 / 52. 66.101
  libavcodec     55. 52.102 / 55. 52.102
  libavformat    55. 34.101 / 55. 34.101
  libavdevice    55. 11.100 / 55. 11.100
  libavfilter     4.  3.100 /  4.  3.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100
[asf @ 0x2d89900] Estimating duration from bitrate, this may be inaccurate
[asf @ 0x2d89900] Could not find codec parameters for stream 1 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, asf, from 'no_stutter.dvr-ms':
  Metadata:
    DVR Index Granularity: 500
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    VBR Peak        : 80179200
    service_provider: Edited with VideoReDo
    WM/WMRVEncodeTime: 18446744073149586944
    WM/MediaOriginalRunTime: 18446744071580066548
    WM/WMRVEndTime  : 1605517556
    IsVBR           : 1
  Duration: 00:00:04.02, start: 0.200000, bitrate: 25504 kb/s
    Stream #0:0: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
    Stream #0:1: Unknown: none
    Stream #0:2: Video: mpeg2video (Main) (DVR  / 0x20525644), yuv420p(tv), 720x480 [SAR 32:27 DAR 16:9], 5056 kb/s, 30.08 fps, 59.94 tbr, 1k tbn, 59.94 tbc
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out.avi':
  Metadata:
    DVR Index Granularity: 500
    WMFSDKVersion   : 12.0.7601.17514
    WMFSDKNeeded    : 0.0.0.0000
    VBR Peak        : 80179200
    service_provider: Edited with VideoReDo
    WM/WMRVEncodeTime: 18446744073149586944
    WM/MediaOriginalRunTime: 18446744071580066548
    WM/WMRVEndTime  : 1605517556
    IsVBR           : 1
    ISFT            : Lavf55.34.101
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 720x480 [SAR 32:27 DAR 16:9], q=2-31, 200 kb/s, 29.97 tbn, 29.97 tbc
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
Stream mapping:
  Stream #0:2 -> #0:0 (mpeg2video -> mpeg4)
  Stream #0:0 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
[mpeg2video @ 0x2d8be60] ac-tex damaged at 33 140:00:16.67 bitrate=2314.0kbits/s dup=0 drop=225
[mpeg2video @ 0x2d8be60] Warning MVs not available
[mpeg2video @ 0x2d8be60] concealing 720 DC, 720 AC, 720 MV errors in P frame
frame=  206 fps=0.0 q=2.0 Lsize=    5427kB time=00:00:18.25 bitrate=2435.7kbits/s dup=0 drop=231
video:4398kB audio:992kB subtitle:0 data:0 global headers:0kB muxing overhead 0.667496%

[Carl Eugen Hoyos]

Replying to beteljuice:

Using VLC player v2.1.2, I am finding that the globe is round for both the git 633b90c and 785dc14 output .avi files (so the vertically compressed image seems to be an issue with the way in which WMP 11 plays back the file).

WMP does not support reading an aspect ratio from avi.

[Michael Niedermayer]

Should be fixed in 4eb13cdfb0aa053f7c3247a1f7ad4887ff3b367c
please reopen if the judder issue remains