ffdshow tryouts project: Discussion & Development - Page 73

_xxl · 6th June 2007, 07:30

Quote:

And an interesting thing with MPC-ffdshow_h264decoding on a dualcore CPU (no further filters are applied with the test):
1. start a 720p-AVC content, and see the loads of CPU (at here, core1 is minimal, core2 is very high)
2. stop the playback (don't close MPC), then start the playback again, and see the CPU: at here, the 2 cores is almost the same.
Can somebody reproduce this?

http://forum.doom9.org/showthread.ph...944#post923944
http://forum.doom9.org/showthread.ph...950#post923950

chros · 6th June 2007, 10:11

Quote:

Originally Posted by drevil_xxl

http://forum.doom9.org/showthread.ph...944#post923944
http://forum.doom9.org/showthread.ph...950#post923950

Aha, I missed that, thanks.

Quote:

Originally Posted by foxyshadis

Try process explorer's single aggregate graph, in process properties. Or just set MPC's affinity to one CPU. You'll find the graphs are mostly stable, and all you're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.

I'll try this, but as I remember, for me it really affected the performance.

_xxl · 6th June 2007, 19:26

New test build:
http://rapidshare.com/files/35616997...6_xxl.exe.html
Patch:
http://lists.mplayerhq.hu/pipermail/...ne/030649.html

Works with:
http://www.moviemaze.de/media/traile...n-returns.html

1 core:
User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 337.4, dfps: 334.0

2 cores:
User: 3s, kernel: 0s, total: 3s, real: 7s, fps: 956.3, dfps: 463.3

http://www.moviemaze.de/media/traile...king-kong.html

1 core:
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 206.1, dfps: 200.6

2 cores:
User: 8s, kernel: 0s, total: 8s, real: 14s, fps: 433.2, dfps: 256.9

It doesn't work with h264 evob's.

http://samples.mplayerhq.hu/evob/Departed%20Trailer.EVO

and this:

http://rapidshare.com/files/35755611...ars.V.mkv.html

Keepitsimple · 6th June 2007, 21:26

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when..

fastplayer · 6th June 2007, 22:12

Slightly OT:
Am I the only one who has probs with SF's SVN? When I commit I get an error message that commit failed but the files are committed actually. And the changelog opens only after pressing the F5 button a hundred times...

_xxl · 6th June 2007, 22:16

The same for me.

clsid · 6th June 2007, 23:13

The commit issue only happens occasionally to me. The internal server error on the changelog page happens all the time. SF desperately needs extra server power. Or even better, make the webpages less bloated.

foxyshadis · 7th June 2007, 04:29

Quote:

Originally Posted by Keepitsimple

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when..

That's exactly what the post above yours is about:

Quote:

Originally Posted by drevil_xxl

New test build:
http://rapidshare.com/files/35616997...6_xxl.exe.html
Patch:
http://lists.mplayerhq.hu/pipermail/...ne/030649.html
It seems to me to be broken.

We're totally dependant on some of the ffmpeg gurus dealing with it. There isn't and will never be a "time frame", although at the moment it's getting much closer. There's no point in asking repeatedly here, the reply's always the same.

check · 7th June 2007, 05:07

Just a note to say that the h264 parallelisation going on there is slice level, which means unless the video was encoded with slices, you will see no benefit at all. I'm not sure how useful this will be in general, no HDVDs/BDs come with sliced video (afaik), and x264 does not slice anymore either.

Delerue · 7th June 2007, 05:49

Can someone confirm this bug, please?

fastplayer · 7th June 2007, 11:48

Quote:

Originally Posted by Delerue

I think that MPEG1 (both libavcodec and libmpeg2) decode is broken.

With ffdshow's libmpeg (rev1245) it plays fine and AR is correct. With ffdshow's libavcodec the AR is wrong (from the beginning) but no stutters at all.

Edit: AR is wrong with another MPEG1 file I have here when using ffdshow's libavcodec. If needed, I can upload it.

Leak · 7th June 2007, 12:44

Quote:

Originally Posted by fastplayer

And the changelog opens only after pressing the F5 button a hundred times...

Yeah, it's rare that you'll get an actual changelog via SF's web page nowadays.

Works much better when I use TortoiseSVN, though, as that bypasses the web server...

Sirber · 7th June 2007, 13:27

Quote:

Originally Posted by Keepitsimple

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when..

I've been waiting for ages for that! GREAT WORK!!!!!!!!!!!!!

[edit]

How do I set the number of decoding threads for H264?

_xxl · 7th June 2007, 14:15

Sirber · 7th June 2007, 14:32

Quote:

Originally Posted by drevil_xxl

Thanks!
The hint still says mpeg1/2 only

haruhiko_yamagata · 7th June 2007, 16:08

Quote:

Originally Posted by Delerue

I think that MPEG1 (both libavcodec and libmpeg2) decode is broken.

With libavcodec, the AR is wrong and stutters.
With libmpeg2, the AR is correct and stutters.
With MPS's libmpeg2, the AR is correct and stutters.
With Microsoft's, no problem.

How about droping libavcodec-MPEG 1/2?
The bug with libmpeg2 has to be fixed.

Delerue · 8th June 2007, 00:04

Quote:

Originally Posted by haruhiko_yamagata

With libavcodec, the AR is wrong and stutters.
With libmpeg2, the AR is correct and stutters.
With MPS's libmpeg2, the AR is correct and stutters.
With Microsoft's, no problem.

Thanks, man. Just to be clear, when you say 'MPS's libmpeg2' you mean 'MPC libmpeg2'? Sorry if I'm saying something wrong.

Quote:

Originally Posted by haruhiko_yamagata

How about droping libavcodec-MPEG 1/2? The bug with libmpeg2 has to be fixed.

Would be really great.

haruhiko_yamagata · 8th June 2007, 11:24

Quote:

Originally Posted by Delerue

Thanks, man. Just to be clear, when you say 'MPS's libmpeg2' you mean 'MPC libmpeg2'? Sorry if I'm saying something wrong.

Oops, it's a typo. MPC libmpeg2.

Nicholi · 9th June 2007, 09:48

Slight bug reportage and other musings.

This was mentioned once in the ancient ffdshow thread concerning tryouts. I'm not sure if it was resolved then or perhaps it wasn't broken at all at that time, but it seems to be now. Motion Vector visualizations are not showing up for divx, xvid, h.264 (and probably more) when lavc is used for decoding. I double checked with the latest clsid available (r1245) tests to be sure it wasn't my own builds. Someone else pointed this out to me (quite a long time ago, just never got around to reported it) and when I asked a few others they all said motion vectors weren't working either, but the other two visualizations are fine. This sounds almost identical to that old report but a few people were also reporting it worked fine. It seems to be working fine from milan's svn though, what could be the problem? Can anyone else confirm motion vectors are not showing up? I can bring a whole slew of hosers who can report it not working, perhaps we can figure out what the problem is.

Next subject... 7.1 audio, ugh

. Am I correct in assuming the mixing code is part of ffdshow, or is that from ffmpeg? Currently 7.1 audio passed through ffdshow gets all wonkified, not sure how to describe it. Its not as though certain channels are just lost or remapped incorrectly, it sounds totally weird. Has this already been discussed at length concerning ffdshow? Perhaps without going into the work of mixing combinations up to 8 channels a temporary fix could be used to just ignore the 2 new channels in 7.1? We could garnish samples from our friendly HD-DVD/BR consumers.

Last thing, which is just a minor inconvenience I've noticed and not that important but you might agree the functionality is a bit off. When you are mixing the audio and using a custom graph, the dropdown in mixing MUST be set to the number of output channels you desire. For example, if the source is 5.1 and the dropdown is set to '2/0 Stereo' it will not matter how many channels you have mapped to speakers in the custom graph, you will only get 2 channels out (L/R). I was thinking more along the lines that when a custom graph is used for mixing the option set in the dropdown should be ignored. Anyone else think the same? Obviously you catch on quickly when ffdshow displays only 2ch output, I think it would just make more sense from a usability perspective.

_xxl · 9th June 2007, 10:38

Quote:

Motion Vector visualizations are not showing up for divx, xvid, h.264 (and probably more) when lavc is used for decoding.

broken since:
ffdshow_rev1029_20070314

6th June 2007, 19:26	#1443 \| Link
_xxl ffdshow user Join Date: Oct 2005 Location: Romania Posts: 818	New test build: http://rapidshare.com/files/35616997...6_xxl.exe.html Patch: http://lists.mplayerhq.hu/pipermail/...ne/030649.html Works with: http://www.moviemaze.de/media/traile...n-returns.html 1 core: User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 337.4, dfps: 334.0 2 cores: User: 3s, kernel: 0s, total: 3s, real: 7s, fps: 956.3, dfps: 463.3 http://www.moviemaze.de/media/traile...king-kong.html 1 core: User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 206.1, dfps: 200.6 2 cores: User: 8s, kernel: 0s, total: 8s, real: 14s, fps: 433.2, dfps: 256.9 It doesn't work with h264 evob's. http://samples.mplayerhq.hu/evob/Departed%20Trailer.EVO and this: http://rapidshare.com/files/35755611...ars.V.mkv.html __________________ ffdshow \| MPC-HC \| Exetools \| Reverse Engineering Team Board Last edited by _xxl; 7th June 2007 at 14:26.

6th June 2007, 22:16	#1446 \| Link
_xxl ffdshow user Join Date: Oct 2005 Location: Romania Posts: 818	The same for me. __________________ ffdshow \| MPC-HC \| Exetools \| Reverse Engineering Team Board

6th June 2007, 23:13	#1447 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,647	The commit issue only happens occasionally to me. The internal server error on the changelog page happens all the time. SF desperately needs extra server power. Or even better, make the webpages less bloated. __________________ MPC-HC 2.2.1

7th June 2007, 05:07	#1449 \| Link
check phjbdpcrjlj2sb3h Join Date: Sep 2005 Location: Western Australia Posts: 1,691	Just a note to say that the h264 parallelisation going on there is slice level, which means unless the video was encoded with slices, you will see no benefit at all. I'm not sure how useful this will be in general, no HDVDs/BDs come with sliced video (afaik), and x264 does not slice anymore either. __________________ CCCP \| MeWiki \| techouse's x264 builds \| Kovensky's mplayer builds

7th June 2007, 14:15	#1454 \| Link
_xxl ffdshow user Join Date: Oct 2005 Location: Romania Posts: 818	__________________ ffdshow \| MPC-HC \| Exetools \| Reverse Engineering Team Board

6th June 2007, 21:26	#1444 \| Link
Keepitsimple Registered User Join Date: Jan 2007 Posts: 57	This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when..

6th June 2007, 22:12	#1445 \| Link
fastplayer Registered User Join Date: Nov 2006 Posts: 799	Slightly OT: Am I the only one who has probs with SF's SVN? When I commit I get an error message that commit failed but the files are committed actually. And the changelog opens only after pressing the F5 button a hundred times...

7th June 2007, 05:49	#1450 \| Link
Delerue Registered User Join Date: Jun 2005 Posts: 365	Can someone confirm this bug, please?

9th June 2007, 09:48	#1459 \| Link
Nicholi Registered User Join Date: Apr 2003 Location: Lancaster, CA Posts: 89	Slight bug reportage and other musings. This was mentioned once in the ancient ffdshow thread concerning tryouts. I'm not sure if it was resolved then or perhaps it wasn't broken at all at that time, but it seems to be now. Motion Vector visualizations are not showing up for divx, xvid, h.264 (and probably more) when lavc is used for decoding. I double checked with the latest clsid available (r1245) tests to be sure it wasn't my own builds. Someone else pointed this out to me (quite a long time ago, just never got around to reported it) and when I asked a few others they all said motion vectors weren't working either, but the other two visualizations are fine. This sounds almost identical to that old report but a few people were also reporting it worked fine. It seems to be working fine from milan's svn though, what could be the problem? Can anyone else confirm motion vectors are not showing up? I can bring a whole slew of hosers who can report it not working, perhaps we can figure out what the problem is. Next subject... 7.1 audio, ugh . Am I correct in assuming the mixing code is part of ffdshow, or is that from ffmpeg? Currently 7.1 audio passed through ffdshow gets all wonkified, not sure how to describe it. Its not as though certain channels are just lost or remapped incorrectly, it sounds totally weird. Has this already been discussed at length concerning ffdshow? Perhaps without going into the work of mixing combinations up to 8 channels a temporary fix could be used to just ignore the 2 new channels in 7.1? We could garnish samples from our friendly HD-DVD/BR consumers. Last thing, which is just a minor inconvenience I've noticed and not that important but you might agree the functionality is a bit off. When you are mixing the audio and using a custom graph, the dropdown in mixing MUST be set to the number of output channels you desire. For example, if the source is 5.1 and the dropdown is set to '2/0 Stereo' it will not matter how many channels you have mapped to speakers in the custom graph, you will only get 2 channels out (L/R). I was thinking more along the lines that when a custom graph is used for mixing the option set in the dropdown should be ignored. Anyone else think the same? Obviously you catch on quickly when ffdshow displays only 2ch output, I think it would just make more sense from a usability perspective.