Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#2412 closed defect (fixed)

AviSynth: New Demuxer Broken on Windows

Reported by: tateu Owned by:
Priority: important Component: avformat
Version: git-master Keywords: avisynth regression
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

Summary of the bug:
The new AviSynth? demuxer rewrite is broken on Windows. There are two problems with it.
1) If the source AviSynth? script is rgb24, then the colors in the output file are incorrect if it is converted to another color format.
2) A few framess of the AviSynth? script are skipped or duplicated. The first frame is skipped and encoded as broken, the last frame is duplicated.

I have tried 3 different 32bit AviSynth? versions running on Windows 7 x64
AviSynth? v2.58, build:Dec 22 2008 [08:46:51]
AviSynth? v2.60, build:Oct 13 2011 [16:17:05]
AviSynth? v2.60, build:Jan 14 2013 [16:50:35]

I have attached an AviSynth? source script with color bars and timecode overlay and the output of the first ffmpeg command listed below.

How to reproduce:

ffmpeg version N-51338-g914f48d
built on Mar 27 2013 01:04:22 with gcc 4.8.0 (GCC)
"ffmpeg.exe" -i "in.avs" -an -pix_fmt yuv420p -c:v libx264 -preset medium -profile:v main "out_420.mp4"
"ffmpeg.exe" -i "in.avs" -an -pix_fmt yuv420p -c:v rawvideo "out_420.avi"
"ffmpeg.exe" -i "in.avs" -an -pix_fmt bgr24 -c:v rawvideo "out_bgr.avi"

Attachments (3)

out_420.mp4 (7.5 KB) - added by tateu 5 years ago.
ffmpeg-20130328-133445.log (5.1 KB) - added by tateu 5 years ago.
in.avs (214 bytes) - added by tateu 5 years ago.

Download all attachments as: .zip

Change History (21)

Changed 5 years ago by tateu

Changed 5 years ago by tateu

comment:1 Changed 5 years ago by cehoyos

Are the problems also reproducible with an older version of FFmpeg?

comment:2 Changed 5 years ago by tateu

No, it is not reproducible with versions made before Wed, 20 Mar 2013 20:11:22 -0700 (04:11 +0100). It is also not reproducible with the current git master if I revert just the changes made to avisynth.c and configure in http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b9ad009475f3afb76bd2fbd92936dc4d4cd441ec

comment:3 Changed 5 years ago by cehoyos

  • Keywords regression added
  • Priority changed from normal to important
  • Status changed from new to open

comment:3 Changed 5 years ago by tateu

And I just realized I attached the wrong in.avs file. It needed ConvertToRGB24() at the end to shows the color errors described in my issue 1). I have attached the corrected version.

Changed 5 years ago by tateu

comment:4 Changed 5 years ago by cehoyos

The RGB issue should be fixed, in the log you added, no skipped or duplicated frames are indicated. Could you elaborate on the problem?

comment:5 Changed 5 years ago by tateu

Yes, the rgb issue appears to be fixed.

Look at in.avs and out_420.mp4 for the other issue. in.avs contains 10 frames with smpte timecode overlay of 00:00:00:00 - 00:00:00:09. out_420.mp4 contains 11 frames with smpte timecode overlay of 00:00:00:01 - 00:00:00:09, where frame 00:00:00:00 is skipped, frame 00:00:00:01 is duplicated at the beginning and frame 00:00:00:09 is duplicated at the end. And I believe that the duplicated frame 00:00:00:01 at the beginning of the output file is actually a broken frame and not really even a duplicate.

comment:6 Changed 5 years ago by cehoyos

Is this second issue - that frames are duplicated - also a regression since b9ad009 ?

comment:7 Changed 5 years ago by tateu

Yes. Both of these problems are only encountered when using the new avisynth demuxer added in that commit. If you download a fresh git-master from today but replace avisynth.c with the old version from before that commit, you can build a fully working ffmpeg that does not exhibit either of these issues.

comment:8 Changed 5 years ago by tateu

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=ca3cef719e382b0bf44bdee1482ea89bb2d7f245 was posted today and says it fixes this ticket. It does not. The first and last frames are broken/duplicated exactly the same way as the previous versions.

comment:9 Changed 5 years ago by tateu

It appears that the above commit plus the following, fixes the error:

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 775a5f2..8a2ff2a 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -420,8 +420,8 @@ static int avisynth_read_packet_video(AVFormatContext *s, AVPacket *pkt, int dis
     if (discard)
         return 0;
 
-    pkt->pts = avs->curr_frame;
-    pkt->dts = avs->curr_frame;
+    pkt->pts = n;
+    pkt->dts = n;
     pkt->duration = 1;
 
     // Define the bpp values for the new AviSynth 2.6 colorspaces

comment:10 Changed 5 years ago by saste

  • Analyzed by developer set
  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed

Should be fixed in:

commit ca3cef719e382b0bf44bdee1482ea89bb2d7f245
Author: d s <avxsynth-testing@gmail.com>
Date:   Tue Apr 9 15:36:58 2013 -0700

    avformat/avisynth: Fix off-by-one error in avisynth demuxer.
    
    Fixes ticket #2412.
    
    Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Please reopen in case it isn't.

comment:11 Changed 5 years ago by tateu

It's not fixed. Look at comments 8 and 9 above.

comment:12 Changed 5 years ago by tateu

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:13 follow-up: Changed 5 years ago by qyot27

To be specific, the frame start truncation and last frame duplication issue was fixed by that commit. It was not a complete fix for all three frame-related issues in this ticket, though.

That so-called 'broken' frame at the beginning is just a null frame, and due to the way that nulls get treated, it can appear broken and having one at the beginning of a stream before any real video starts isn't correct and therefore it is undesired (it also makes the frame count differ against what you see in e.g. VirtualDub? - that same script has a total of 10 frames in VirtualDub?, ffmpeg outputs 11: null+10). This was true of both AviSynth? and AvxSynth?.

Comment 9 has a partial fix which stops the demuxer from inserting said null frame at the beginning of the video stream. It's a partial fix because the same thing needs to be done to the audio packets as well, and these combined solves that mystery issue* I'd noted on the mailing list when trying to use the SSRC filter with certain framerates (although it may have just been the null frame that mucked it up, but for consistency's sake IMO it's better for the same fix to be applied to avisynth_read_packet_audio as well).

*it made FFMS2 crash (likely it was a memory leak that was only noticeable on my computer because it's so old; newer computers I tested on didn't show the issue) and/or segfault with certain framerates when used with SSRC, and with other source filters (and SSRC still), a very noticeable slowdown occurred under 1 second, presumably until after the demuxer got past the nulled start frame or corresponding audio samples, after which the speed picked up and conversion completed successfully. Like I said, though, actually employing the n variable as in comment 9 for both video and audio seems to have resolved it.

I'll go ahead and submit another patch for this in a few minutes once I get back under Linux.

comment:14 in reply to: ↑ 13 Changed 5 years ago by tateu

Replying to qyot27:

To be specific, the frame start truncation and last frame duplication issue was fixed by that commit. It was not a complete fix for all three frame-related issues in this ticket, though.

No, commit ca3cef719e382b0bf44bdee1482ea89bb2d7f245 did not fix anything with the video for me. Applying the patch that I posted in comment 9 fixed everything with the video for me.

I have not tried anything with audio, though, so I can't comment on that.

comment:15 Changed 5 years ago by qyot27

I tested ca3cef71 and it properly incremented the timecodes from 0-9 as expected, although it still had the null frame at the beginning. I agree that it's best to not prepend one of those to the start of a video stream, though. And the patch that applies it to both video and audio has been submitted to ffmpeg-devel (although not without me sticking my foot in my mouth in the commit message, see below).

The framerate/SSRC issue was apparently already fixed by either ca3cef71 or another commit unrelated to the AviSynth? demuxer.

comment:16 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed

Should be fixed in ff99b42

comment:17 Changed 5 years ago by tateu

Confirmed working. Thanks.

Note: See TracTickets for help on using tickets.