DGAVCDec 1.0.9 - Page 86

Guest · 3rd January 2009, 14:25

It's just hard 3:2 pulldown. You can use this script:

AVCSource("20080817152150.dga")
assumetff()
telecide()
decimate()

Further discussion about undoing pulldown should be taken to the Avisynth forum.

Turtleggjp · 6th January 2009, 04:19

Watch out using clips from that camera in DGAVCDecode. I know from personal experience that you're likely to run into some known artifact issues with the PAFF streams produced by it. The NV version does not have this problem, but requires a donation and an Nvidia card to use.

Chefkoch_ico · 6th January 2009, 09:20

Quote:

Originally Posted by Turtleggjp

Watch out using clips from that camera in DGAVCDecode. I know from personal experience that you're likely to run into some known artifact issues with the PAFF streams produced by it. The NV version does not have this problem, but requires a donation and an Nvidia card to use.

Thx for pointing this out. Donated already since I also need it for BluRay.

laserfan · 6th January 2009, 21:09

Quote:

Originally Posted by neuron2

...plays clean in DGAVCDecNV, so I conclude that it's a problem in the version of libavcodec that is used in DGAVCDec.

I don't understand all the issue(s) with libavcodec, but it seems from a casual look at the ffdshow changelogs that a lot of changes have been made since the date of the file you made for DGAVCDec. Might it be possible there's a better/newer version to use with DGAVCDec?

Feel free to shoot me if I'm completely off-base somehow.

Guest · 6th January 2009, 21:56

BANG! I've answered that several times.

There are regressions in functionality needed for random access that the developers appear to be uninterested in fixing, or which they consider to be too low in priority to ever get worked on.

I'll look again this evening at the status of the critical bug reports.

laserfan · 6th January 2009, 22:10

Quote:

Originally Posted by neuron2

BANG! I've answered that several times... I'll look again this evening at the status of the critical bug reports.

OWWWW! Yeah, I know--I read your many posts about this but I'm not smart enough to correlate ffdshow's change log entries to your issue (and didn't know how to seek the bug reports). Anyway thanks for looking again.

If no progress can be made I will try to be patient til my Nvidia system is done, after which you will be hearing from my banker, er, I mean PayPal, for the NV versions of your tools.

Guest · 6th January 2009, 22:59

The ffmpeg issue tracker appears to be down. Does anyone know anything about that?

canTsTop · 6th January 2009, 23:06

its down for me to, maybe svn log can be useful http://svn.ffmpeg.org/ffmpeg/trunk/libavcodec/?view=log

Guest · 6th January 2009, 23:47

Nah, I need the tracker to see if the known bugs have been addressed. Can't remember the bug numbers.

EDIT: I just built and tested ffmpeg16456. The bugs are still present.

laserfan · 7th January 2009, 01:25

Quote:

Originally Posted by neuron2

I just built and tested ffmpeg16456. The bugs are still present.

Thanks very much for your time.

komisar · 7th January 2009, 03:12

neuron2, can you describe ffmpeg-bug more detail?

Maybe we can solve this problem through joint efforts? ("we" -- Those who are interested in using dgavcdec; "solve" -- do make correct patch)

P.S. Oh, sorry for my bad English. I check translate.google.com

Guest · 7th January 2009, 03:23

When the issue tracker comes back up we can discuss it.

Quote:

Maybe we are solve this problem?

Can you translate this into understandable English, please? Who is "we"? What does "are solve" mean?

Atak_Snajpera · 7th January 2009, 22:05

Quote:

Maybe we are solve this problem?

Quote:

Can you translate this into understandable English, please? Who is "we"? What does "are solve" mean?

He made a mistake so what? I understand what he meant! Is that difficult to replace 'are' with 'can'???

MatMaul · 8th January 2009, 13:47

roundup is back

Guest · 8th January 2009, 15:12

Quote:

Originally Posted by MatMaul

roundup is back

Thank you for notifying us.

The killer for me is Issue 475.

https://roundup.mplayerhq.hu/roundup/ffmpeg/issue475

I have several files that do this. As upgrading is a big effort, I prefer to wait until this major issue in PAFF support is fixed. Note that after more than 6 months it is still unassigned.

MatMaul · 8th January 2009, 15:20

you mention regressions for random access, is it only for this kind of files (AVCHD) or is it an other issue ?

Guest · 8th January 2009, 15:43

Remaining PAFF bugs are the main issue. I don't know if it is just AVCHD.

The decoder is now returning orphaned B frames at the start, which it doesn't do in the older version I use. That's not strictly a regression and I can re-architect around that, as that is the way that the CUDA version works.

canTsTop · 8th January 2009, 16:56

i am not expert

, but if i understand correctly Issue 475 (https://roundup.mplayerhq.hu/roundup/ffmpeg/issue475) have problems with ffmpeg but not libavcodec. i had same problem with ffmpeg, Issue 721 (https://roundup.mplayerhq.hu/roundup/ffmpeg/issue721), but if play that sample in mpc+ffdshow there is no problems.

is there are any samples that current version of ffdshow cant decode correctly?

Guest · 8th January 2009, 17:04

That's very interesting!

I'll see if they play correctly using ffdshow. Is it ffdshow-tryout? Please tell me the exact version you are using.

If things are OK, I will upgrade from that code base.

canTsTop · 8th January 2009, 17:13

yes its ffdshow-tryout, i allways use latest version from here http://sourceforge.net/project/showf...ease_id=439904

now i heve ffdshow_rev2588 and have no problems with my dvb-t recordings

6th January 2009, 23:47	#1709 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	Nah, I need the tracker to see if the known bugs have been addressed. Can't remember the bug numbers. EDIT: I just built and tested ffmpeg16456. The bugs are still present. Last edited by Guest; 6th January 2009 at 23:51.

7th January 2009, 03:12	#1711 \| Link
komisar Registered User Join Date: Aug 2008 Location: Minsk, Belarus Posts: 235	neuron2, can you describe ffmpeg-bug more detail? Maybe we can solve this problem through joint efforts? ("we" -- Those who are interested in using dgavcdec; "solve" -- do make correct patch) P.S. Oh, sorry for my bad English. I check translate.google.com __________________ ..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::.. Last edited by komisar; 7th January 2009 at 03:33.

8th January 2009, 15:43	#1717 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	Remaining PAFF bugs are the main issue. I don't know if it is just AVCHD. The decoder is now returning orphaned B frames at the start, which it doesn't do in the older version I use. That's not strictly a regression and I can re-architect around that, as that is the way that the CUDA version works. Last edited by Guest; 8th January 2009 at 15:46.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

3rd January 2009, 14:25	#1701 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	It's just hard 3:2 pulldown. You can use this script: AVCSource("20080817152150.dga") assumetff() telecide() decimate() Further discussion about undoing pulldown should be taken to the Avisynth forum.

6th January 2009, 04:19	#1702 \| Link
Turtleggjp Registered User Join Date: Apr 2006 Posts: 225	Watch out using clips from that camera in DGAVCDecode. I know from personal experience that you're likely to run into some known artifact issues with the PAFF streams produced by it. The NV version does not have this problem, but requires a donation and an Nvidia card to use.

6th January 2009, 21:56	#1705 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	BANG! I've answered that several times. There are regressions in functionality needed for random access that the developers appear to be uninterested in fixing, or which they consider to be too low in priority to ever get worked on. I'll look again this evening at the status of the critical bug reports.

6th January 2009, 22:59	#1707 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	The ffmpeg issue tracker appears to be down. Does anyone know anything about that?

6th January 2009, 23:06	#1708 \| Link
canTsTop Registered User Join Date: Apr 2007 Location: Lithuania Posts: 120	its down for me to, maybe svn log can be useful http://svn.ffmpeg.org/ffmpeg/trunk/libavcodec/?view=log

8th January 2009, 13:47	#1714 \| Link
MatMaul Registered User Join Date: Apr 2004 Posts: 402	roundup is back

8th January 2009, 15:20	#1716 \| Link
MatMaul Registered User Join Date: Apr 2004 Posts: 402	you mention regressions for random access, is it only for this kind of files (AVCHD) or is it an other issue ?

8th January 2009, 16:56	#1718 \| Link
canTsTop Registered User Join Date: Apr 2007 Location: Lithuania Posts: 120	i am not expert , but if i understand correctly Issue 475 (https://roundup.mplayerhq.hu/roundup/ffmpeg/issue475) have problems with ffmpeg but not libavcodec. i had same problem with ffmpeg, Issue 721 (https://roundup.mplayerhq.hu/roundup/ffmpeg/issue721), but if play that sample in mpc+ffdshow there is no problems. is there are any samples that current version of ffdshow cant decode correctly?

8th January 2009, 17:04	#1719 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,907	That's very interesting! I'll see if they play correctly using ffdshow. Is it ffdshow-tryout? Please tell me the exact version you are using. If things are OK, I will upgrade from that code base.

8th January 2009, 17:13	#1720 \| Link
canTsTop Registered User Join Date: Apr 2007 Location: Lithuania Posts: 120	yes its ffdshow-tryout, i allways use latest version from here http://sourceforge.net/project/showf...ease_id=439904 now i heve ffdshow_rev2588 and have no problems with my dvb-t recordings