[FFmpeg-trac] #2412(avformat:reopened): AviSynth: New Demuxer Broken on Windows

[FFmpeg]

#2412: AviSynth: New Demuxer Broken on Windows
-------------------------------------+-------------------------------------
             Reporter:  tateu        |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  important    |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  avisynth     |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  1            |
-------------------------------------+-------------------------------------

Comment (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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2412#comment:13>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker