Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
11th July 2018, 17:37 | #81 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Thanks qyot27 for looking into this issue...
This also explains why using the shortcut "ffmpegsource2" works (because indexing will be done before the ffaudiosource call). Of course using this workaround is not really satisfactory if the second track cannot be decoded. Cheers manolito |
12th July 2018, 18:39 | #82 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,903
|
Thank you for the new build!
Still, adding enable10bithack would be really useful for our poor Avisynth (not Avisynth+) users. :') Last edited by FranceBB; 21st July 2018 at 05:43. |
9th August 2018, 11:40 | #83 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
Comparing 2.23.1 and 1327+120 in AvsPmod (Avisynth+ r2728), the outputs are different. Is it a bug or because of newer ffmpeg?
Comparing 2.23.1 and 1140+101 in AvsPmod (Avisynth+ r2728), the outputs are identical. Checked with 8/10bit progressive video (23.976/24.000). Simple script: Code:
FFVideoSource("input.mkv") |
9th August 2018, 22:15 | #84 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
You're going to have to be more specific. Are you sure that's not just the fact that newer versions of the C plugin don't automatically downsample to 8bit? Did you compare 2.23.1 and the latest mainline FFMS2 build?
|
10th August 2018, 02:31 | #85 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
What I mean - https://imgbox.com/g/JWldJPTvIb
Script: Code:
FFVideoSource("HEVC.10bit.mkv") #2.23.1 ConvertBits(8) LoadCPlugin("ffms2_r1140+101-avs+vsp\64-bit\ffms2.dll") FFVideoSource("HEVC.10bit.mkv",cachefile="r1140.ffindex") ConvertBits(8) LoadCPlugin("ffms2_r1327+120-avs+vsp\64bit\ffms2.dll") FFVideoSource("HEVC.10bit.mkv",cachefile="r1327.ffindex") ConvertBits(8) LoadPlugin("ffms2000-test8\64\ffms2.dll") FFVideoSource("HEVC.10bit.mkv",cachefile="test8.ffindex") ConvertBits(8) Also some frames of the video could be ok, other frames could be off. |
10th August 2018, 03:16 | #86 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Okay, it looks like there's a frame skew compared to the other builds.
FFMS2000 test8 is from March 3rd, and there are only a couple of extant C-plugin builds from after that point (including r1327+120, which is from July 10th). Try with the 'lastxp' build in the first post (r1315+119). Since r1315+119 is from April 25th, if it doesn't exhibit this, it was introduced *after* April. If it does show the issue, it happened sometime between March 3rd and April 25th. There were multiple commits that occurred on FFMS2's master branch during mid-March dealing with H.264 PAFF and interlaced HEVC, frame delays, and such. This is stuff that could simply make the frame counts different from then on, and would be visible on a hypothetical FFMS2000 test9 or the next point release. It doesn't necessarily mean it's a bug, just a change in behavior. |
10th August 2018, 06:18 | #87 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
r1315+119 has the same behavior as r1327+120. http://imgbox.com/g/DAz5CXMPN4 - AVC 8bit video, some of the frames are ok, other frames are off.
|
10th August 2018, 07:11 | #88 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Then it occurred somewhere in the five frame-related commits in March*. All of those commits relate to how frames are handled in terms of delay, half-frames/interlacing, discarded frames, and so on. Considering that, is the output from newer FFMS2 builds just different or is playback affected negatively?
*https://github.com/FFMS/ffms2/commit...2d32ed87d7c9ee https://github.com/FFMS/ffms2/commit...cb3c18d4db401a https://github.com/FFMS/ffms2/commit...ea22ed534d01ba https://github.com/FFMS/ffms2/commit...0cb6eaf5f5a81a https://github.com/FFMS/ffms2/commit...4aa69e5531c0e8 |
10th August 2018, 10:36 | #89 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
When the frames are off, usually r1327 shows 2-3 frames ahead compared to 2.23.1 and the other versions. So playback seems ok. Both the first and the last frame always are matching.
Seems some I frames decoded by 2.23.1 are decoded as B frames by r1327 and those are places where the mismatch is starting until the next I frame, which could be decoded either as I frame (frames are matching again) or as B frame (the mismatch is continuing). Also tested some files encoded with x264 and always everything seems ok with these files. |
11th August 2018, 19:24 | #93 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
The sample is cut with mkvtoolnix (https://gitlab.com/mbunkus/mkvtoolni...ting-imprecise). 2.23.1 shows 4 I frames in the beginning.
|
11th August 2018, 21:26 | #94 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Yes, but there aren't 4 I frames. 1 I and 3 B frames. It seems to freeze the I frame for 4 frames total. Now, the 2 strategies to deal with this broken file:
1.) freeze first I frame/recovery point for 4 frames replacing the 3 stray b frames or 2.) skipping/deleting the 3 stray b frames are both valid in itself. You have to do something. The questions would be: A.) is av sync maintained B.) what happens at the end of the clip (both show a length of 501 frames) |
11th August 2018, 22:39 | #95 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
The sample is a part of randomly picked trailer just for testing.
Another sample (should be fine now). When you go forward and backward through the video picking random frames, you will see at some moment that frames by 2.23.1 and r1327 are off. Then if you go backward to find the last I frame (let's call X the frame number) showed by 2.23.1, you will see that X frame by r1327 is B. If you refresh the video by r1327, the frame is still B type. Then if you go backward again to a place where frames by 2.23.1 and r1327 are the same and go forward frame by frame, X frame by r1327 will be now I frame and there will no further mismatch until you start picking randomly frames again. I encoded (x264) this sample with both 2.23.1 and r1327, and compared the encoded files - no matter how long I'm randomly picking forward/backward frames, the frames by 2.23.1 and r1327 are always matching. |
15th August 2018, 09:30 | #97 | Link |
Registered User
Join Date: Jul 2018
Posts: 450
|
Btw FFMS2000 test8 has similar behavior in a lighter form.
It seems the ffmpeg version also has influence. Github tag 2.23 built with the latest ffmpeg master branch has the same behavior as FFMS2000 test 8 - both have a bit different behavior than 2.23.1 release posted here. Tag 2.23 built with the latest release/3.4 ffmpeg branch has the same behavior as 2.23.1 github release. It seems FFMS2000 test 8 behavior starts from this commit, because version compiled from this tree with ffmpeg release/3.4 has the same behavior as the github release. P.S. This problem obviously is not specifically related to the c-plugin, so a staff could move the whole conversion to the appropriate thread? Edit: Reverting back these commits*, build from master branch with the latest ffmpeg has the same behavior as 2.23.1. *https://github.com/FFMS/ffms2/commit...4391e57ad3c6fb https://github.com/FFMS/ffms2/commit...2f582183d3af6d https://github.com/FFMS/ffms2/commit...cb3c18d4db401a Last edited by StvG; 20th August 2018 at 20:13. |
16th September 2018, 04:17 | #99 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
It was about time for a new build anyway.
FFMS2 C-plugin r1327+119 (the backtrack of the C-plugin rev # is nothing to worry about, just a mix-up with the working trees on my local setup - it's been resolved on Github) I tested it against the AV1 samples on https://www.elecard.com/videos, it seems to work. |
Thread Tools | Search this Thread |
Display Modes | |
|
|