Media Player Classic - BE Win32/x64

[BetA13]

Thanks for the reply :)

i did test around a bit and to me, 16bit does look better.. in some scenes, expecially animated cartoons etc, the banding is less then with 8bit.
So, i leave it at 16bit for now since it looks better to my eyes..

Thank you for the help...

have a nice evening guys..

[alex1399]

Hi,guys. I've found some MP4 container with a text track in Timed Text Format, sbtl Muxing mode, tx3g Codec ID,Default and not Forced. The timestamps seems to be messed up in MPC-BE, so I convert it into ass format. The playback is perfect. Then, I add the LAV Splitter Source in external filter to replace MPC MP4/MOV Source. The playback is perfect, too.
Is sample clip required for more investigation?

[Aleksoid1978]

Hi,guys. I've found some MP4 container with a text track in Timed Text Format, sbtl Muxing mode, tx3g Codec ID,Default and not Forced. The timestamps seems to be messed up in MPC-BE, so I convert it into ass format. The playback is perfect. Then, I add the LAV Splitter Source in external filter to replace MPC MP4/MOV Source. The playback is perfect, too.
Is sample clip required for more investigation?

Yes - upload same samples for test.

[alex1399]

Here it goes. https://www110.zippyshare.com/v/oQdqXxYz/file.html
The wrong situation is that some subtitles disappeared suddenly, some subtitles prolong too much, and others strange just like the sample clip.

[Aleksoid1978]

Ok, thanks.

[Aleksoid1978]

alex1399
Who say then LAV Source/ffmpeg/libavfilter correctly handle text subtitles in MOV/MP4 ? As i see - it's ignore sample duration and calculate : sample end time = next sample start time. I think it's incorrect. Internal Source use sample start time + duration to calculate end time.

[sneaker_ger]

But ffmpeg is correct, isn't it?
[stts: Decoding Time to Sample Box]
position = 3175014
size = 80
version = 0
flags = 0x000000
entry_count = 8
entry[0]
sample_count = 1
sample_delta = 33334
entry[1]
sample_count = 1
sample_delta = 3934000
entry[2]
sample_count = 1
sample_delta = 1466000
entry[3]
sample_count = 1
sample_delta = 2300000
entry[4]
sample_count = 1
sample_delta = 600000
entry[5]
sample_count = 1
sample_delta = 3360000
entry[6]
sample_count = 1
sample_delta = 3300000
entry[7]
sample_count = 1
sample_delta = 0
[stsc: Sample To Chunk Box]
position = 3175094
size = 28
version = 0
flags = 0x000000
entry_count = 1
entry[0]
first_chunk = 1
samples_per_chunk = 1
sample_description_index = 1
[stsz: Sample Size Box]
position = 3175122
size = 52
version = 0
flags = 0x000000
sample_size = 0 (variable)
sample_count = 8
entry_size[0] = 2
entry_size[1] = 2
entry_size[2] = 11
entry_size[3] = 41
entry_size[4] = 2
entry_size[5] = 47
entry_size[6] = 44
entry_size[7] = 2

https://i.imgur.com/g8a2zEd.png

I think it's a regression. Didn't happen with older MPC-BE. (Of course I just overwrote my old MPC-BE with the new nightly without writing down the revision. :o )

/edit:
At least 1.5.1 (build 2985) doesn't have the problem.

[alex1399]

I see, there are something tricky in the ffmpeg conversion. It should be four dialogs in the clip, but turns out to have 8 chunks. The four dialogs are:00:00:03,934 --> 00:00:05,400, 00:00:05,400 --> 00:00:07,700, 00:00:08,300 --> 00:00:11,660, and 00:00:11,660 --> 00:00:14,960.
Please read the subtitle packets info of the uncut video here https://www21.zippyshare.com/v/18bGYCpZ/file.html.

Despite that additional 0.033334 packets, the mov_text in ffmpeg simply adds many dummy packets so that each packet's end time = next packet's start time and each packet's start time + duration time = end time.

The start time is valid. The duration of each packet is ignored by LAV spliiter. I agree that the end time should be more robust against the case that next sample start time is larger than or not equal to current sample end time. If MPC-BE have worked well, maybe the duration handler of MP4/MOV Source was altered in the current version.

People using other player are complaining, too. I definitely need more information whether it is ffmpeg fault or not.

[Aleksoid1978]

alex1399
I found a mistake in code. Wait a fix.

[alex1399]

Thank you

[Razoola]

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]

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

[Razoola]

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]

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]

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]

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

[Aleksoid1978]

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

[mkver]

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:
https://i.imgur.com/kF80RDHl.jpg (https://i.imgur.com/kF80RDH.jpg)
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 (https://www.dropbox.com/s/i6cegn45f2t62ri/Double.Subtitles.mkv?dl=0) is the sample):

...
|+ 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 (https://www.dropbox.com/s/i6cegn45f2t62ri/Double.Subtitles.mkv?dl=0) 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:

|+ 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:

|+ 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


|+ 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:

|+ 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:

|+ 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]

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]

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 (https://www.dropbox.com/s/i6cegn45f2t62ri/Double.Subtitles.mkv?dl=0) 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:
|+ 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]

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

[mclingo]

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]

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]

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:

|+ 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 (https://www.dropbox.com/s/qq1zu90yrjqrnpp/Double.Subtitles.Small.Clusters.mkv?dl=0) is the file.

[Aleksoid1978]

mkver
Thanks for samples.

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

[mclingo]

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]

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]

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]

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]

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.)

[Klaus1189]

updated german translation (https://drive.google.com/file/d/1BWDt77wcVRd-RL5YRKhFFCVVgOQ5INAH/view?usp=sharing) :)

To check the length of the new translation, where is

STRING IDS_RECORD_START "Aufnahme"
STRING IDS_RECORD_STOP "Stopp"

in GUI?

[v0lt]

@Klaus1189
This is the translation for the button in the capture settings.
http://jpegshare.net/thumbs/33/60/3360306d99f6307a8eb1c851e2e4d380.jpg (http://jpegshare.net/33/60/3360306d99f6307a8eb1c851e2e4d380.png.html)

[beter]

Update for translation

https://www.sendspace.com/file/4rup10

[v0lt]

@beter
Thanks. Updated in r4082.
You can also look at r4081 (https://sourceforge.net/p/mpcbe/code/4081/).

[Klaus1189]

updated german translation (https://drive.google.com/file/d/1U61VjQ-7a7OKyidSlM1F1oTamBVYpLay/view?usp=sharing) :)
"Randomize the playlist"

[mkver]

I have just found out that MPC-BE is able to display teletext subtitles as text (and not in the rather ugly way teletext subtitles are usually shown). Great feature! But I think I have found three bugs; or rather two bugs in the teletext specific code and one limitation that may or may not be intentional:

1. The teletext specifications (https://www.etsi.org/deliver/etsi_i_ets/300700_300799/300706/01_60/ets_300706e01p.pdf) state in paragraph 12.2 that the colour attributes only extend until they are replaced by another colour attribute or the beginning of a new line/row. At the beginning of a line/row, "Alpha White" is the default. MPC-BE currently ignores this. Here (https://www.dropbox.com/s/lqyllcrvx3zlk7u/End.of.Row.Sample.ts?dl=0) is a sample. This matters with the first two subtitles of this sample. These screenshots show VLC at the left, MPC-BE with teletext subtitles in the middle and the DVBSUB subtitles (with MPC-BE) on the right:
https://i.imgur.com/WSwqVVMm.jpg (https://i.imgur.com/WSwqVVM.jpg) https://i.imgur.com/HCyJdF5m.jpg (https://i.imgur.com/HCyJdF5.jpg) https://i.imgur.com/pbTEh6im.jpg (https://i.imgur.com/pbTEh6i.jpg)

2. Section 12.2 of the standard also says that "unless operating in "Hold Mosaics" mode, each character space occupied by a spacing attribute is displayed as a SPACE." As far as I know, there is no reason to use mosaics in subtitles, so one can ignore this case. The bottom line is that e.g. the colour codes should not only affect the colours, but should also be displayed as a SPACE. Otherwise things like in the middle picures here can happen (left VLC, middle MPC-BE teletext, right MPC-BE DVBSUB):
https://i.imgur.com/FrthC3hm.jpg (https://i.imgur.com/FrthC3h.jpg) https://i.imgur.com/VmdjdSFm.jpg (https://i.imgur.com/VmdjdSF.jpg) https://i.imgur.com/4WKPIjem.jpg (https://i.imgur.com/4WKPIje.jpg)
https://i.imgur.com/W84jTSJm.png (https://i.imgur.com/W84jTSJ.png) https://i.imgur.com/SLCHFCHm.jpg (https://i.imgur.com/SLCHFCH.jpg) https://i.imgur.com/nH9JQPym.jpg (https://i.imgur.com/nH9JQPy.jpg)
https://i.imgur.com/WQgKz0Um.jpg (https://i.imgur.com/WQgKz0U.jpg) https://i.imgur.com/dT2Z5yEm.jpg (https://i.imgur.com/dT2Z5yE.jpg) https://i.imgur.com/8LkWWRcm.jpg (https://i.imgur.com/8LkWWRc.jpg)
The samples are here (https://www.dropbox.com/s/qd7k0ajiattggzm/Missing.Space.ts?dl=0), here (https://www.dropbox.com/s/rfbfzfqjadc8d9s/Missing.Space.2.ts?dl=0) and here (https://www.dropbox.com/s/qj31ix7cj2bswro/Missing.Space.3.ts?dl=0).
(By the way: You seem to have common ancestry with the ccextractor teletext module: It had this bug (https://github.com/CCExtractor/ccextractor/pull/930), too.)

3. As you might have already observed from the samples from 2., teletext subtitles and also other subtitles more generally sometimes contain leading whitespace for purposes of horizontal alignment. It seems that MPC-BE strips this away (not only when the subtitles originated from teletext). Would it be possible to add an option to respect the horizontal alignment?

[Aleksoid1978]

mkver
Thanks for testing and info.
1/2 - Fixed.
3 - it's text subtitles module limitation - trim all space.

[ryrynz]

WMAudio Decoder DMO has higher merit than LAV if I disable internal filters, it causes stuttering on seek and I must disable it in external filters so LAV decodes.
Is this merit set by MPC-BE? If so, can you place LAV with higher merit internally so there's no need to specify in BE to block it / add LAV Filters as Preferred? Thanks.

[Aleksoid1978]

WMAudio Decoder DMO has higher merit than LAV if I disable internal filters, it causes stuttering on seek and I must disable it in external filters so LAV decodes.
Is this merit set by MPC-BE? If so, can you place LAV with higher merit internally so there's no need to specify in BE to block it / add LAV Filters as Preferred? Thanks.

WMAudio Decoder DMO merit set by system. You ca manualy low it - use graphstudionext for it.

[Klaus1189]

I had to adjust one thing in translation. Now I like how it looks -> updated german translation (https://drive.google.com/file/d/1Gc4BXGipz5pH7LyJfF92pSpOlcLt5e20/view?usp=sharing) :)

[hubi73]

Hi Klaus,
can you set [STRING IDS_PLAYLIST_REMOVE "Wiedergabeliste ent&fernen"] to something like "Aus Wiedergabeliste entfernen". Because it does not remove the playlist, it only removes one item from the playlist.

[JarrettH]

A new BE this month? :cool:

[Klaus1189]

hubi73
Done.

updated german translation (https://drive.google.com/file/d/1WyZ_okfDAEjA82WdZY2dKGgKqLiC4dR8/view?usp=sharing)
I am also looking forward to a new stable release :)

[Grimsdyke]

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 !!

I don't know if it helps but I noticed that the informations for external audio are stored in the default.mpcpl, so after a simple re-start of the playback the external audio is still there !
But as soon as I re-load the disc it's gone and this happens even if I have activated write-protection for default.mpcpl !!

Oh by the way, I think it would be nice if BE would open directly the folder that I have specified for external audio in the settings.

[beter]

@beter
Thanks. Updated in r4082.
You can also look at r4081 (https://sourceforge.net/p/mpcbe/code/4081/).
Update:)
https://www.sendspace.com/file/xxh7hg

[hubi73]

@Klaus Thank you.

@Aleksoid
Thanks a lot for fixing the occasional crashes that occurred during youtube-playback with external LAV-Splitter-Source. (For some weeks now the nightlies run stable under these circumstances.)

[v0lt]

@Klaus1189, @beter
Thank you!
Updated in r4092.

[Klaus1189]

It is incredible - you can check the translation so many times, you will find one little issue later. Sorry but I had to update again to correct an old typo. Thank you Grimsdyke
If you or anybody else finds any other typo(s) let me know, I'll fix them all ;)

updated german translation (https://drive.google.com/file/d/1Fzq7YHFY5g1Wj33ZgfV6Mc1-Cf4clY4j/view?usp=sharing)

[Klaus1189]

v0lt
Thank you for r4097, I am almost ready for stable release. Should be finished in some minutes... optimizing translation, it must be perfect ;) ...

[Klaus1189]

optimized translation (https://drive.google.com/file/d/1xMRmB-FuRi1dGRDdsfPG-6M0rpOAyqM_/view?usp=sharing) for soon coming stable release :)

Now I don't annoy you anymore with so many small updates ;)