Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th July 2011, 15:16   #13781  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
ehm, have you tried playing avc in m2ts container?
lags will be seen at once, e.g. video plays at half the speed, total desync, etc.
all options are set to defaults

this issue is confirmed by 3 users btw.
wOxxOm is offline   Reply With Quote
Old 9th July 2011, 15:39   #13782  |  Link
dwild
Registered User
 
Join Date: Sep 2006
Posts: 3
Quote:
Originally Posted by clsid View Post
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Nothing changes.

Quote:
Originally Posted by clsid View Post
Does it only happen with M2TS? MKV and MP4 are fine?
Every file that requires more than one cpu core to decode.
Looks like threading problem.
Quad-core cpu utilisation (same m2ts file):
builds 3904-3925 - 25-30%, lags.
build 3892 and earlier - 40%, no lags.

Last edited by dwild; 9th July 2011 at 15:43.
dwild is offline   Reply With Quote
Old 9th July 2011, 15:51   #13783  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.

Please point to a sample file I should test.

Also try builds in between 3892 and 3904.
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 9th July 2011, 16:09   #13784  |  Link
dwild
Registered User
 
Join Date: Sep 2006
Posts: 3
Quote:
Originally Posted by clsid View Post
I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.
It's an i7, I guess?

Quote:
Originally Posted by clsid View Post
Please point to a sample file I should test.
From previous quote - that doesn't matter. It's every .m2ts file.

Quote:
Originally Posted by clsid View Post
Also try builds in between 3892 and 3904.
Sorry, but I'm seeing only those two on your site, nothing in-between.
dwild is offline   Reply With Quote
Old 9th July 2011, 16:17   #13785  |  Link
wOxxOm
Oz of the zOo
 
Join Date: May 2005
Posts: 208
@clsid: any BD will do, however I sent you a 15s sample via pm (look at fps in MPC's Statistics pane)

p.s. also you should use a utility to slowdown speed of your CPU for testing purposes, or wait! there's a neat trick - rightclick a player process in Windows' TaskManager, select Affinity and set it to only 1 core. This way you'll be able to spot any problems at once.

and btw, you're not using DXVA, are you?

Last edited by wOxxOm; 9th July 2011 at 17:01.
wOxxOm is offline   Reply With Quote
Old 9th July 2011, 18:28   #13786  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
BD playback is smooth here. Even with a single thread. No DXVA.

Here are two other builds:
http://www.xvidvideo.ru/ffdshow-tryo...4-x86-x64.html
http://www.xvidvideo.ru/ffdshow-tryo...7-x86-x64.html
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 9th July 2011, 19:34   #13787  |  Link
dwild
Registered User
 
Join Date: Sep 2006
Posts: 3
Quote:
Originally Posted by clsid View Post
Here are two other builds:
...
They both lag.
So it was introduced in 3893 or 3894.
dwild is offline   Reply With Quote
Old 9th July 2011, 20:02   #13788  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
I have to agree that there seems to be a performance regression or a synchronization regression around revision 3888 or so with H.264 that comes up mostly with blu-ray streams (mpeg-ts, splitter doesn't seem to matter). Haven't done specific testing, but when building things on the 26th of June trunk HEAD seemed to already have the regression, and revision 3887 seemed to be alright (the libavcodec multithreading used in both cases). This seems to have been reported at the Japanese 2ch board as well (example).

Other than with just plain eyes, the difference can be seen by looking at the green and red lines on MPC-HC's stats output. 3887 and before might have had some sudden rises in the synch difference or whatever it shows, but with a revision affected by this regression the rises would be MUCH bigger. As the effects of this regression are seemingly overall smaller with newer CPUs (I'm on a 2.26GHz Penryn C2D), I would guess that the difference would be visible via this kind of output in case of no visible stutter.

Will try to build and test revision-by-revision later on.

MSVS2010 SP1, GCC 4.5.3
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 9th July 2011, 20:13   #13789  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=...a6218a016a3af5
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 9th July 2011, 21:09   #13790  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
Quote:
Originally Posted by clsid View Post
3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=...a6218a016a3af5
Re-built with that commit reverted, and it unfortunately was still stuttering all around the place.

Edit: the libavcodec/h264.c change, that is.
Edit2: I take my words back, same problem came up with mplayer2, and reverting that commit fixed it in there. Uploading a sample for BBB now.
__________________
[I'm human, no debug]

Last edited by JEEB; 9th July 2011 at 21:44.
JEEB is offline   Reply With Quote
Old 10th July 2011, 04:56   #13791  |  Link
PetitDragon
Registered User
 
Join Date: Sep 2006
Posts: 81
Quote:
Originally Posted by clsid View Post
You are the first to mention such problems.

What exactly do you mean with lag? A sync delay? Stuttering?
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Does it only happen with M2TS? MKV and MP4 are fine?
Hi clsid,

I mentioned the similar problem at 25th June. (http://forum.doom9.org/showthread.ph...05#post1510105)
PetitDragon is offline   Reply With Quote
Old 10th July 2011, 18:10   #13792  |  Link
ikarad
Registered User
 
Join Date: Apr 2008
Posts: 546
Quote:
Originally Posted by clsid View Post
3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=...a6218a016a3af5
How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.


Moreover i don't know if anybody works on sub renderer (which is still buggued) today but this problem is not yet corrected
https://sourceforge.net/tracker/inde...41&atid=867360
ikarad is offline   Reply With Quote
Old 10th July 2011, 19:24   #13793  |  Link
hoborg
Registered User
 
Join Date: Nov 2008
Posts: 454
Quote:
Originally Posted by clsid View Post
Canīt reproduce. Canīt fix. Sorry. Maybe someone else can.
Too bad
But here is video what happening.
Tested h.264 in mp4/m2ts/mkv container - all of them crash Graphstudio when deleting FFDshow DXVA decoder from graph.
No problem with FFDshow video decoder - tested on xvid AVI.
__________________
Working machine: Win10x64 + Intel Skull Canyon
My HTPC.

How to start with Bitcoin
hoborg is offline   Reply With Quote
Old 10th July 2011, 19:45   #13794  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
Quote:
Originally Posted by ikarad View Post
How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.
There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 10th July 2011, 20:23   #13795  |  Link
ikarad
Registered User
 
Join Date: Apr 2008
Posts: 546
Quote:
Originally Posted by clsid View Post
There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
I don't know what bug you told but I speak about sub renderer bugs (bug that I post the link above: here https://sourceforge.net/tracker/inde...41&atid=867360).

If you speak about ffdshow-mt, I never have bugs with ffdshow-mt since one or two year with blu-ray movies or anime in h264 (I stop at version 3614 (I only test briefly the next versions then I don't know if the next versions are buggued with ffdshow-mt).

Last edited by ikarad; 10th July 2011 at 20:27.
ikarad is offline   Reply With Quote
Old 10th July 2011, 20:41   #13796  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
Quote:
Originally Posted by clsid View Post
The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
Basically the cause was a fix to the threading code that could produce incorrect results with H.264 streams having slices:
Code:
// packets can sometimes contain multiple PPS/SPS
// e.g. two PAFF field pictures in one packet, or a demuxer which splits NALs strangely
// if so, when frame threading we can't start the next thread until we've read all of them
Cases NAL_IDR_SLICE and NAL_SLICE were added to it, to take sliced streams into mention (basically more stuff is done with slice-having streams [blu-ray specs mandate all level 4.1 blu-ray streams to have slices, f.ex.] before threads can continue/be started). Which is a valid fix.

Now, of course I have no idea if this fix actually touches us, as in -- is it needed in our use case of ffdshow-tryouts (probably is), but BBB answered my calls right away, and I gave him out a ~420MB sample that might help him develop something that not only fixes the borked cases, but also does less damage towards decoding capabilities with frame-based multithreading (slice-based multithreading is unaffected, as is single-threaded decoding).
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 10th July 2011, 21:09   #13797  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,642
You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?

Using slice-based threading on streams without slices will of course give crappy performance, so if we would ever use it it must be done conditionally.

Who is BBB btw?
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 10th July 2011, 21:53   #13798  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
Quote:
Originally Posted by clsid View Post
You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?
Will see in a momento... or tomorrow (today) after I get some sleep. Been a rather hectic weekend.

Quote:
Who is BBB btw?
Ronald S. Bultje's nickname on IRC, as I don't use the mailing list much (read: at all).
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 10th July 2011, 22:10   #13799  |  Link
ikarad
Registered User
 
Join Date: Apr 2008
Posts: 546
I don't know where I can post this thing but Ihave noticed that in the versions from xvidvideo.ru (icl12 and mvsc2010), deband filter doesn't work since several months. With versions from ffdshow site deband filter works well.
ikarad is offline   Reply With Quote
Old 11th July 2011, 12:17   #13800  |  Link
andybkma
Registered User
 
Join Date: Sep 2006
Posts: 212
Quote:
Originally Posted by clsid View Post

@andybkma
This is a splitter problem. It does not work properly with the standard MS splitter. The files play properly when forcing LAV Splitter as the source filter. Here is a Registry tweak for that:
Code:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.wmv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"
Ah, thanks for your kind response and advice, clisd. So ummm... just curious as to why ffdshow won't work properly with the standard MS Splitter for those vids? Were the vids encoded improperly by their makers or something like that? Unfortunately setting the LAV Splitter to split all my wmv content is a no go solution but is nice to know all the same
andybkma is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.