DGAVCDec 1.0.9 - Page 90

buzzqw · 19th March 2009, 11:36

i have a little problem decoding this stream

http://www.64k.it/andres/data/Varie/...gavcindex.h264 (30mb)

any help is appreciated

BHH

nm · 19th March 2009, 12:32

Looks like the old PAFF problem in the libavcodec version used in DGAVCDec. Not much you can do about it other than switch to DGAVCDecNV or fix the frame-accuracy problems that neuron2 is having with the current libavcodec.

buzzqw · 19th March 2009, 13:39

thanks nm

i own the license for DGAVCDecNV but users of my application no (and i suggest to buy it!

)

thanks again

BHH

Kurtnoise · 20th March 2009, 02:41

Don, speaking on this...

Quote:

Originally Posted by Neuron2

The libavcodec.dll shipped with DGAVCDec is a GPL binary. I built it from the
source code available here:

http://sourceforge.net/project/downl...ffdshow-tryout

I have made a small modification to return a different version string to
manage compatibility issues. This modification is available on request.

can we have access to this mod, please ?

Guest · 20th March 2009, 02:44

Already posted. Use search.

Kurtnoise · 20th March 2009, 02:52

aaa, got it...thanks.

Guest · 20th March 2009, 03:02

You found it faster than me. I just found it.

laserfan · 26th March 2009, 20:45

My new Q6600 computer is so fast that I've lately found myself watching it perform, and thought I might ask neuron2: is it normal, having done a Save Project on a h.264 es, that DGAVCIndexNV (and non-NV too AFAICT) will scream along for some thousands of frames, and then start behaving in a staccato fashion? Where it races along doing 300-400 frames in a second, then pause for maybe a half-second, then suddenly another 300-400 frames, etc. etc. until completion.

I thought it might be pausing to calculate bitrates perhaps but then as I watch it, that doesn't seem like that's what it's doing. And to look at Windows CPU utilization it does appear that it goes to zero, then 10%, zero, 10% etc. In the end I'm getting an average of 150-170fps.

Not a problem--just wondering it this is normal/expected behavior....? Guess I should go-back & try my old P4 again; maybe it's always worked this same way.

Rodger · 26th March 2009, 21:39

You are making a HUGE thinking error.

frames is not equal size!
The reading speed is limited by the bitrate / mass of data to be read.
Parts with higher bitrate will take longer than those with lower bitrate. As I have a Q9400s CPU @3,2Ghz I can tell, that even my super high speed WD Velociraptor-Raid is by FAR not able to feed the Intel-CPU quickly enough with data

That was already the case back then, when I used a C2D E8400@3,55Ghz.

Only thing I can imagine is, that higher cache usage of the program itself might improve speed.
But I have something in mind, that this was already tested some time ago. Well possibly newer systems require different settings.
Usually...reading the data in 1024Kb block sizes is already pretty perfect for most drives. And personally I don´t think huge cache sizes of 8Mb and more will do any trick to it.

@ Neuron: If you give out a test-version with variable cache sizes, I´d be helpful to test the perfect settings for newer quad core machines.

@ laserfan: Try out An Intel X25-M SSD , this surely will help speeding up

Guest · 26th March 2009, 21:59

I don't know and I'm not that interested to be honest.

I have a large buffer that gets refilled. Trying to tweak it is not interesting to me given all the other things on my list already.

But never say never.

laserfan · 26th March 2009, 23:38

Honestly my question was not re: improving speed--I was just wondering if the program's zoom-stop-zoom-stop behavior was normal. And I guess you have said "yes", or maybe you have just never noticed!

No matter then; must be "stopping" when the buffer fills. And it "screams along at the beginning" maybe cuz there's mostly black there at first. And I managed to post this accidently in the non-NV thread; tho AFAICT both versions work the same... :slinksaway:

Guest · 26th March 2009, 23:48

No need to slink. The start stop thing I've only seen on the NV builds. It never got high enough on my list to look at. I do know that the NV builds have a much bigger buffer to refill. Maybe after I merge them all, add program stream support to DGMPG, support multiple file loading. It's not broken but it could possibly be improved.

Egh · 13th April 2009, 04:41

@neuron2:

I have rather interesting case here with one m2ts file from bluray source. It has video stream which is fine, but also two other audio streams detected (LPCM 48KHz 2ch), however if I demux them they are empty. Length is normal but streams are filled with zeros

Splitters also have troubles with that m2ts, for instance Haali splitter doesn't detect audio streams at all, apparently. Any suggestions re what experiments I can do with the file to identify what can be wrong with it?

Revgen · 13th April 2009, 20:37

^You might want to post a sample for neuron2 to look at.

Guest · 13th April 2009, 20:56

Yes, indeed. Please post a link to an unprocessed source sample that can be used to duplicate your issue.

Egh · 14th April 2009, 18:38

Try this, 25mb cut from beginning. http://www.mediafire.com/?z4kzngyodty

Maybe this video doesn't really have any sound data, but both VLC and Haali splitter have troubles with it regarding these two additional tracks. VLC considers them to be video (???) and Haali doesn't detect them at all apparently.

Guest · 14th April 2009, 20:10

It seems to be just blank audio going with some kind of intro video. Is there audio present when you play this section of the BD?

Egh · 14th April 2009, 21:14

Quote:

Originally Posted by neuron2

It seems to be just blank audio going with some kind of intro video. Is there audio present when you play this section of the BD?

I cannot play it :shy: This is separate intro yes, it is not in the main m2ts file. And yes, this file raised suspicions because both Haali and VLC have troubles with additional tracks. Still puzzled why two blank audiotracks were added to that file.... Main m2ts file contains two audiotracks as well, but they are not blank....

halsboss · 18th April 2009, 15:08

Just checking:

Quote:

1. Only AVC/H.264 elementary (raw) and transport streams can be opened

means it doesn't process mpeg4-ASP streams, doesn't it ? Is there a DGsomething for mpeg4-ASP ?

Guest · 18th April 2009, 15:10

Nope. Use DirectShowSource() or DSS2().

19th March 2009, 11:36	#1781 \| Link
buzzqw HDConvertToX author Join Date: Nov 2003 Location: Cesena,Italy Posts: 6,552	i have a little problem decoding this stream http://www.64k.it/andres/data/Varie/...gavcindex.h264 (30mb) any help is appreciated BHH __________________ HDConvertToX: your tool for BD backup MultiX264: The quick gui for x264 AutoMen: The Mencoder GUI AutoWebM: supporting WebM/VP8

19th March 2009, 13:39	#1783 \| Link
buzzqw HDConvertToX author Join Date: Nov 2003 Location: Cesena,Italy Posts: 6,552	thanks nm i own the license for DGAVCDecNV but users of my application no (and i suggest to buy it! ) thanks again BHH __________________ HDConvertToX: your tool for BD backup MultiX264: The quick gui for x264 AutoMen: The Mencoder GUI AutoWebM: supporting WebM/VP8

26th March 2009, 21:39	#1789 \| Link
Rodger Registered User Join Date: Dec 2001 Location: Viersen, Germany Posts: 270	You are making a HUGE thinking error. frames is not equal size! The reading speed is limited by the bitrate / mass of data to be read. Parts with higher bitrate will take longer than those with lower bitrate. As I have a Q9400s CPU @3,2Ghz I can tell, that even my super high speed WD Velociraptor-Raid is by FAR not able to feed the Intel-CPU quickly enough with data That was already the case back then, when I used a C2D E8400@3,55Ghz. Only thing I can imagine is, that higher cache usage of the program itself might improve speed. But I have something in mind, that this was already tested some time ago. Well possibly newer systems require different settings. Usually...reading the data in 1024Kb block sizes is already pretty perfect for most drives. And personally I don´t think huge cache sizes of 8Mb and more will do any trick to it. @ Neuron: If you give out a test-version with variable cache sizes, I´d be helpful to test the perfect settings for newer quad core machines. @ laserfan: Try out An Intel X25-M SSD , this surely will help speeding up Last edited by Rodger; 26th March 2009 at 21:52. Reason: corrections / additions

26th March 2009, 21:59	#1790 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	I don't know and I'm not that interested to be honest. I have a large buffer that gets refilled. Trying to tweak it is not interesting to me given all the other things on my list already. But never say never. Last edited by Guest; 26th March 2009 at 22:03.

13th April 2009, 20:37	#1794 \| Link
Revgen Registered User Join Date: Sep 2004 Location: Near LA, California, USA Posts: 1,545	^You might want to post a sample for neuron2 to look at. __________________ Pirate: Now how would you like to die? Would you like to have your head chopped off or be burned at the stake? Curly: Burned at the stake! Moe: Why? Curly: A hot steak is always better than a cold chop.

19th March 2009, 12:32	#1782 \| Link
nm Registered User Join Date: Mar 2005 Location: Finland Posts: 2,641	Looks like the old PAFF problem in the libavcodec version used in DGAVCDec. Not much you can do about it other than switch to DGAVCDecNV or fix the frame-accuracy problems that neuron2 is having with the current libavcodec.

20th March 2009, 02:44	#1785 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	Already posted. Use search.

20th March 2009, 02:52	#1786 \| Link
Kurtnoise Swallowed in the Sea Join Date: Oct 2002 Location: Aix-en-Provence, France Posts: 5,191	aaa, got it...thanks.

20th March 2009, 03:02	#1787 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	You found it faster than me. I just found it.

26th March 2009, 20:45	#1788 \| Link
laserfan Aging Video Hobbyist Join Date: Dec 2004 Location: Off the Map Posts: 2,461	My new Q6600 computer is so fast that I've lately found myself watching it perform, and thought I might ask neuron2: is it normal, having done a Save Project on a h.264 es, that DGAVCIndexNV (and non-NV too AFAICT) will scream along for some thousands of frames, and then start behaving in a staccato fashion? Where it races along doing 300-400 frames in a second, then pause for maybe a half-second, then suddenly another 300-400 frames, etc. etc. until completion. I thought it might be pausing to calculate bitrates perhaps but then as I watch it, that doesn't seem like that's what it's doing. And to look at Windows CPU utilization it does appear that it goes to zero, then 10%, zero, 10% etc. In the end I'm getting an average of 150-170fps. Not a problem--just wondering it this is normal/expected behavior....? Guess I should go-back & try my old P4 again; maybe it's always worked this same way.

26th March 2009, 23:38	#1791 \| Link
laserfan Aging Video Hobbyist Join Date: Dec 2004 Location: Off the Map Posts: 2,461	Honestly my question was not re: improving speed--I was just wondering if the program's zoom-stop-zoom-stop behavior was normal. And I guess you have said "yes", or maybe you have just never noticed! No matter then; must be "stopping" when the buffer fills. And it "screams along at the beginning" maybe cuz there's mostly black there at first. And I managed to post this accidently in the non-NV thread; tho AFAICT both versions work the same... :slinksaway:

26th March 2009, 23:48	#1792 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	No need to slink. The start stop thing I've only seen on the NV builds. It never got high enough on my list to look at. I do know that the NV builds have a much bigger buffer to refill. Maybe after I merge them all, add program stream support to DGMPG, support multiple file loading. It's not broken but it could possibly be improved.

13th April 2009, 04:41	#1793 \| Link
Egh Registered User Join Date: Jun 2005 Posts: 630	@neuron2: I have rather interesting case here with one m2ts file from bluray source. It has video stream which is fine, but also two other audio streams detected (LPCM 48KHz 2ch), however if I demux them they are empty. Length is normal but streams are filled with zeros Splitters also have troubles with that m2ts, for instance Haali splitter doesn't detect audio streams at all, apparently. Any suggestions re what experiments I can do with the file to identify what can be wrong with it?

13th April 2009, 20:56	#1795 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	Yes, indeed. Please post a link to an unprocessed source sample that can be used to duplicate your issue.

14th April 2009, 18:38	#1796 \| Link
Egh Registered User Join Date: Jun 2005 Posts: 630	Try this, 25mb cut from beginning. http://www.mediafire.com/?z4kzngyodty Maybe this video doesn't really have any sound data, but both VLC and Haali splitter have troubles with it regarding these two additional tracks. VLC considers them to be video (???) and Haali doesn't detect them at all apparently.

14th April 2009, 20:10	#1797 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	It seems to be just blank audio going with some kind of intro video. Is there audio present when you play this section of the BD?

18th April 2009, 15:10	#1800 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	Nope. Use DirectShowSource() or DSS2().