Media Player Classic - BE Win32/x64 - Page 289

Razoola · 15th October 2018, 11:12

I was trying to watch a NFL game last night useing the aceplayer stream option in MPC-BE. I had just installed the 4053 nightly build. However it just would not work and play the stream (error file not found reported after a few seconds in the players status bar). After going back to released build of MPC-BE (1.5.1) aceplayer started working. I did notice however that even with this version audio and video would go out of sync the longer a stream played. The stream worked fine using the player that comes with acestream.

This is the first time I have tried to use MPC-BE to play acestreams and wondered if both of these issues are known in MPC-BE?

Aleksoid1978 · 15th October 2018, 11:30

Try to increase "cashe time" in Acestream. Give me a link - i test.

Razoola · 15th October 2018, 12:49

Quote:

Originally Posted by Aleksoid1978

Try to increase "cashe time" in Acestream. Give me a link - i test.

The stream is no longer available but here is another that will go out of sync. It seems to happen if the video glitches. It does not auto correct itsself back into sync.
acestream://7f12cca406cf461596bad8478915cadb96b48960

Aleksoid1978 · 15th October 2018, 13:17

Quote:

Originally Posted by Razoola

The stream is no longer available but here is another that will go out of sync. It seems to happen if the video glitches. It does not auto correct itsself back into sync.
acestream://7f12cca406cf461596bad8478915cadb96b48960

Perfect playback and A/V sync.

Razoola · 15th October 2018, 13:27

Quote:

Originally Posted by Aleksoid1978

Perfect playback and A/V sync.

Can I just ask if you are using LAV for video and audio and if so what version? Just wondering if my issue is there.

huhn · 15th October 2018, 13:28

maybe try the internal filter first. i mean this is the mpc-be thread not the lavfilter thread.

Aleksoid1978 · 15th October 2018, 13:31

I always use only internal filters. If bug using LAV - you are wrong thread

mkver · 15th October 2018, 16:39

I have another bug report for you. I hope you can understand me (I unfortunately don't speak Russian); if not, just ask for more information.

a) Summary: I have been experiencing a strange phenomenon with subtitles in Matroska: Sometimes they are displayed twice after seeking:

I looked into this and it seems that this happens if and only if (i) in order to decode the video, one has to seek to the very cluster that the subtitle block is in and (ii) the subtitles should be shown during the point in time to which one seeks (but of course they should only be shown once) and (iii) the subtitles have a timestamp that is lower than the cluster timestamp of the cluster that contains the video block that is being seeked to (by "video block that is being seeked to" I don't mean the actual frame the user wants, but the keyframe that is being seeked to in order to get the actual frame the user wants). Here is mkvinfo's output for a situation in which this can happen (Here is the sample):

Code:

...
|+ Cluster at 9820991
| + Cluster timestamp: 00:00:10.447000000 at 9821009
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:10.447000000 at 9821013
|  + Frame with size 180180 at 9821021
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.270000000 at 10001201
|  + Frame with size 1792 at 10001208
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.367000000 at 10003000
|  + Frame with size 12088 at 10003007
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.302000000 at 10015095
|  + Frame with size 1792 at 10015102
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.307000000 at 10016894
|  + Frame with size 1641 at 10016901
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.327000000 at 10018542
|  + Frame with size 4069 at 10018549
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.334000000 at 10022618
|  + Frame with size 1792 at 10022625
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.347000000 at 10024417
|  + Frame with size 3790 at 10024424
| + Block group at 10028214
|  + Block: track number 3, 1 frame(s), timestamp 00:00:10.350000000 at 10028216
|   + Frame with size 25 at 10028222
|  + Block duration: 00:00:01.680000000 at 10028247
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.366000000 at 10028251
|  + Frame with size 1792 at 10028258
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.387000000 at 10030050
|  + Frame with size 1158 at 10030057

As can be seen, the subtitle (track 3) has a lower timestamp than the cluster timestamp. If one seeks to the keyframe at 10.447s, the subtitle at 10.35s is displayed twice.

b) I don't know your seeking code, but I guess that you look in the cues for the cluster that contains the video keyframe that needs to be seeked to and you also search the cues for subtitles that should be displayed at the intended time. Then you seek to that cluster, look at its cluster timestamp and if its bigger than the timestamp of one of the subtitles that should be displayed, you seek another time to the subtitle block referenced in the cues. If one does this with the example above and seeks to 10.447s, the subtitle block at 10.35s is found during the normal seeking operation, but it is also found a second time during the deliberate seeking to the subtitles, hence it is displayed twice.

c) It seems to me that when you ignore the CueRelativePosition element when it is inside a cue entry for a video track; instead, you always seek to the beginning of the cluster that is referenced and start processing from said beginning. But for subtitle blocks you use this element. Is this true? I tested it with files in which I have manually changed the CueRelativePosition: Nothing was affected when I changed the CueRelativePosition element of a video entry, but subtitles didn't work upon seeking when setting CueRelativePosition to an incorrect value. If I am right, then the following procedure should produce better results: When you seek you parse the cues, and seek to the cluster containing the video keyframe that is required for decoding the desired frame (i.e. the cluster containing the keyframe with the highest timestamp that is <= the desired timestamp). If the cues indicate that there is a subtitle element that should be displayed during the desired time and said subtitle block is in a cluster before the cluster containing the video keyframe that has just been seeked to then one does a second seek to retrieve the subtitles. If the subtitle block is in or after the cluster that we have already seeked to, then this subtitle element will be read anyway during the normal course of reading the file.
(If the subtitles are wrongly interleaved (i.e. subtitles destined to be shown at 1m interleaved with video and audio with timestamps 2m, then it might happen that the current seeking procedure will work with these files, but the proposed one won't. But such files should be considered broken anyway, whereas the files I'm just talking about are not.)

d) If you are wondering why the files are interleaved like that: They have been created by ffmpeg and ffmpeg doesn't interleave by pts, but by dts. And it also doesn't try to avoid negative relative timestamp offsets in the Matroska (Simple)Blocks, it simply uses the timestamp of the first (Simple)Block it intends to put into the cluster as cluster timestamp. Therefore situations like under a) can and do happen.

e) If you are wondering how I came to the conclusion from b): The sample I already linked to in a) has two points where subtitles appear doubled: At about 10s (I quoted mkvinfo's output of this part in a)) and at about 17s:

Code:

|+ Cluster at 14810224
| + Cluster timestamp: 00:00:17.487000000 at 14810242
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:17.487000000 at 14810246
|  + Frame with size 187790 at 14810254
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.310000000 at 14998044
|  + Frame with size 1792 at 14998051
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.407000000 at 14999843
|  + Frame with size 11750 at 14999850
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.342000000 at 15011600
|  + Frame with size 1792 at 15011607
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.347000000 at 15013399
|  + Frame with size 1645 at 15013406
| + Block group at 15015051
|  + Block: track number 3, 1 frame(s), timestamp 00:00:17.350000000 at 15015053
|   + Frame with size 66 at 15015059
|  + Block duration: 00:00:03.200000000 at 15015125
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.367000000 at 15015129
|  + Frame with size 3113 at 15015136
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.374000000 at 15018249
|  + Frame with size 1792 at 15018256

Based on these two examples, my first guess was that it is the fact that the video keyframe has a pts that is bigger than the pts of the subtitle block that is later in the file that is causing this (i.e. I thought that MPC-BE seeks to the necessary video keyframe and to any earlier subtitle block referenced in the cues that is to be shown during the desired frame). But this is not true, as the file has numerous other clusters where this happens, but without the subtitles being shown doubled (at about 2s, at about 5s, at about 49.5s and at about 55.9s). Here are two examples:

Code:

|+ Cluster at 4480132
| + Cluster timestamp: 00:00:05.022000000 at 4480150
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:05.022000000 at 4480154
|  + Frame with size 1792 at 4480161
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:05.207000000 at 4481953
|  + Frame with size 121487 at 4481961
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.127000000 at 4603448
|  + Frame with size 31586 at 4603456
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:05.054000000 at 4635042
|  + Frame with size 1792 at 4635049
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.067000000 at 4636841
|  + Frame with size 2248 at 4636848
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:05.086000000 at 4639096
|  + Frame with size 1792 at 4639103
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.087000000 at 4640895
|  + Frame with size 11625 at 4640902
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.107000000 at 4652527
|  + Frame with size 10840 at 4652534
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:05.118000000 at 4663374
|  + Frame with size 1792 at 4663381
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.147000000 at 4665173
|  + Frame with size 960 at 4665180
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.167000000 at 4666140
|  + Frame with size 11822 at 4666147
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:05.150000000 at 4677969
|  + Frame with size 1792 at 4677976
| + Block group at 4679768
|  + Block: track number 3, 1 frame(s), timestamp 00:00:05.150000000 at 4679770
|   + Frame with size 26 at 4679776
|  + Block duration: 00:00:01.720000000 at 4679802
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.187000000 at 4679806
|  + Frame with size 11151 at 4679813

Code:

|+ Cluster at 49051320
| + Cluster timestamp: 00:00:55.742000000 at 49051338
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:55.742000000 at 49051342
|  + Frame with size 1792 at 49051349
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:55.927000000 at 49053141
|  + Frame with size 181308 at 49053149
| + Block group at 49234457
|  + Block: track number 3, 1 frame(s), timestamp 00:00:55.750000000 at 49234459
|   + Frame with size 47 at 49234465
|  + Block duration: 00:00:02.280000000 at 49234512
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:55.847000000 at 49234516
|  + Frame with size 16523 at 49234524
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:55.774000000 at 49251047
|  + Frame with size 1792 at 49251054

The four counterexamples have all two things in common:
(i) The clusters start with an audio block whose timestamp is lower than the timestamp of the subtitle block contained in the cluster.
(ii) The cluster timestamp is lower than the timestamp of the subtitle block contained in the cluster (in fact, the cluster timestamp always coincides with the timestamp of the first block contained in it).

In order to find out which of the two alternatives it is I have voided (i.e. using the 0xEC element that Matroska has to reserve space) the audio blocks (including the track header for the track) the audio blocks. Here's a part of mkvinfo's report for the resulting file:

Code:

|+ Cluster at 4480132
| + Cluster timestamp: 00:00:05.022000000 at 4480150
| + EBML void: size 1796 at 4480154
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:05.207000000 at 4481953
|  + Frame with size 121487 at 4481961
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.127000000 at 4603448
|  + Frame with size 31586 at 4603456
| + EBML void: size 1796 at 4635042
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.067000000 at 4636841
|  + Frame with size 2248 at 4636848
| + EBML void: size 1796 at 4639096
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.087000000 at 4640895
|  + Frame with size 11625 at 4640902
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.107000000 at 4652527
|  + Frame with size 10840 at 4652534
| + EBML void: size 1796 at 4663374
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.147000000 at 4665173
|  + Frame with size 960 at 4665180
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.167000000 at 4666140
|  + Frame with size 11822 at 4666147
| + EBML void: size 1796 at 4677969
| + Block group at 4679768
|  + Block: track number 3, 1 frame(s), timestamp 00:00:05.150000000 at 4679770
|   + Frame with size 26 at 4679776
|  + Block duration: 00:00:01.720000000 at 4679802
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.187000000 at 4679806
|  + Frame with size 11151 at 4679813

Even for this modified file only the two places at 10s and 17s showed double subtitles. This rules the possibility (i) out.

In order to test whether it is really (ii) I have remuxed the file (again with ffmpeg) without the audio track. The resulting file looks like this:

Code:

|+ Cluster at 4199358
| + Cluster timestamp: 00:00:05.207000000 at 4199376
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:05.207000000 at 4199380
|  + Frame with size 121487 at 4199388
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.127000000 at 4320875
|  + Frame with size 31586 at 4320883
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.067000000 at 4352469
|  + Frame with size 2248 at 4352476
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.087000000 at 4354724
|  + Frame with size 11625 at 4354731
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.107000000 at 4366356
|  + Frame with size 10840 at 4366363
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.147000000 at 4377203
|  + Frame with size 960 at 4377210
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.167000000 at 4378170
|  + Frame with size 11822 at 4378177
| + Block group at 4389999
|  + Block: track number 2, 1 frame(s), timestamp 00:00:05.150000000 at 4390001
|   + Frame with size 26 at 4390007
|  + Block duration: 00:00:01.720000000 at 4390033
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:05.187000000 at 4390037
|  + Frame with size 11151 at 4390044

Notice that the cluster timestamp has changed because there is no audio track any more. This time, all the six places where there are subtitle blocks with lower pts muxed after video keyframes with higher pts showed doubled subtitles. This confirms (ii).

f) This bug is about duplicated subtitles showing up in some places. But if I pause the video and seek from keyframe to keyframe (back and forth), it is not uncommon for subtitles to not appear directly after the seek even though they should. If I later seek to the very same keyframe again, the subtitles show up. I don't know why. I don't even know if this problem is unique to me. I just tell you this so that you aren't surprised if you experience the same issue.

alex1399 · 15th October 2018, 16:55

TLTR, too much information ~
Please use simple English for conversation

I can reproduce it. The dialog "Aber das ist voll gemein," appeared twice during specific operation: (1) playback until 11.5 sec (2) seek back to 11sec.

mkver · 15th October 2018, 17:34

Under certain circumstances subtitles are displayed twice. These circumstances are: If a cluster contains both a video keyframe as first video block and furthermore a subtitle block is contained in the cluster and if the subtitle block has a timestamp smaller than the cluster timestamp, then the subtitle block will be displayed twice when one seeks to the video keyframe.
The reason seems to be: MPC-BE seeks to the block containing the video keyframe, looks at the cluster timestamp and if the cluster timestamp is higher than the timestamp of the subtitle block (the timestamp of the subtitle block is already known from the cues), then it falsely presumes that it has to seek to the subtitle block in order to get the subtitle block, because it simply presumes based upon the timestamps that the subtitle block was interleaved earlier. Therefore it reads the subtitle block twice: Once during the deliberate seek to the subtitle block and once during the normaling reading of the cluster the video keyframe is in. Therefore MPC-BE displays the subtitle block twice.
Here is a sample; the two points were this happens are at about 10.4s and at about 17.4s. The cluster at 17.4s looks like this:

Code:

|+ Cluster at 14810224
| + Cluster timestamp: 00:00:17.487000000 at 14810242
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:17.487000000 at 14810246
|  + Frame with size 187790 at 14810254
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.310000000 at 14998044
|  + Frame with size 1792 at 14998051
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.407000000 at 14999843
|  + Frame with size 11750 at 14999850
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.342000000 at 15011600
|  + Frame with size 1792 at 15011607
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.347000000 at 15013399
|  + Frame with size 1645 at 15013406
| + Block group at 15015051
|  + Block: track number 3, 1 frame(s), timestamp 00:00:17.350000000 at 15015053
|   + Frame with size 66 at 15015059
|  + Block duration: 00:00:03.200000000 at 15015125
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.367000000 at 15015129
|  + Frame with size 3113 at 15015136
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.374000000 at 15018249
|  + Frame with size 1792 at 15018256

This file has been produced by ffmpeg and ffmpeg interleaves by dts, not pts. Therefore the file looks the way it does.

Aleksoid1978 · 16th October 2018, 01:12

mkver
Test build - https://yadi.sk/d/MxiYP2HXvWCOJQ

mclingo · 16th October 2018, 12:24

i dont think MPC-BE is summing audio channels correctly. I have 5.1.2, two front, two rear, center and sub plus two ATMOS front heights. MPC-BE using internal filters is summing my ATMOS heights to front left and right, if I use latest external LAV filters all is ok.

Aleksoid1978 · 16th October 2018, 12:33

5.1.2 PCM output don't support by Windows, it's not standart channel layout. If you bitstream track with Atmos extension - all audio handling do A/V reciver.

mkver · 16th October 2018, 18:53

Quote:

Originally Posted by Aleksoid1978

mkver
Test build - https://yadi.sk/d/MxiYP2HXvWCOJQ

Many thanks for this prompt update. Much appreciated. This test build is indeed an improvement and the sample I uploaded earlier works fine with it. But I have remuxed the file and used smaller clusters this time so that the file layout looks like this:

Code:

|+ Cluster at 9821804
| + Cluster timestamp: 00:00:10.417000000 at 9821822
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:10.417000000 at 9821826
|  + Frame with size 180180 at 9821834
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.240000000 at 10002014
|  + Frame with size 1792 at 10002021
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.337000000 at 10003813
|  + Frame with size 12088 at 10003820
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.272000000 at 10015908
|  + Frame with size 1792 at 10015915
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.277000000 at 10017707
|  + Frame with size 1641 at 10017714
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.297000000 at 10019355
|  + Frame with size 4069 at 10019362
|+ Cluster at 10023431
| + Cluster timestamp: 00:00:10.304000000 at 10023449
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.304000000 at 10023453
|  + Frame with size 1792 at 10023460
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:10.317000000 at 10025252
|  + Frame with size 3790 at 10025259
| + Block group at 10029049
|  + Block: track number 3, 1 frame(s), timestamp 00:00:10.320000000 at 10029051
|   + Frame with size 25 at 10029057
|  + Block duration: 00:00:01.680000000 at 10029082
| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:10.336000000 at 10029086
|  + Frame with size 1792 at 10029093

This time the subtitle block is in the cluster after the cluster with the keyframe that has a higher timestamp than the subtitle block. And in this situation one has double subtitles again. Seeking to the intervall from 10.5s to 11s or from 17.5s to 18s shows it.
Here is the file.

Aleksoid1978 · 16th October 2018, 23:07

mkver
Thanks for samples.

Test build - https://yadi.sk/d/ai6hM8QGJA0yIQ

mclingo · 18th October 2018, 14:39

Quote:

Originally Posted by Aleksoid1978

5.1.2 PCM output don't support by Windows, it's not standart channel layout. If you bitstream track with Atmos extension - all audio handling do A/V reciver.

that might be it, i reinstalled BE recently and might have fogotten to turn on bitstream, cheers.

mkver · 18th October 2018, 17:07

Quote:

Originally Posted by Aleksoid1978

mkver
Thanks for samples.

Test build - https://yadi.sk/d/ai6hM8QGJA0yIQ

This works really well. It fixes the issue and I have found no negative side-effects. Thanks for it!

Grimsdyke · 18th October 2018, 21:50

Quote:

Originally Posted by Grimsdyke

2) There is a German label which unfortunately names all their BluRays with the companys name. No matter which film the discs are named ANOLIS FILM ENTERTAINMENT.
I have several external audio files there and unfortunately they are ALL loaded even when not meant for that movie and that causes handling problems for my somewhat weak system !!
So I was wondering if you could not add a check for, say, the time stamp of the bdmv-folder ?
For example: ANOLIS FILM ENTERTAINMENT.[10.03.2014]. Mole People - Mick Garris Audio commentary.ac3
This would make sure that only that file is loaded and not also the audio commentary for, say, 'Monolith Monsters', etc.

I am not sure if this feature worked just coincidentally so nice or maybe Microsoft changed something !! However it seem to be broken now.
Autoload-external-audio only works now if the audio is named like the disc itself.
But this leads to problems as described above when commentary-tracks are loaded even if there are not meant for that movie !!
Can you maybe look into this again ? Thx !!

mclingo · 19th October 2018, 12:37

Hi, i've mentioned this a few times on here but never got a good answer or explanation as to whats going on.

When I start a movie with BE often there is a 10-20 second wait before you can skip, go to full screen or do anything without BE crashing, its like its buffering or something. Same movie starts and plays straight away on MPC-HC with identical settings regardless of whether i'm using internal or external filters, PCM or bitstreaming, MADVR or internal renderer.

What gives?

I've also noticed that recent version just wont work very well with MVC 3D at all using MADVR, sometimes I just get black screen and nothing, sometimes it plays top left corner of screen, sometimes I get HDMI loss, very unstable compare to MPC-HC, again with same external filter settings.

mkver · 19th October 2018, 15:05

I'm not a developer, but I think that they will want a bit more information from you:
Does the movie actually start playing right away with MPC-BE and is it just skipping/going to full screen that makes it crash when done at the beginning or does the movie actually take that long to start playing?
Does it just happen from time to time or does it happen reliably with the same files? Did you check whether it worked with MPC-HC after you tried MPC-BE and found out that it failed? (The reason for this question is that the OS has then probably cached the file that you want to read so that reading it a second time should be faster as it is from memory.)
What container format is it and what tracks are in the container? (A mediainfo would be nice, a sample that allows to reliably reproduce it even better.)

15th October 2018, 11:30	#5762 \| Link
Aleksoid1978 Registered User Join Date: Apr 2008 Location: Russia, Vladivostok Posts: 2,787	Try to increase "cashe time" in Acestream. Give me a link - i test. __________________ AMD Ryzen 5 3600 /GIGABYTE B450 Gaming X /Patriot 32Gb@3200 /Kingston 500Gb M.2 /RTX 4060 /Samsung U28R550UQI /OLED Philips 55OLED707 /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

15th October 2018, 13:31	#5767 \| Link
Aleksoid1978 Registered User Join Date: Apr 2008 Location: Russia, Vladivostok Posts: 2,787	I always use only internal filters. If bug using LAV - you are wrong thread __________________ AMD Ryzen 5 3600 /GIGABYTE B450 Gaming X /Patriot 32Gb@3200 /Kingston 500Gb M.2 /RTX 4060 /Samsung U28R550UQI /OLED Philips 55OLED707 /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

15th October 2018, 16:55	#5769 \| Link
alex1399 Registered User Join Date: Jun 2018 Posts: 56	TLTR, too much information ~ Please use simple English for conversation I can reproduce it. The dialog "Aber das ist voll gemein," appeared twice during specific operation: (1) playback until 11.5 sec (2) seek back to 11sec. Last edited by alex1399; 15th October 2018 at 17:26.

15th October 2018, 17:34	#5770 \| Link
mkver Registered User Join Date: May 2016 Posts: 197	Under certain circumstances subtitles are displayed twice. These circumstances are: If a cluster contains both a video keyframe as first video block and furthermore a subtitle block is contained in the cluster and if the subtitle block has a timestamp smaller than the cluster timestamp, then the subtitle block will be displayed twice when one seeks to the video keyframe. The reason seems to be: MPC-BE seeks to the block containing the video keyframe, looks at the cluster timestamp and if the cluster timestamp is higher than the timestamp of the subtitle block (the timestamp of the subtitle block is already known from the cues), then it falsely presumes that it has to seek to the subtitle block in order to get the subtitle block, because it simply presumes based upon the timestamps that the subtitle block was interleaved earlier. Therefore it reads the subtitle block twice: Once during the deliberate seek to the subtitle block and once during the normaling reading of the cluster the video keyframe is in. Therefore MPC-BE displays the subtitle block twice. Here is a sample; the two points were this happens are at about 10.4s and at about 17.4s. The cluster at 17.4s looks like this: Code: \|+ Cluster at 14810224 \| + Cluster timestamp: 00:00:17.487000000 at 14810242 \| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:17.487000000 at 14810246 \| + Frame with size 187790 at 14810254 \| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.310000000 at 14998044 \| + Frame with size 1792 at 14998051 \| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.407000000 at 14999843 \| + Frame with size 11750 at 14999850 \| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.342000000 at 15011600 \| + Frame with size 1792 at 15011607 \| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.347000000 at 15013399 \| + Frame with size 1645 at 15013406 \| + Block group at 15015051 \| + Block: track number 3, 1 frame(s), timestamp 00:00:17.350000000 at 15015053 \| + Frame with size 66 at 15015059 \| + Block duration: 00:00:03.200000000 at 15015125 \| + Simple block: track number 1, 1 frame(s), timestamp 00:00:17.367000000 at 15015129 \| + Frame with size 3113 at 15015136 \| + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:17.374000000 at 15018249 \| + Frame with size 1792 at 15018256 This file has been produced by ffmpeg and ffmpeg interleaves by dts, not pts. Therefore the file looks the way it does. Last edited by mkver; 15th October 2018 at 17:36.

16th October 2018, 01:12	#5771 \| Link
Aleksoid1978 Registered User Join Date: Apr 2008 Location: Russia, Vladivostok Posts: 2,787	mkver Test build - https://yadi.sk/d/MxiYP2HXvWCOJQ __________________ AMD Ryzen 5 3600 /GIGABYTE B450 Gaming X /Patriot 32Gb@3200 /Kingston 500Gb M.2 /RTX 4060 /Samsung U28R550UQI /OLED Philips 55OLED707 /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

15th October 2018, 11:12	#5761 \| Link
Razoola Registered User Join Date: May 2007 Posts: 454	I was trying to watch a NFL game last night useing the aceplayer stream option in MPC-BE. I had just installed the 4053 nightly build. However it just would not work and play the stream (error file not found reported after a few seconds in the players status bar). After going back to released build of MPC-BE (1.5.1) aceplayer started working. I did notice however that even with this version audio and video would go out of sync the longer a stream played. The stream worked fine using the player that comes with acestream. This is the first time I have tried to use MPC-BE to play acestreams and wondered if both of these issues are known in MPC-BE?

15th October 2018, 13:28	#5766 \| Link
huhn Registered User Join Date: Oct 2012 Posts: 7,926	maybe try the internal filter first. i mean this is the mpc-be thread not the lavfilter thread.

16th October 2018, 12:24	#5772 \| Link
mclingo Registered User Join Date: Aug 2016 Posts: 1,348	i dont think MPC-BE is summing audio channels correctly. I have 5.1.2, two front, two rear, center and sub plus two ATMOS front heights. MPC-BE using internal filters is summing my ATMOS heights to front left and right, if I use latest external LAV filters all is ok. __________________ LG OLED EF950-YAM RX-V685-RYZEN 3600 - 16GBRAM - WIN10 RX 5700 - https://www.videohelp.com/software/madVR/old-versions

16th October 2018, 12:33	#5773 \| Link
Aleksoid1978 Registered User Join Date: Apr 2008 Location: Russia, Vladivostok Posts: 2,787	5.1.2 PCM output don't support by Windows, it's not standart channel layout. If you bitstream track with Atmos extension - all audio handling do A/V reciver. __________________ AMD Ryzen 5 3600 /GIGABYTE B450 Gaming X /Patriot 32Gb@3200 /Kingston 500Gb M.2 /RTX 4060 /Samsung U28R550UQI /OLED Philips 55OLED707 /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215

16th October 2018, 23:07	#5775 \| Link
Aleksoid1978 Registered User Join Date: Apr 2008 Location: Russia, Vladivostok Posts: 2,787	mkver Thanks for samples. Test build - https://yadi.sk/d/ai6hM8QGJA0yIQ __________________ AMD Ryzen 5 3600 /GIGABYTE B450 Gaming X /Patriot 32Gb@3200 /Kingston 500Gb M.2 /RTX 4060 /Samsung U28R550UQI /OLED Philips 55OLED707 /Yamaha RX-V471 + NS-555 + NS-C444 + NS-333 + YST-SW215 Last edited by Aleksoid1978; 17th October 2018 at 00:29.

19th October 2018, 12:37	#5779 \| Link
mclingo Registered User Join Date: Aug 2016 Posts: 1,348	Hi, i've mentioned this a few times on here but never got a good answer or explanation as to whats going on. When I start a movie with BE often there is a 10-20 second wait before you can skip, go to full screen or do anything without BE crashing, its like its buffering or something. Same movie starts and plays straight away on MPC-HC with identical settings regardless of whether i'm using internal or external filters, PCM or bitstreaming, MADVR or internal renderer. What gives? I've also noticed that recent version just wont work very well with MVC 3D at all using MADVR, sometimes I just get black screen and nothing, sometimes it plays top left corner of screen, sometimes I get HDMI loss, very unstable compare to MPC-HC, again with same external filter settings. __________________ LG OLED EF950-YAM RX-V685-RYZEN 3600 - 16GBRAM - WIN10 RX 5700 - https://www.videohelp.com/software/madVR/old-versions

19th October 2018, 15:05	#5780 \| Link
mkver Registered User Join Date: May 2016 Posts: 197	I'm not a developer, but I think that they will want a bit more information from you: Does the movie actually start playing right away with MPC-BE and is it just skipping/going to full screen that makes it crash when done at the beginning or does the movie actually take that long to start playing? Does it just happen from time to time or does it happen reliably with the same files? Did you check whether it worked with MPC-HC after you tried MPC-BE and found out that it failed? (The reason for this question is that the OS has then probably cached the file that you want to read so that reading it a second time should be faster as it is from memory.) What container format is it and what tracks are in the container? (A mediainfo would be nice, a sample that allows to reliably reproduce it even better.)