Media Player Classic - BE Win32/x64

[Aleksoid1978]

Version 1.5.3 (build 4455) beta

A few settings tried
https://imgur.com/a/EgG4AhK

Filtros externos = external filters

I changed that area by adding LAV and selecting PREFER, but that didn't help, still crackling.

Try reset settings and delete all external filters. Just for test.

P.S. Check on latest SVN - https://yadi.sk/d/hlf1lfC8mKU58/!_last

[Perenista]

Try reset settings and delete all external filters. Just for test.I was looking for this and couldn't find (reset to factory settings). Where should I go?

[Aleksoid1978]

I was looking for this and couldn't find (reset to factory settings). Where should I go?

Options -> Miscellaneous -> Settings management

[Grimsdyke]

I love the dual-audio out feature of BE !! But unfortunately I do need much more gain on HDMI (=> connected to TV) than on 5.1-Analog (=> connected to Amplifier).
Would it be possible to add a second slider so that gain could be adjusted independently ?

[Aleksoid1978]

I love the dual-audio out feature of BE !! But unfortunately I do need much more gain on HDMI (=> connected to TV) than on 5.1-Analog (=> connected to Amplifier).
Would it be possible to add a second slider so that gain could be adjusted independently ?

Volume slider ?? If so - not.

[Manni]

I love the dual-audio out feature of BE !! But unfortunately I do need much more gain on HDMI (=> connected to TV) than on 5.1-Analog (=> connected to Amplifier).
Would it be possible to add a second slider so that gain could be adjusted independently ?

If you need more volume on HDMI it could be because you are converting to LPCM before sending to the AVR. If it's an option in your setup, try to bitstream audio over HDMI, volume tends to be higher in that case. But then of course you have no volume control from MPC.

[Grimsdyke]

@Aleksoid. I mean: Options -> Audio -> Sound Processing -> Volume Control -> GAIN. Would need one slider for each audio out.
@Manni. Thanx, I will check that.

[Aleksoid1978]

Dual audio not working for bitstreaming + PCM output.

Only bitstream or PCM

[Grimsdyke]

Bitstreaming over HDMI seem to be not louder on my equipment.

[Manni]

Bitstreaming over HDMI seem to be not louder on my equipment.

It's not always the case, but it was worth checking :)

[beter]

Update for translation of Chinese traditional and Dutch
https://www.sendspace.com/file/x1lt1i

[Anima123]

Using recent mpc-be builds (till 4455, didn't test latest), the progress bar will not appear for a while after starting playback the video, and certainly not be able to enter full-screen mode by Alt-Enter.

[mkver]

DVBSUB subtitles are usually displayed until the next subtitle packet (often an empty subtitle that just says "Stop displaying the previous subtitles") is due for display. If a file does not contain these end-of-display subtitles, MPC-BE crashes. Such files can be produced by e.g. splitting files with mkvmerge. It doesn't seem to matter whether the DVBSUB packet (in Matroska) is in a SimpleBlock or a BlockGroup with an explicit nonzero duration or a BlockGroup with a zero duration. Here (https://www.dropbox.com/s/cp0i7s6f198l30m/DVBSUB.Zero.Duration.mkv?dl=0), here (https://www.dropbox.com/s/vkkeqp5lxds4dof/DVBSUB.Nonzero.Duration.mkv?dl=0) and here (https://www.dropbox.com/s/hq8mtspzrq47cy6/DVBSUB.SimpleBlock.mkv?dl=0) are samples for this. I can sometimes produce crashes if I am near the end of a transport stream with DVBSUBs as active subtitles, so this doesn't seem to be limited to Matroska, although it is not so easy to reproduce the crash there.

(If a DVBSUB in a BlockGroup has a nonzero duration, then actually this should be used as the duration; it should override the duration implied by the next subtitle packet. (The reason I am treating a BlockGroup with a zero duration specially is that FFmpeg has a bug in that it writes duration zero if the duration is unknown.))

[Arm3nian]

If I seek before a file starts to play initially, MPC-BE stops responding. Same if I seek a second time too quickly after the first one. Turning off wait for render queue in madVR makes it better, but it still crashes. This has been happening ever since the UI change. I've tried nightlies of MPC-BE and LAV for a month but it does the same thing.

Also, before the UI change, if I had 2 screens connected, and I switched the file to fullscreen, and pulled the display plug on one of them, it would automatically continue playing on the other display. Doesn't do that anymore.

[Aleksoid1978]

DVBSUB subtitles are usually displayed until the next subtitle packet (often an empty subtitle that just says "Stop displaying the previous subtitles") is due for display. If a file does not contain these end-of-display subtitles, MPC-BE crashes. Such files can be produced by e.g. splitting files with mkvmerge. It doesn't seem to matter whether the DVBSUB packet (in Matroska) is in a SimpleBlock or a BlockGroup with an explicit nonzero duration or a BlockGroup with a zero duration. Here (https://www.dropbox.com/s/cp0i7s6f198l30m/DVBSUB.Zero.Duration.mkv?dl=0), here (https://www.dropbox.com/s/vkkeqp5lxds4dof/DVBSUB.Nonzero.Duration.mkv?dl=0) and here (https://www.dropbox.com/s/hq8mtspzrq47cy6/DVBSUB.SimpleBlock.mkv?dl=0) are samples for this. I can sometimes produce crashes if I am near the end of a transport stream with DVBSUBs as active subtitles, so this doesn't seem to be limited to Matroska, although it is not so easy to reproduce the crash there.

(If a DVBSUB in a BlockGroup has a nonzero duration, then actually this should be used as the duration; it should override the duration implied by the next subtitle packet. (The reason I am treating a BlockGroup with a zero duration specially is that FFmpeg has a bug in that it writes duration zero if the duration is unknown.))

Thanks - fixed.

[Aleksoid1978]

If I seek before a file starts to play initially, MPC-BE stops responding. Same if I seek a second time too quickly after the first one. Turning off wait for render queue in madVR makes it better, but it still crashes. This has been happening ever since the UI change. I've tried nightlies of MPC-BE and LAV for a month but it does the same thing.

Also, before the UI change, if I had 2 screens connected, and I switched the file to fullscreen, and pulled the display plug on one of them, it would automatically continue playing on the other display. Doesn't do that anymore.

1 - reset settings.
2 - try without LAV and madVR.

[Anima123]

Using recent mpc-be builds (till 4455, didn't test latest), the progress bar will not appear for a while after starting playback the video, and certainly not be able to enter full-screen mode by Alt-Enter.

Just tried the latest nightly and found the problem has gone. Thanks a lot!

[mkver]

Thanks - fixed.
Works fine in 4466. Thanks.

[Klaus1189]

Thank you very much for 1.5.3 :)

[v0lt]

MPC-BE 1.5.3 (build 4488) stable (https://sourceforge.net/projects/mpcbe/files/MPC-BE/Release%20builds/1.5.3/)

MPC-BE 1.5.4 Nightly builds: main file store (https://yadi.sk/d/hlf1lfC8mKU58), alternative (https://yadi.sk/d/r7JYQ2NjHvE4lA)
Also new and old versions can be found on VideoHelp.com (https://www.videohelp.com/software/MPC-BE).

[filler56789]

MPC-BE 1.5.3 (build 4488) stable (https://sourceforge.net/projects/mpcbe/files/MPC-BE/Release%20builds/1.5.3/)

:thanks:

[chros]

Thanks guys, I'll start to use it during the next couple of days and report back :)

[ryrynz]

Very nice release. Excellent work.

[GCRaistlin]

Is there any chance that these feature requests (http://forum.doom9.org/showpost.php?p=1865267&postcount=6073) will be implemented?

[JarrettH]

What is new or fixed in 1.5.3?:confused:

Edit-found it in the log the installer comes with

[Aleksoid1978]

Info about release on first page of this thread :)

[v0lt]

What is new or fixed in 1.5.3?:confused:

Edit-found it in the log the installer comes with
https://sourceforge.net/p/mpcbe/code/HEAD/tree/tags/release_1.5.3/docs/Changelog.txt

[Manni]

Thanks for the new version, keep up the good work!

[P.J]

I have a video file that MPC-BE can't play it unless I add LAV+Splitter Source as external filter :confused:

General
Format : MPEG-4
Commercial name : DVCPRO HD
Format profile : QuickTime
Codec ID : qt 2005.03 (qt )
File size : 1.23 GiB
Duration : 3 min 42 s
Overall bit rate : 47.6 Mb/s
Encoded date : UTC 2006-12-23 23:14:13
Tagged date : UTC 2007-08-22 07:25:41
Writing library : Apple QuickTime

Video
ID : 4
Format : DV
Commercial name : DVCPRO HD
Codec ID : dvhp
Duration : 3 min 42 s
Bit rate mode : Constant
Bit rate : 46.0 Mb/s
Width : 1 280 pixels
Original width : 960 pixels
Clean aperture width : 936 pixels
Height : 720 pixels
Clean aperture height : 702 pixels
Display aspect ratio : 2.40:1
Original display aspect ratio : 16:9
Clean aperture display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 59.940 (59940/1000) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Scan type : Progressive
Original scan type : Interlaced
Original scan order : Bottom Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 2.083
Time code of first frame : 00:00:00:00
Time code source : Subcode time code
Stream size : 1.19 GiB (97%)
Language : English
Encoded date : UTC 2007-08-22 07:25:41
Tagged date : UTC 2007-08-22 07:25:41
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[SeeMoreDigital]

I have a video file that MPC-BE can't play it unless I add LAV+Splitter Source as external filter :confused:

Playing DV (Digital Video) within an Apple container on a Windows computer can be a bit 'hit and miss' at the best of times. Have you tried re-muxing to the MKV container?

[P.J]

Playing DV (Digital Video) within an Apple container on a Windows computer can be a bit 'hit and miss' at the best of times. Have you tried re-muxing to the MKV container?

I have many DV videos with mov container that play fine except this one.
LAV+Splitter Source plays it fine too.

[SeeMoreDigital]

I have many DV videos with mov container that play fine except this one.
LAV+Splitter Source plays it fine too.It's not a regular DV file it's a DVCPRO HD file with 4:2:2 chroma sub-sampling. It's most likely 10-bit too...

[Aleksoid1978]

Upload some files.

[P.J]

Upload some files.

Here you are: https://drive.google.com/open?id=14YuBH6_eYf_tz27-T3_70G2pM6n-PDCn

[SeeMoreDigital]

Here you are: https://drive.google.com/open?id=14YuBH6_eYf_tz27-T3_70G2pM6n-PDCnIt appears that the DVPRO HD sample contains some damaged frames between 5017-5023...

[Aleksoid1978]

Here you are: https://drive.google.com/open?id=14YuBH6_eYf_tz27-T3_70G2pM6n-PDCn

Thanks - fixed.

[P.J]

Thanks - fixed.

:thanks:

[tormento]

Is it only me or the latest versions get lot of time when launching?

[Klaus1189]

Which latest versions? Latest stable or latest nightlies?

[ryrynz]

Is it only me or the latest versions get lot of time when launching?

I don't get why you just didn't download the stable 1.5.3 release and just test for yourself. Nobody has mentioned anything and most of us use SSDs so many apps are basically instant.

[tormento]

I don't get why you just didn't download the stable 1.5.3 release and just test for yourself. Nobody has mentioned anything and most of us use SSDs so many apps are basically instant.
Downloaded both stable and nightly. Same effect. Tried to delete every .ini and other setting and at first launch it's almost instant, from the second, when settings are saved, get slower. I have 2 Samsung 850 Pro here, so storage is not the bottleneck.

[Aleksoid1978]

Is it only me or the latest versions get lot of time when launching?

Only for you.

[Qotscha]

Is it only me or the latest versions get lot of time when launching?

Same thing for me too. Tested nightlies (x64) and 1.5.3.4373 (https://yadi.sk/d/hlf1lfC8mKU58/1.5.3.4373) seems to be the last build launching practically instantly. Builds starting from 1.5.3.4378 (https://yadi.sk/d/hlf1lfC8mKU58/1.5.3.4378) take several seconds.

[tormento]

Same thing for me too.
Thanks for the working version hint.

I confirm it is opening instantly for me too (x64 version).

[lvqcl]

1.5.4.4508: startup time < 1 second.

[BetA13]

hy all,

i have a little problem with Subtitles in h265 Files..
they allways display in White and default size, if try to change anything in the Standart style, lets say color to red, it doesnt change it, same with the Size.
Using the standart internal subtitle renderer in MPC BE..

With h264 Files it does work like it should..

is there a reason for that? maybe a limitation of some sort?

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

Use Standart style is enabled..


or should i use a different subtitle renderer? If yes, wich would be recommend?

Thanks..

[ryrynz]

1.5.4.4508: startup time < 1 second.But do you have the slow startup on the build stated (4378)?

[Aleksoid1978]

hy all,

i have a little problem with Subtitles in h265 Files..
they allways display in White and default size, if try to change anything in the Standart style, lets say color to red, it doesnt change it, same with the Size.
Using the standart internal subtitle renderer in MPC BE..

With h264 Files it does work like it should..

is there a reason for that? maybe a limitation of some sort?

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

Use Standart style is enabled..


or should i use a different subtitle renderer? If yes, wich would be recommend?

Thanks..

Subtitles style work only for text's subs. As i see on screen - it's PGS or VOBSUB subtitle. Show MediaInfo for this file.

[BetA13]

Media Info - Subtitles part:

Text
ID : 3
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 3 min 37 s
Bit rate : 48.6 kb/s
Count of elements : 128
Stream size : 1.26 MiB (1%)
Title : Uncle.Buck.1989.x265
Language : English
Default : No
Forced : No


Looks like PGS..
So, with an seperate external subtitle this would work? like srt? etc...

And for vobsubs, would there be another way to modify the subs? as in using a different subtitle renderer?

sorry for the questions, but i never really used subtitles, wich i do now increasingly..

Thanks for the Help :)

[Qotscha]

But do you have the slow startup on the build stated (4378)?
Every build (or at least 1.5.3 stable, 1.5.4.4508, and a couple of others I tested) since 4378 seems to take significantly longer time to start compared to 4373 (~5 s vs ~0.5 s). So probably there is something in commits 4374 - 4378 which has an effect on startup times at least for me and tormento.

I looked at these commits and there seems to be quite a lot of code changes in 4374 (https://sourceforge.net/p/mpcbe/code/4374/) "Change: Transfer code from branches / playlist to the main branch." (Google translation). The other commits include changes to PlaylistNameDlg.cpp/.h introduced in 4374.