Possible regression in 17.11

I have been using Shotcut for Windows for over 6 months and yesterday upgraded from 17.10 to 17.11. Several of my video source files now take many minutes for Shotcut to load and start playback, or they fail to load at all. The screen is completely white during playback, but audio seems okay. They are MPEG-2 TV recordings.

Reverting back to 17.10 fixed the issue. The videos load immediately and allow editing again.

If there are things to try or debug info I can gather, please let me know.

I downloaded 17.12 today and see the same regression. I have a 3.4 Gig 1920x1080 .mpg file that quickly opens in 17.10 for editing. When I try to open this file in 17.12 it hangs for several minutes and I get Windows (not responding) messages. The source file also opens and plays properly in the VLC media player application.

I uninstalled 17.10 and rebooted my PC before installing 17.12. But still see the hang. What can I do to diagnose or correct the issue?

FFmpeg was not upgraded between v17.10 and v17.11. I am not sure what change could have caused it. Maybe something related to variable frame rate detection. You can upload a short sample clip to https://shotcut.org/notes/support-upload/

The shortest example I currently have is 3.4gigs/31 minutes. When I trim the video to 5, 10, 15, or 20 minutes in length it plays okay in 17.12. Can I/should I/dare I upload the whole thing to the support-upload URL?

Or perhaps video size relative to system size is part of the problem? I’m running on an i3, 64-bit with only 8GB of RAM.

You can upload that large, but not sure if you really want to. Can you make a new recording that is shorter and shows the problem? Also, you can dump the information in Properties and Properties > Menu > More information… here. Alternatively, you can use the MediaInfo program to dump properties.

That is really only a problem as it relates to resolution especially on a 32-bit version of the program. You can edit medium complexity projects up to HD with 8GB but not UHD/4K. Complexity of a project depends heavily on the number of tracks used especially in conjunction with transitions.

Here is the basic media info result:

I think the closest thing I have is some of my old HDV camcorder captures (MPEG-2 video in MPEG transport stream). It is a little difficult to find files that are very long, but I found one 84 minutes. It does not work good at all in Shotcut regardless of version. I tested 17.10 and 17.08, which is the version before latest FFmpeg upgrade. Even tried 15.04. This particular file is practically useless in Shotcut, and I would have to use the new feature Convert to Edit-friendly to use it. You might have to do the same.

I just got a 10 minute (1 GB) capture that exhibits the problem. I will try uploading it now.
…upload complete 3:58PM Eastern.

I got the file and reproduced the problem. It does appear to be related to the new variable frame rate detection code because Shotcut (actually MLT) thinks it is variable whereas MediaInfo says not, and besides MPEG-2 cannot be variable. I will work on fix.

Thanks, glad it’s not just me seeing things. Also, WRT 17.12 I am seeing audio sync issues when converting MPEG2/ac3 to MPEG4/stereo that I did not see with 17.10. Would that be related? Or should I start a new forum thread?

I found the problem and fixed it. It was simple. The code for detecting variable frame rate probes the file by parsing a part of it to gather information such as timestamp of first keyframe and now also the reported video frame duration. That probe function had a limiter that I reduced by 4/5 when making the change! I had thought the old limit was too liberal/long. Well, on this file, it only need to probe a tiny bit further, but I just set it back to the old value to be safe.

Now, it still detects your MPEG-2 video as variable frame rate, which I found very odd. However, there is no denying what the stream is saying based on timestamps:
checking VFR: pkt.duration 3003
checking VFR: pkt.duration 4504
checking VFR: pkt.duration 3003
checking VFR: pkt.duration 4504
checking VFR: pkt.duration 3003
checking VFR: pkt.duration 4504
checking VFR: pkt.duration 3003

These are in timestamps units that use a 90 KHz tick rate, which is standard for MPEG-2. 3003/90000 * 1000 = 33.367 ms, which corresponds exactly with NTSC frame rate. However, 4505 = 50.056 ms, which is strange. I found this thread while searching google on “MPEG-2 variable frame rate”:

So, it seems some tools will play tricks with timestamps, and it does not surprised me in your case since you are using a capture tool of some sort. Capture tools and devices are notorious for producing variable frame rate. However, you need to play around with it yourself in Shotcut to determine if you feel the need to convert it to “edit-friendly” format.

Tomorrow, I can give you a link to a new 64-bit build that has this fix, and then you can check the A/V sync.

1 Like

Sounds great. Thanks for figuring it out and fixing. These videos are raw captures of a Silicondust HDHomeRun Prime delivered cable channel. I don’t think the device is making any changes to the stream with respect to VFR. I think this is the stream being broadcast by Comcast. But I suppose it’s possible.

I look forward to testing the fix when it’s available.

Here is a link to the new build to try:

I am familiar with HDHomeRun, and yes it provides the same transport stream as provided by the broadcaster. So, that makes these varying times more curious. When analyzing this stream with
ffprobe -select_streams v -show_frames ~/net/media/unsorted/videos/test/ABCafternoonShotcut1712fail.ts | less
I see that every time pkt_duration=4504 is reported that repeat_pict=1 is also reported. If you step frame-by-frame on the clip you provided you will see that periodically a frame is repeated: 5&6, 15&16, 25&26. Once the commercials and the program starts, this pattern goes away. This might be some form of telecine pulldown for including material produced in 24p.

Nice! My original 30 minute video now loads instantly in 17.12.06. It plays and edits easily too. Also, the H.264/aac stereo encoding result is completely in sync. I’d call the 17.12.06 release a complete fix for the problems I previously reported in this thread. Thanks.