I have a weird issue when encoding video with H.265 through ffmpeg where sometimes, the encoder will duplicate a few frames. I have a m2ts from a bluray that I open using an avisynth script with FFMpegSource2. (I will have some treatment to run so I cannot bypass the avisynth script). The video is then encoded like so:
ffmpeg -i script.avs -c:v libx265 out.mkv
This issue does not happen when using libx264 nor does it happen if I feed the m2ts directly to ffmpeg.
I've been using stable release 4.1.4 of ffmpeg, and tried the latest nightly (20190731-42a2edc) and surprisingly, the issue is even worse, many more duplicate frames and wonky results.Code:ID : 4113 (0x1011) Menu ID : 1 (0x1) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, RefFrames : 4 frames Format settings, picture structure : Frame Codec ID : 27 Duration : 17 min 2 s Bit rate mode : Variable Maximum bit rate : 36.0 Mb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan type, store method : Interleaved fields Scan order : Top Field First
+ Reply to Thread
Results 1 to 23 of 23
Can you reproduce the issue consistently ?
Can you upload a sample of the source that demonstrates this behaviour ?
Post your script and commandline
If anything I would guess the problem is in FFMpegSource2 rather than x265. Of course the question is: how do you even detect the duplicate frames?
Indeed the issue can be reproduced consistently, always at the same mark for a specific video. The script only contains FFMpegSource2("00002.m2ts") and the command line is the one I posted. I've purposefully removed as much options as possible.
Here's a sample of the H.265 encode (https://mega.nz/#!ltBnWIaT!_9N732cQbtvEnN8sC_Sxp69tZSpejupI2-Xs3DfYlKA) and the source (https://mega.nz/#!x8ADDSgI!y0fhpjvBSKcvq1AqyVKFOf1etbY27f3RQFYyfSACMnI) as you can see the duplicate frames are very obvious, there is even a rollback. Here it's in the very beginning but it can happen anywhere in the video (depending on the source).
What is your full script ? (ignore the resizing)
Is it just ffms2 ? Or are you using fpsnum /den , or other framerate override ? What does info() say with just ffmpegsource2() ?
Certain versions of ffms2 get the framerate wrong, and if you use fpsnum/den, they introduce duplicates . But you would expect the same duplicates in the libx264 encode
lsmash/ffms2 are quite inconsistent these days . Certain versions of ffms2 and lsmash work better or worse on certain formats . I have dozens handy to swap back and forth
So several versions of ffms2 I tested have the framerate issue (and duplicates if you use fpsnum/den) , but that's in the script (all encodes will ave the problem, not just libx265) . But if you demux it, it works correctly and encodes correctly with ffmpeg libx265. Something with the way ffms2 (and lsmash) handles mkv timecodes . I find mkv container quite buggy these days too . It also works correctly with ffmpeg libx265 (different versions, old and new)
If you're certain the script is ok on your computer with that version of ffms2 (preview the script in avspmod or vdub2) , I can't reproduce the problem with ffmpeg libx265
Well the script I used is dynamically created by a custom script I'm using, turns out there was something else in the avisynth script, a simple call to Prefetch(6) and surprisingly, this is the source of my problem. It seems libx265 does not play well with multithreading for some reason?
Might have spoken too soon. Without prefetch the issue still appears, except in different places.
I've checked the frame rate, it's properly inferred.
prefetch works ok here with libx265 on that sample
did you use SetFilterMTMode correctly for ffvideosource ?
Post everything, full script, full commandline . Don't omit things
I've tried a couple of new things. Instead of using the m2ts, I tried ripping with MakeMKV and encode that, turns out the issue is still present (still only with x265 + ffms2) could it be an issue in the ripping process? Doesn't explain why it's okay with x264. I'll have to try different versions of ffms2 I guess.
I promise you, the script is... FFmpegSource2(".\VOB\00002.m2ts")
And the command line is... ffmpeg -i script.avs -c:v libx265 out.mkv
I had issue with the mkv with several ffms2 versions . But that doesn't explain why ffmpeg libx264 works for you
Everything work ok here, if the script works ok . (In terms of Framerate, framecount ; I had to demux it for several ffms2 versions, and lsmash too)
I can't reproduce your problem, not sure why you have libx265 issues .
What about hardware ? temps / overheating ? Maybe it's stressing the CPU more than libx264 ?
I don' t know . Just guessing about hardware issue. It makes no sense that libx264 would work for you, but not libx65
First, use the mkv sample that you uploaded, not the .m2ts. So everyone is on the same page (ffms2 can have other issues with AVC transport streams)
Try demuxing it , using ffms2 with the elementary stream
If you're reporting that script is fine on your end (in terms of framerate, framecount) , then changing source filter should not help
Well, believe it or not, it seems that as long as I'm not using prefetch, the remaining duplicates are only appearing when playing the sample through VLC. I'm still having some weird encoding issues when using multithreading, but that I can work around. Can you please take a look at this encoded sample and tell me if there are any skips perchance? https://mega.nz/#!1kpCja4Q!NH2TdhMhWhlzgvvGF4qU3APZcryMR9jj0qqivXCGFLI VLC will consistently skip and duplicate a frame around 12 seconds. No problem when playing frame by frame through (also checked PC performance on playback, all in the green, this is a weird bug)
Do you mean multiple encodes of the same script/same encode settings give different framerates ? How are you reading the framerates ?
What about libx264 ?
When you get inconsistent results like that, it could be threading... but the first thing on your mind should be hardware issues (bad psu, bad memory stick, overheating etc...)
I'm using MediaInfo.
Of course now I can't seem to replicate the problem so I might be starting to mix things up. So tried this from scratch:
-Extract title00 through MakeMKV
-Encode title00 with FFMpegSource2("title00.mkv") and ffmpeg -i script.avs -c:v libx265 out.mkv (produces solid 25 fps output)
-Cut a sample from title00 using ffmpeg -i title00.mkv -t 17 -c copy sample.mkv (sample is 25 fps as expected)
-Encode sample with FFMpegSource2("sample.mkv") and ffmpeg -i script.avs -c:v libx265 out.mkv (produces 24.94 fps output)
-Encode sample with ffmpeg -i sample.mkv -c:v libx265 out.mkv (produces 25 fps output)
There's something rotten here... should I use fpsnum then?
(Oh i also tried with the source.mkv I uploaded earlier, it produces a 24.80 fps result... I'm lost)
fpsnum/den will introduce duplicates if the fps is lower than the desired . AssumeFPS(25) will work, only if the frames are correct in the first place (you have to check)
source.mkv was 24.80 fps for several ffms2 versions for me too. If you demux it , it works ok (use elementary stream), without any other script adjustments
The "rottenness" , IMO, is something buggy with MKV handling
What do you mean by elementary stream? I've used MKVCleaver to get the h264 track and open that with ffms2 (and indeed the fps was now correct).
But it does leave me with a question. If MKV cannot be fully trusted and m2ts do not play well with ffms2... what else can I use to encode BluRays? (also, do you think I should consider encoding H.265 in a MP4 container?)
But did you try encoding that new script (with demuxed video) with libx265 ? Can you reproduce the issue in the 1st sample ? or is it ok now ?
If it's ok, then it still doesn't make sense - because why would libx264 work with the old script . Maybe you confused or mixed up some of the observations
Nothing can be fully trusted. You have to check the script carefully. I keep like 20 versions of ffms2 and lsmash handy . Each one has little bugs or quirks. For example one might get framecount wrong for VP9, one might skip PNG decoding, etc.. etc...
The most reliable, by far, is DGSource . But it requires compatible Nvidia card, and not free. Also it doesn't decode all formats, only ones that nvidia/purevideo supports . But that's all blu rays . (VC1, MPEG2, AVC)
There was in fact two separate issues: some duplicates were fixed by using the raw h264 track, and the remaining were not duplicates but stutter during playback; it seems VLC has a lot of issues with h265, which is why h264 wasn't showing this issue. This duality was what's throwing me off.
DGSource... do you mean DGIndexNV? It looks pretty promising, but the licensing seems a PITA.
Thank you for all your help.