Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bogdanbz]

Unfortunately, there is another issue with this MC32 build (and maybe with the older ones, but I did not check): when playing files over the network, and seeking forward (30s) and backward (5s) repeatedly, it sometimes starts playing at a very reduced speed. JRVR records very few frames dropped (like 2 every 10 seconds) but the playback speed looks like a frame every 2 seconds and the audio constantly breaks. If you let the playback continue, it suddenly resumes at normal fps after a very long time (something like 30 seconds or more).

MC 31 on the same file, with the same seeks forward and backward has no such issue, the playback speed is normal.

I have a file on a remote network drive (a 6.62GB high bitrate BluRay ts file which has no internal subtitle, but I use an external ass subtitle with it) on which I can reproduce this 100% of the time: MC32 stutters after a single 30s seek forward, MC 31 doesn't.

It doesn't happen when copying the file to a local SSD and playing back from there.

Please let me know what kind of logs I can provide to debug this.

Edit: seems like having an external ass subtitle file with the same name as the video file increases the chance of running into the stutter on seek. The stutter still happens on seek even when you have no internal or external subtitle, but maybe not after a single seek, I need two or three on that file for instance.

I have no proof, but I suspect this playback stutter is triggered when the latency of the data retrieval from the remote network location (a folder shared on a system running Windows Server 2019 and accessed from another Win10 computer) is greater than some value. Transfer rate over the network for that file is a constant 60MB/s (aka 480 Mbit/s) while the file has an overall average bitrate of 40 MB/s and an overall max bitrate of 48 MB/s according to MediaInfo (avg of 36.2 MB/s and max of 40 MB/s for the H264 video stream alone with the audio being a PCM track with a constant 2304 KB/s - their sum is less than the reported overall bitrates so the rest must be the ts stream overhead), so the cause doesn't seem to be the constant transfer rate.

Later edit: I replaced the lav64 folder used by MC32 with the lav64 folder from MC31... and the stutter on seek doesn't happen. If I go back to the lav64 that MC32 has downloaded, the stutter on seek is there again. Tested this several times, and I got the same result every time: the lav64 folder from MC31 used with MC 32 build 32 doesn't have the stutter on seek, but it stutters when using the new lav64 in MC32 build 32.

So, I guess something in the new lav filters build, or the way it's used by MC, is causing the stutter on seek.

[Hendrik]

Since you say its a Blu-ray stream, I imagine your reported bitrates are suffering from unit conversion faux pas? And rather are 40Mbps, rather then 40MB/s? Because actual 40 MB/s is beyond Blu-ray specification and really quite a lot of bitrate.
At 40Mbps I don't expect the network to be a huge burden, however as you say it doesn't happen locally..

Are you using hardware decoding? Does changing that setting influence the behavior at all?

Does the same happen on similar files? Other Blu-ray files, or even UHD Blu-ray files?

[bogdanbz]

Yes, it's using hardware decoding. I will try to change that setting later today.

I did not have time to try similar high bitrate files, the fact that I noticed it on that file was by chance.
I did not encounter the issue on other low bitrate files (but I also don't use skip forward/back too often).

Replacing the lav64 folder in the MC32 AppData\JRiver...\Plugins with the one from MC31 makes the issue go away on that same file, so I don't see the file as being the cause for this issue.

I'm not sure what unit MediaInfo uses, you're right that it might be reporting the rate in bits not bytes. I am still confused on what MB and Mb mean since the "accepted" meaning went through a change some years ago. MediaInfo is reporting the rate using MB, btw.

Edit: looking at the file size (6.62 GBytes) it seems that the bitrate is in Megabits/s indeed.

[Hendrik]

Replacing the lav64 folder in the MC32 AppData\JRiver...\Plugins with the one from MC31 makes the issue go away on that same file, so I don't see the file as being the cause for this issue.

Not trying to blame the file, just trying to isolate factors so it can possibly be reproduced, which makes fixing things so much easier.

[bogdanbz]

I tried with Hardware acceleration disabled in the MC video settings, and the stutter after seek is the same as with hardware acceleration enabled.

I enabled Hardware acceleration back, enabled logging in the JRVR settings, and double-clicked on the file. It asked me if I want to resume or start from the beginning and I chose to start from the beginning.

After it started playing I pressed the right arrow key twice rapidly to seek forward 2x 30 secs then I let it play for 2-3 seconds (it was stuttering). This gave me a very small log file, whose contents I attached here. I don't know if it will help though.

The display refresh rate (a TV connected on the HDMI port of the graphic card) is at 120 Hz. I attached the JRVR stats as displayed while the file is playing fine (before trying to seek).

[bogdanbz]

Here is the MediaInfo report on the file (looks like I misremebered, the reported bitrate is in Mb/s after all):

Code: [Select]

Complete name                            : D:\stutter.m2ts
Format                                   : BDAV
Format/Info                              : Blu-ray Video
File size                                : 6.63 GiB
Duration                                 : 23 min 40 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 40.1 Mb/s
Maximum Overall bit rate                 : 48.0 Mb/s
Frame rate                               : 23.976 FPS

Video
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, Reference frames        : 4 frames
Codec ID                                 : 27
Duration                                 : 23 min 41 s
Bit rate mode                            : Variable
Bit rate                                 : 36.2 Mb/s
Maximum bit rate                         : 40.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.728
Stream size                              : 5.99 GiB (90%)

Audio
ID                                       : 4352 (0x1100)
Menu ID                                  : 1 (0x1)
Format                                   : PCM
Format settings                          : Big / Signed
Muxing mode                              : Blu-ray
Codec ID                                 : 128
Duration                                 : 23 min 41 s
Bit rate mode                            : Constant
Bit rate                                 : 2 304 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Bit depth                                : 24 bits
Stream size                              : 390 MiB (6%)
If I multiply the duration in seconds by the avg bitrate, I get less than the file size (7.118.254.080 bytes) which is a bit strange.

[Hendrik]

The thing I can see from the JRVR log is that the video is far behind the clock, and not catching up fast enough. In fact the distance to the clock seems to be growing.
I'll do some more testing and hypothesizing what might have changed to cause this.

If you could test if this affects more files in some way that would be useful.

If I multiply the duration in seconds by the avg bitrate, I get less than the file size (7.118.254.080 bytes) which is a bit strange.

Seems right to me.

1420 seconds * 40.1 Mbps -> 56942 Mbits -> 7118 MByte

[bogdanbz]

I managed to reproduce the issue not only on that ts file but on many others, located on other physical hard-disks on the remote Windows Server machine.

It can be seen the easiest on ts files from Blurays, with H264 video and PCM audio with ~48Mb/s max overall bitrate. The max video track bitrate was 40 Mb/s in all these cases.

If I try the same on ts muxed to mkv files, with the same max video track bitrate, I need somewhat larger overall mkv files, and the stutter does not last long, it's gone after at most 5 seconds while it can take more than 30 seconds for the ts files.

A sure way to run into it is two 30s forward seeks + one 5s backward seek, done quickly.

If I replace the lav64 folder with the one from MC31, I noticed once more that the issue doesn't happen (except once, where it took two seconds to recover).

[Hendrik]

You are playing the TS file directly right, not through Blu-ray title playback?

[bogdanbz]

Yes, I'm playing them directly, by double-clicking them in Windows Explorer.

The folders from the remote computer where the files are located are mounted to drive letters locally, if that matters, I'm not accessing them using network paths like "\\remote_computer\folder\etc".

Edit: tried playing while I accessed the folders in Windows Explorer using network paths like "\\remote_computer\folder\etc" and the stutter still occurs after seeking.

The stutter on seek happens no matter if the ts files are inside the BDMV\STREAM folder or outside of it.

If I try to cut just a small piece of the file (like 400 MBytes) I can't get to reproduce the stutter on seek, it really has to be a big file, over 6.something GBytes.

I made copies of the files on the remote drive (by copy & pasting them) to test if the fragmentation of the original file might be responsible, but the stutter happens when seeking on the file copies too. (the files are located on mechanical hard-disks, not SSDs)

[Hendrik]

I found one possible change that may at least explain it in some sense, can you just drop this over the LAV version from 32, overwriting the same file?

https://files.1f0.de/tmp/avformat-lav-61.zip

[bogdanbz]

Sure, I will try it later today.

I realized today that I have installed on the system an old version of the Lav Filters (in order to be used by other applications) and it has some settings which are not default.

I don't know if the LAV filters registry settings are shared between different versions, or if MC uses them, but I can try to uninstall that old version, install the latest version and modify the default settings. Maybe those settings, especially on the splitter side, are what makes a difference.

[Hendrik]

It should not matter, hopefully. Its intended to be runtime configured starting from defaults, assuming you just use MCs automatic directshow mode, and not a custom mode.

[bogdanbz]

I'm happy to say the new dll fixes the stutter on seek.

I did not uninstall the old lav filters install, I just replaced the dll in the lav64 folder.

[Hendrik]

Great, then I'll prepare a new release for inclusion in MC soon. Thanks for confirming!

[bogdanbz]

Thank you for fixing it!