I’ve searched and found many examples of people having the same issue and it finally happend to me as well. I checked the problematic file and it turns out that FFmpeg can’t handle the file correctly:
[h264 @ 00000171edc519c0] mmco: unref short failure
[h264 @ 00000171edc52740] illegal short term buffer state detected
Since the video plays fine otherwise, I’ve decided to just circumvent the problem because otherwise, Plex tries (and fails) to generate the thumbnails every single day. Turns out the issue only arises when telling FFmpeg to drop intra frames (skip_frame: nokey/nointra), so I’ve forced it to default and let Plex (successfully) create the thumbnails.
Would it be possible for Plex to check for those error messages and reset it to default automatically? If not, hopefully people will find this thread and be able to fix it themselves.
Well yeah, obviously something is wrong, but not ignoring/bypassing those errors is just being pedantic. The video plays/seeks fine otherwise and reripping unfortunately is not an opion. If Plex doesn’t want to implement a workaround, which it really should because it works when using the default paramters, it should atleast flag the file as noncompliant so it doesn’t waste my resources every morning.
There’s a hidden preference you can use instead of binary-hacking Plex to avoid a broken file.
Thanks for watching out brother. I’ve already fixed the issue for me and re-replaced the transcoder, but I’ll keep this in mind for the next time. By the way, how did you find that?
At the time I was digging around to figure out why some files were failing - see the thread I linked previously. And I knew that -skip_frame nokey was a huge performance increase. So I was snooping in the binaries too.
May I have the DEBUG logs ZIP where these errors were found ?
I’d like to see what information PMS / the transcoder found for them.
Also, please show me the XML for the file which generated this error. (hover over the item → Get Info → View XML → from top down through the </media> XML tag.
With this information, we can properly diagnose and discuss before going too far off base on assumptions.
Actually, Raelworld already identified the issue - it has something to do with having open GOPs. So I’m pretty sure the video is correct, it’s just that FFmpeg can’t handle it (for H.264 at least, read that thread for more info).
Here’s a little clip if you want to see for yourself: bad.zip (5.5 MB)
Are you sure your file has open GOPs? FFmpeg can handle them fine in most cases, without throwing the errors you’re getting. AFAIK it’s just -skip_frame nokey that fails in that case.
Obviously yours is also failing, but it would be interesting to see if yours has open GOP too - or if it’s for another reason.
Does your original have the encoding settings embedded? Can you share the stuff Chuck asked for, a bigger sample of the file, and/or the output from mediainfo?
AFAIK it’s just -skip_frame nokey that fails in that case.
Well, yeah, that’s exactly what’s happening here.
Does your original have the encoding settings embedded? Can you share the stuff Chuck asked for, a bigger sample of the file, and/or the output from mediainfo ?
I didn’t really wanna invest too much time in debugging this because I know Plex doesn’t really care about these kinds of issues (don’t get me wrong, it’s still a great product). So anyway, turns out that it’s a mixture between having open GOPs (open_gop=1) and setting the GOP length too low (keyint<=25).
Same thing happend in the other post (open_gop=1:keyint=24).
Yes, this should be fixed!
Using -skip_frame bidir instead of -skip_frame nokey would also be sufficient and it is even faster than -skip_frame default.
[h264 @ 000002071c3f9a40] illegal short term buffer state detectedup=45 drop=0 speed= 117x
[h264 @ 000002071c375340] mmco: unref short failure bitrate=N/A dup=45 drop=0 speed=1.22x
[h264 @ 000002071c375340] illegal short term buffer state detected
[h264 @ 000002071c374980] illegal short term buffer state detectedup=45 drop=0 speed=0.927x
[h264 @ 000002071c375340] illegal short term buffer state detectedup=45 drop=0 speed=0.62x
with bidir everything works. I don´t know if it’s any better but it definitely works and is faster than default. (on my system)
Would you mind testing your file with bidir again?
Sure, I will. I wonder if it’s a similar-but-different issue, or if I’m mis-remembering about testing bidir before.
The issue in the files we were looking at was poor identification of keyframes when nokey was used. In some cases I frames were almost all skipped, leaving nothing to make previews with. But it happened quickly and didn’t generate errors.
bidir should skip only the B frames, leaving the I and P frames. It does sound like that should succeed, so I’m questioning my memory.
It may not give as much speed-up, depending on the GOP structure of a file. I think we’re on the same page.
I wonder if your file has broken B frames, and skipping them is addressing that error.
Anyway, I remember testing with bidir and yeah, it works, although it can/will generate duplicates. The preferred solution is still default for those problematic videos, but maybe bidir would be a better default than nokey (because it’s still fast and doesn’t break “randomly”). Hopefully Plex listens.
bidir shouldn’t be worse than nokey in that regard, and it ought to be better.
That’s part of why I’m comfortable recommending an increased GenerateBIFFrameInterval value. Making duplicate preview frames because of dropped source frames doesn’t make much sense.
@Mitzsch what’s the origin story/provenance of your file?
Another file (Lady Vengeance - remastered bluray) with almost the same behavior. (no mmco: unref short failure bitrate error message)
[h264 @ 0000027d8d30ad80] illegal short term buffer state detectedup=23 drop=0 speed=1.97x
[h264 @ 0000027d8d30ad80] illegal short term buffer state detectedup=23 drop=0 speed=0.265x
[h264 @ 0000027d8d309fc0] illegal short term buffer state detectedup=23 drop=0 speed=0.199x
[h264 @ 0000027d8d309b40] illegal short term buffer state detectedup=23 drop=0 speed=0.181x
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4.1
Format-Einstellungen : CABAC / 3 Ref Frames
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für RefFrames : 3 frames
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 1 h 55 min
Bitraten-Modus : variabel
Bitrate : 36,0 Mb/s
maximale Bitrate : 38,0 Mb/s
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 24,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.723
Stream-Größe : 28,8 GiB (94%)
verwendete Encoder-Bibliothek : x264 core 161
Kodierungseinstellungen : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x110 / me=tesa / subme=11 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=34 / lookahead_threads=2 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=60 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=36000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=38000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:1.00
Sprache : Englisch
Default : Nein
Forced : Nein
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Originales Source-Medium : Blu-ray
