Hi everyone, I’m having issues with playback on > 2.3.0.(also tested with 2.3.1 LTS stable, 2.3.2 LTSbeta as well as 2.3.3 LTS stable which claim it self to be 2.3.2 4de6d18f).
If playing back DNxHD(mxf), ProRes(mov) or Animation(mov) 1080p50 the last frame is never being displayed. If the file ist not looped it stops at the frame before the last one in the file. My file has 296 frames. Playback stops at 295. If the file is set to loop. Frame 296 ist skipped and therefore the loop is not seamless. This file and also some others are working with e.g. 2.2.0 and 2.0.7 and also in other media players on the same machine. Frame 296 is definitely there.
Otherwise if playing back h.264(mp4) playback stops at the last frame e.g. 296. But as expected looping ist not seamless with h.264 anyway.
It’s a known issue, Animation files never get to the last frame since some commit nearly a year ago that fixed another ffmpeg issue. IIRC it was an ffmpeg update.
Thanks @didikunz and @rrebuffo that was pretty fast. I was guessing that it had to do with ffmpeg as 2.2 uses v3 and 2.3.x uses v4. Too bad that there is no fix and the version is called stable. Adding 1f works, but feels more like a pain than a workaround. Cutting a frame would be easy but adding a frame means always use a NLE for converting files. Telling the client that the files need to have +1f isn’t a good idea either.
@didikunz: Also tried my rerendering my mp4s but still not looping seamless. The last frame is played three times. Any hint how to make seamless looping mp4s ?
I think I do not have a mp4 loop with that much movement, that it can bee seen clearly. I just tried with one in 2.3.0 LTS. But as far as I can see it, it looks ok.
Ok, using MOV Container without audio brings back the same problem I have with the other files while looping. Last frame is eaten by ffmpeg. So I’d also need to add 1f to make this work. I though maybe there is the possibility for a looping mp4 without adding 1f. Using only I-Frames in mp4 doesn’t work either.
I believe have the same (or similar) problem even with the sample video files that usually come with caspar: when looping, the last frame stays frozen for too long so it “jumps” into the start of the video.
In my case is a 1080i50 channel with 1080p25 h264 files. Sadly it makes the 2.3.2 server unusable for me.
Has anybody found a solution that doesn’t involve re-exporting all the videos?
One of our FFMPEG command-line gurus can probably write a command, that goes trough a folder and adds a black frame behind all files. Maybe @hreinnbeck?
That seems like a god-level workaround.
It’s like going through the media folder renaming to uppercase every file to avoid unicode character errors. It doesn’t quite solve the problem, just a workaround.
Upon further inspection I found out that the test video that we all know (the one with the family having dinner) doesn’t loop correctly but if I re-encode it with Adobe, it loops normally, without the last frame “freezing” for a couple of frames. I tested it on all builds 2.3.x.
I tried to find a cause or notable difference between the two files with “MediaInfo” but I’m not sure what to make of it.
Does anyone have any clues why one old h.264 doesn’t loop and a “new” h.264 does?
The audio track in the left one is a few hundred ms longer than the video. So I expect caspar is playing to the end of the longest track causing the video to freeze when it runs out.
On the right, the audio has been trimmed to the length of the video
That makes sense. Thank you @Julusian.
It never crossed my mind because 2.0.7 worked fine with that same file, and Adobe Premiere doesn’t show the audio track being longer.
It must be a weird audio codification.
Good to know 2.3.x doesn’t suffer from the bug I thought it did…
@Sidon your original .mp4 video has MPEG-1 Layer 3 encoded audio and the .mp4 exported out of Adobe has AAC encoded audio.
MPEG-1 Layer 3 (a.k.a. MP3), in my experience, nearly never encodes to the original audio file duration and there’s normally a shift/offset/delay of a few milliseconds too.
