DGAVCDec 1.0.9

[Guest]

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]

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]

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]

...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. :scared:

[Guest]

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]

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]

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

[canTsTop]

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

[Guest]

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]

I just built and tested ffmpeg16456. The bugs are still present.Thanks very much for your time. :o

[komisar]

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]

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

Maybe we are solve this problem?

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

[Atak_Snajpera]

Maybe we are solve this problem?
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]

roundup is back :)

[Guest]

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]

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

[Guest]

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]

i am not expert :confused:, 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]

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]

yes its ffdshow-tryout, i allways use latest version from here http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=439904

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

[laserfan]

I didn't know there was a difference in libavcodec versions between ffdshow-tryout and ffmpeg. FWIW it was ffdshow-tryouts that has changed so much lately that I was inspired to ask in the first place...

[sneaker_ger]

I wanted to use the cli of DGAVCIndex with a batch file (under Windows XP) using the "for" command, but instead of doing it one by one all instances of DGAVCIndex run at the same time. Any way to change that behavior?

[rebkell]

I wanted to use the cli of DGAVCIndex with a batch file (under Windows XP) using the "for" command, but instead of doing it one by one all instances of DGAVCIndex run at the same time. Any way to change that behavior?

try putting start "" /WAIT in front the DGAVCDec command line, do a help start from the cmd window and check out all the options there.

[sneaker_ger]

try putting start "" /WAIT in front the DGAVCDec command line, do a help start from the cmd window and check out all the options there.

thx, worked just fine.

[laserfan]

I've been experiencing seemingly random frame corruptions in some of my 2-pass x264 encodings, which might occur only a couple of times in a 200,000 frame movie. In the most recent, I found just one instance of bad frames (7 of them) which occur after what appears to be an incorrect I-frame placement, i.e. the nearest I-frame was the frame immediately PRIOR to the scene change, and the first-thru-seventh frames into the new scene are (decreasingly) corrupt. I've uploaded 9 frames here (I-frame, seven bad, last good) (http://www.mediafire.com/file/nnzdz2lmmnk/IBBPBBBPB.7z). To my eye it looks like the 2nd frame includes elements of the first frame (the grey locker door in the background).

Here's what I'd done:

1. Use DGAVCindex to make a .dga file from the original h264 video
2. Make an .avs w/DGDecode & AVCSource as input to x264
3. Make a two-pass x264 encoding, which yielded corruption at frames 155597-155603

Excerpt of the stats file from Pass 1:

in:155594 out:155595 type:b q:26.00 tex:65746 mv:15608 misc:5878 imb:693 pmb:1743 smb:5724 d:s;
in:155596 out:155596 type:I q:22.04 tex:1547034 mv:348958 misc:544 imb:8160 pmb:0 smb:0 d:s;
in:155599 out:155597 type:P q:27.80 tex:31803 mv:9705 misc:5412 imb:138 pmb:1668 smb:6354 d:s;
in:155597 out:155598 type:b q:30.00 tex:2809 mv:4908 misc:3091 imb:21 pmb:627 smb:7512 d:s;
in:155598 out:155599 type:b q:30.00 tex:3431 mv:5321 misc:2952 imb:36 pmb:645 smb:7479 d:s;
in:155603 out:155600 type:P q:26.98 tex:54207 mv:14962 misc:6935 imb:132 pmb:2988 smb:5040 d:s;
in:155600 out:155601 type:b q:30.00 tex:4579 mv:5640 misc:3229 imb:7 pmb:675 smb:7478 d:t;
in:155601 out:155602 type:b q:30.00 tex:4210 mv:5549 misc:2937 imb:7 pmb:601 smb:7552 d:s;
in:155602 out:155603 type:b q:29.99 tex:4443 mv:8272 misc:4461 imb:4 pmb:1106 smb:7050 d:s;
in:155607 out:155604 type:P q:26.02 tex:96382 mv:19707 misc:7047 imb:139 pmb:4204 smb:3817 d:s;

Note that 155596 is the *wrong frame* for the I-frame--should have been at the new scene frame 155597.

I've next made another Pass 1 at the movie, this time using not DGAVCindex, but rather
DirectShowSource("d:\videoAS.grf", audio=false) where videoAS.grf uses

video.264 --> Arcsoft MPEG Demux --> CoreAVC Video Decoder

This method yields a stats file that places the I-frame correctly it appears:

in:155596 out:155595 type:P q:25.02 tex:145561 mv:27198 misc:6969 imb:1606 pmb:2668 smb:3886 d:s;595
in:155595 out:155596 type:b q:27.00 tex:41510 mv:10972 misc:5238 imb:576 pmb:1170 smb:6414 d:s;
in:155597 out:155597 type:I q:23.04 tex:1368657 mv:337886 misc:537 imb:8160 pmb:0 smb:0 d:s;
in:155600 out:155598 type:P q:28.12 tex:31178 mv:9646 misc:5368 imb:138 pmb:1694 smb:6328 d:s;
in:155598 out:155599 type:b q:30.00 tex:2969 mv:5328 misc:3199 imb:12 pmb:675 smb:7473 d:s;
in:155599 out:155600 type:b q:30.00 tex:3752 mv:5476 misc:3060 imb:37 pmb:662 smb:7461 d:s;
in:155604 out:155601 type:P q:27.96 tex:33202 mv:11504 misc:6294 imb:86 pmb:2104 smb:5970 d:s;
in:155601 out:155602 type:b q:30.01 tex:4305 mv:5489 misc:3294 imb:7 pmb:674 smb:7479 d:t;
in:155602 out:155603 type:b q:30.00 tex:4928 mv:6322 misc:3462 imb:8 pmb:719 smb:7433 d:s;
in:155603 out:155604 type:b q:30.00 tex:4817 mv:9065 misc:4726 imb:4 pmb:1216 smb:6940 d:s;


I know this "calls for speculation--facts not in evidence" but does this seem like something that the libavcodec issues mentioned before might cause (selection of the previous/wrong frame as I-frame)? BTW I noticed a couple of other I-frames that occurred "1 frame too early" when looking at all the chapter points, but this one above is the only place where corruption occurred.

I will soon be migrating to neuron2's NV tools instead, but it might still be a week or more and I hate unsolved mysteries! :scared:

[Guest]

Remove the encoding from the picture. Can you see any issues just viewing the script in VirtualDub? I really have no control over what x264 is doing.

Is it PAFF? Can you post a link to the source video of the affected section?

[laserfan]

It's a Blu-ray disc of a feature film ("The Guardian") so no interlacing at all AFAIK. And viewing the original frame-by-frame reveals nothing; it appears perfect.

I don't know how x264 works, so I was guessing at a decoding issue in the 1st pass (whereby x264.stats assertion sometimes places an I-frame wrongly) and then again in the 2nd pass i.e. that x264 just encodes the glitches it sees. But your post caused me to do the obvious (slaps head) which is to make a snippet of the problem area and process it again. Naturally :rolleyes: the snippet alone re-encodes perfectly across this scene break (using of course .dga as input), so a sample doesn't expose the issue. :( I've not done a lot of these, but seems to me that when I've seen this problem before, as this time, that it tends to occur well-into a 2 hour movie (and yes I've done extensive memtest & prime95 on this machine to no errors)...

The last parts for my new Nvidia PC arrived after I posted so I'm going to focus instead on getting that built, so I can try your NV tools. Thanks for reading & replying--your expertise & active presence at doom9 is most appreciated!

[Underground78]

Hello,

Reading DGAVCDec user manual, it seems that the only way to demux an audio track using the CLI is to demux all audio streams with the -a flag. But I have seen in the GUI that a selection of audio tracks to be demuxed is possible so to you have any plan to port this feature to the CLI ?

Anyway thank you very much for your work on DGAVCDec !

[Guest]

Didn't plan to. How would you know what audio ID to specify?

[Chumbo]

Didn't plan to. How would you know what audio ID to specify?
Doesn't the UI identify the ID? No pun intended. ;) If I had to do a bunch, I wouldn't mind identifying, manually, the IDs through the UI and then putting them in my batch file.

[kemuri-_9]

Another possible venue would be to add an option to have it display all the available IDs so you wouldn't have to open the GUI at all.

[Underground78]

I think that the informations given by MediaInfo could be used too.

Audio
ID : 130 (0x82) <--
ID de menu : 1281 (0x501)
Format : AC-3
[...]
Langue : Français

[hellfred]

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. :(
Hi neuron2

A motivated new developer named Ivan Schreter showed up on the ffmpeg mailing list, who is working hard on the H264 parser / time stamp issues. See e. g. this mail (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060134.html) and this follow up (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-February/060832.html). You will find more when searching the ffmpeg-devel mail archives of January and February for Ivan Schreter.
Did you observe that development? Will his work help you to fix the random access problems? This guy seems to be motivated, maybe you should contact him to get your problems addressed, too.

Lately there was a long discussion about libavformat usability on the mailing list, too. So now you have a good chance to get your issues addressed.

Thank you for your hard work on DGAVGDec and the other tools and filters that you have provided for us.

Hellfred

Update:
I have missed this message (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/060796.html). So Ivan will not have that much time in the near future.

[AntiJw]

Hey, neuron2. I wonder, is it okey to join-demux a m2ts (AVC) file, in eac3to:
eac3to 00118.m2ts+00119.m2ts 2: mainvideo.source.1080p.264

and use it in DGAVCDec (to encode in x264), or do I lose something by demuxing to *.264, not *.m2ts?

EDIT: Thanks for the answer, although I used DSS. "Herr"=Mister (translated). The other is something I don't like. "neuron2" doesn't mean someone with only 2 neurons?! ;)
Curiosity killed the cat :) Thinking of your avatar.

[Guest]

You don't lose anything, it's OK.

I'm curious about the significance of:

"AntiJw
Herr"

Can you explain it to me?

[tebasuna51]

Sorry if is a old question.

But, if we can't use a list of m2ts files (like vob's with DGIndex), if the decoder is libavcodec.dll like in ffdshow (installed), what is the difference between use

AVCSource("D:\Video\00001.dga")

supposed 00001.dga the DGAVCIndex output from D:\Video\00001.m2ts and

DirectShowSource("D:\Video\00001.m2ts", audio=false) ?

[Guest]

Frame accurate seeking.

[tebasuna51]

Thanks neuron2.
Then for a complete linear transcoding is the same but with Trim's in the avs we can see differences?

[Guest]

Not just trim's; any Avisynth processing that requires seeking can be wrong with DirectShowSource(). E.g., consider SelectEvery().

[djloewen]

Sorry, I realize this is OT, but I've been wondering about this for awhile too: is frame-accurate seeking needed for FieldDienterlace, IVTC(decomb), or bobbing?

[Guest]

FD - no. IVTC and smart bobbing - probably not, due to the Avisynth frame cache. I say probably because I'd have to know what the specific ones are doing, do they look ahead more than a frame or look behind outside the cache.

[laserfan]

...I've been wondering about this for awhile too: is frame-accurate seeking needed...?
I like to make movie-only backups of discs that have an especially annoying amount of junk to wade-thru on insertion, but at the same time keep all the chapter marks from the original, for jumping to favorite scenes. Before using DG's tools, making these marks was a hit-or-miss affair (actually "mostly miss") as the timecodes-after-encoding were usually different. Since building my new Quadcore/Nvidia system I use these tools exclusively, and my re-encodings do always now seem to have the exact same timecodes as the originals, and my chapter marks are perfect.

In addition, I used to have odd & random visual glitches in my encodings (a couple per movie) which appeared to have something to do with faulty decoding. No more problems.

Since these tools/methods are mostly Magic to me, I can't be certain that DGxxxDec is the sole reason why everything works perfectly now, but I don't argue with success! Where's the :bow-down: smilie here! Thanks neuron2! :)

[saint-francis]

Can we expect to see mkv support in DGAVCDec?

[Guest]

I don't plan to do anything more for the libavcodec version.

If I am successful in using CoreAVC, then I will add the MKV support to that version.

[~bT~]

I don't plan to do anything more for the libavcodec version.

If I am successful in using CoreAVC, then I will add the MKV support to that version.

what about using DivX 7? its free :) does a good job with mkv's.

[Guest]

Need an API.

[rebkell]

I don't plan to do anything more for the libavcodec version.

If I am successful in using CoreAVC, then I will add the MKV support to that version.

If you develop something with CoreAVC, would you pretty please post a note in this thread about it, I sub to this and a couple of other threads and might not even know about it for weeks :thanks:

[len0x]

Any chance CLI options of this tool can resemble main DGMpgDec for audio? (i.e. ability to specify Audio PIDs to demux) cheers.

[magic144]

Hi Donald,

I seem to have found an .m2ts file on a BD disc which is causing some grief with DGAVCIndex 1.08

The file itself is seen to playback perfectly well with ffdshow in DirectShow via ZoomPlayer (ffdshow tryouts rev 2527 Dec 17 2008). If I use eac3to to extract the video stream to an .h264 file, this is seen to hiccup at the same place in VLC (0.8.6i Janus). Again, the same eac3to extracted clip can be played flawlessly in DirectShow (in an .mkv container) using the ffdshow tryouts decoder.

In any case, when stepping through the .m2ts original in DGAVCIndex 1.08, I get the message "top block unavailable for requested intra mode at 101841180 1875508556" at the beginning of the point of visual corruption. (and later, "top block unavailable for requested intra4x4 mode 101841180 at 1875508556 1910128"

Any ideas what could be causing this, and is there some way I can give you a sample of said video stream for your expert analysis? (I don't know how to go about this, and the original .m2ts is impractically large!!)

Thanks for this great tool - I rely on it implicitly for my BD backups and have never seen this behaviour before,

m

hmm, looking through the past few weeks forum activity, am I right in assuming there are some outstanding issues with libavcodec, which may therefore affect DGAVCIndex? That's not good (I don't have an NVidia GPU either!!)... Are you developing a version that works with CoreAVC (or even ATI)?

as a *very* reluctant alternative in the absence of a fix, will DirectShowSource work just as well (would this be 'frame accurate') if all I want to do is frame-serve to x264 via a very-plain .avs script with just this kind of format:-

DirectShowSource("AVCSsourceInContainer.mkv.GRF",audio=false)
AssumeFPS(24000,1001) # possibly unnecessary
crop( 0, 0, 0, 0)
LanczosResize(1280,720) # Lanczos (Sharp)

[Guest]

You can cut a segment with DGSplit and upload that to a hosting site.

But why do you talk about an M2TS and then give me a script with:

AVCSourceInContainer.mkv.GRF

???