DGAVCDec 1.0.9

[Ranguvar]

I've indexed 1080p files over 15GB, so no.

Bad stream? Try muxing to M2TS/demuxing. If it still won't go, chop a sample, test, and send it in.

[rebkell]

I don't know if this has already been addressed, but on the CLI version, if you leave the dga off of the output file, it will crash, and if you put the .dga extension on the output file, then when demuxing the audio, it will include the .dga as part of the demuxed audio aka
Eureka0102.dga PID 1100 DELAY -39ms.aac

this is on 100a35, it's no big problem, just inconsistent with the gui version, which doesn't put the dga in the demuxed audio file.

It will actually index the file and create the output dga file, without an extension, but I guess it crashes on the audio file, it doesn't create one at all.

Edit: Ok, it does create the audio file when you leave off the dga extension, but it crashes on completion.

[Ranguvar]

Bug report, though I doubt you'll be able to replicate it, since it was random... I've used DGAVCIndex a lot today, and when I opened it this time, I couldn't see it, though it was on the taskbar. Hmm. Odd. What was really odd is that in WinFlip (fancy graphical Alt+Tab like Vista), I could see the window.

I downloaded DGAVCIndex again, ran the new one, and it worked. So, I checked my INI file, as that was the only difference between the two. Lo and behold - my window position was set to -3200,-3200. Changed it to 100,100, as it was in the default INI, and now it works.

Again, doubt you'll be able to replicate/fix, and it may have been on my end, but I'll post this for anyone else if they run across the problem.

[Guest]

It happened to me once, too. I couldn't repeat it and the code looks OK so I never bothered about it.

[Sagekilla]

@Ranguvar: I think the issue has to do with the ini file. I had this same problem as well, but as soon as I closed the application and deleted my ini to have it regenerated, it worked perfectly fine.

I should note, neuron2, that this problem exists in DGAVCIndexNV too.

[Guest]

I should note, neuron2, that this problem exists in DGAVCIndexNV too. Same code for INI file handling. What we need to fix it is a procedure for making it happen. I could also add a sanity check on the values when loading the INI file.

[krieger2005]

The main question for me is where these numbers (-3200) came from. I mean, if DGAVCIndex write them into the ini-file it should get them from somewhere. Maybe it is a OS-Problem then? If so, then a so called "sanity check" whould be the best thing. In general i think such a check is usefull when for exaple if someone lower his resolution, so the DGAVCIndex fall out of the monitor-view. Or if someone give his DGAVCIndex zipped to his friend with different Monitor-Resolution.

[squid_80]

Don't break my secondary monitor (whose co-ordinates range from {-1280,0} to {0, 1024}). However do feel free to swear at MS for allowing stupid desktop geometries.

[Guest]

The main question for me is where these numbers (-3200) came from. GetWindowRect().

[medp7060]

I have a ts clip of h.264/aac+. DGAVCDec 1.0.0 Alpha 35 demuxed the audio as AAC LATM/LOAS. Strange thing was PowereDVD could not play the resulted aac audio. However, it played the original ts clip well. Any isea what was wrong?

[Guest]

Please provide an unprocessed stream sample that I can use to duplicate your issue.

[medp7060]

here is the sample http://rapidshare.com/files/147590800/TVNZ6.ts

[rack04]

@neuron2

I have read the DGAVCIndex User Manual. In the section "Field Operation" you discuss the differences between honor pulldown, ignore pulldown, and force film. More specifically:

If the clip is 29.976fps, and the Field Repeats box in the Information Panel indicates field repeats consistent with 3:2 pulldown, then it is likely that the clip can be treated as 3:2 pulldown material, and so the Force Film option should be selected for generation of the DGA file.

What indicates field repeats consistent with 3:2 pulldown? The reason I ask is because on some of my HD DVD's with AVC, i.e. Transformers, the demuxed AVC file is 29.976. How would I use the Information Panel to verify that the source has a 3:2 pulldown?

[Atak_Snajpera]

Movies on HD-DVD are always encoded as 23.976 so you can safely use Force Film

[rack04]

Movies on HD-DVD are always encoded as 23.976 so you can safely use Force Film

Same for Blu-ray?

[Guest]

What indicates field repeats consistent with 3:2 pulldown? The reason I ask is because on some of my HD DVD's with AVC, i.e. Transformers, the demuxed AVC file is 29.976. How would I use the Information Panel to verify that the source has a 3:2 pulldown? 3:2 pulldown makes 5 frames out of 4. So, start a preview and let it run for a while. Then calculate the ratio of Playback # / Coded #. If it is a 3:2 pattern the ratio will be close to 5/4 = 1.25.

[Guest]

I have a ts clip of h.264/aac+. DGAVCDec 1.0.0 Alpha 35 demuxed the audio as AAC LATM/LOAS. Strange thing was PowereDVD could not play the resulted aac audio. However, it played the original ts clip well. Any isea what was wrong? Well, it is LATM/LOAS. You can drop the demuxed AAC file into WinAmp and play it. You can use the WinAmp output plugin to save the decoded WAV. I don't know anything about PowerDVD and what files it can open.

[Guest]

* Code restructured for standard decoder interface.

* Changed hotkeys:

Save BMP [F7]
Copy Frame to Clipboard [F8]

* Fixed a memory leak that caused indexing to fail for large files.

* Licensing activation system added. [Just kidding!]

* Temporarily disabled the frame type field of the Info dialog because it was showing decode order data instead of display order data, which is misleading to the user. (Note: this works correctly in DGAVCIndexNV.) Fix in progress.

http://neuron2.net/dgavcdec/dgavcdec101.zip

[medp7060]

Thanks.

Unlike PowerDVD, WinAMP does take the aac audio and converts it into wav.

[G_M_C]

Thx Neuron2 !

I'll upgrade this weekend, and find a nice large project to test. DGAVCIndex has come a long way since i've started using it with Alpha 5, and i've not had many problems yet.

[LoRd_MuldeR]

http://neuron2.net/dgavcdec/dgavcdec101.zip

Thanks for the update :)

(BTW: It seems you forgot to change the version number, the "About DGAVCIndex" dialog still says Alpha-35)

[Guest]

BTW: It seems you forgot to change the version number, the "About DGAVCIndex" dialog still says Alpha-35) Ah yes, things were a little hectic yesterday evening. I have updated the ZIP so you can re-download it if you so desire.

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?

[G_M_C]

Ah yes, things were a little hectic yesterday evening. I have updated the ZIP so you can re-download it if you so desire.

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?

For some reason or another ( ;) ) i get the feeling that AVC-in-MKV is more common. And on that basis I think that MKV would be the more wise choice.

[LoRd_MuldeR]

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?

Since MP4 is the "native" container for H.264 (if there is such a thing), I'd vote for MP4 ;)

[Zwitterion]

My vote goes to MKV because I think it's the more used and versatile of the two, despite MP4 being the 'official' container.

[Nikos]

I'd vote for MKV.

[rebkell]

I would vote for mkv also.

[turbojet]

just a little cosmetic bug, the about box still says 1.0.0 alpha 35 in 1.0.1

[LoRd_MuldeR]

just a little cosmetic bug, the about box still says 1.0.0 alpha 35 in 1.0.1

http://forum.doom9.org/showpost.php?p=1188626&postcount=1471

[rack04]

I also vote for MKV.

[audyovydeo]

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?

Definitely MP4

I think there are enough "standards" already. Let's push one to achievecritical mass to one, and let it live long & prosper. I'd rather see DGAVDec become an "industrial-strength" tool than an "enthusiast-tweaking" tool.




cheers
a/v

[rebkell]

Definitely MP4

I think there are enough "standards" already. Let's push one to achievecritical mass to one, and let it live long & prosper. I'd rather see DGAVDec become an "industrial-strength" tool than an "enthusiast-tweaking" tool.




cheers
a/v

I don't think he's planning on exclusive mkv, just which one do we think he should tackle first. I gotta believe that the biggest majority of the userbase right now would rather see mkv. I can't speak for neuron2, but I strongly believe that the majority of his users would rather have mkv first.

[Ranguvar]

*votes for MKV*

[Adub]

* Licensing activation system added. [Just kidding!]


LOL!! Man, I almost had a heart attack there for a second. It was pretty surprising. Don't get me wrong, I think what you did with DGAVCDecNV was entirely in your right, and I support your decision to do so. But, man, I would have been extremely surprised (and maybe a little angry) if you had done the same thing with DGAVCDec.

Putting that aside, thanks very much for the update!! And I cast my vote for MKV first. It is more versatile than MP4, and more widely used. I use it all of the time, yet I only use MP4 for special situations, mostly having to do with hardware compatibility.

If you are eventually going to add both, that is great! But if it is only one, I vote MKV.

Thanks, Don, for the great work you continue to do for the community!

[SeeMoreDigital]

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?It's MP4 for me please....

More so now, given that the muxing of AC3 and EAC3 streams within the MP4 container has been standardised.

[noee]

Licensing activation system added. [Just kidding!]

**courtesy chuckle**

I vote for MKV.

[Zep]

On another matter, what is the thinking on MKV versus MP4 support? Which should I tackle first?

mkv for me too :)

[Comatose]

I vote for MP4 or MOV. MKV files are usually stuff I've encoded and don't need to open with DGAVC, so...
Example for mp4 - nicovideo uploads and other such blahblah.

Trailers and even video game trailers come in MOV often, so that would also prove useful.

Definitely MP4

I think there are enough "standards" already. Let's push one to achievecritical mass to one, and let it live long & prosper. I'd rather see DGAVDec become an "industrial-strength" tool than an "enthusiast-tweaking" tool.
Personally, I think we should support MKV instead of MP4 as it is the purely non-commercial format of the two and aims for more features, all of which are awesome.

Also, one thing that's would be awesome to have for both MP4 and MKV would be being able to tell when a video is VFR and the capability to extract it into MKV timecodes.

[Zwitterion]

MKV instead of MP4

Neuron2 just wanted to know which container to support first, so chances are good that both will be supported eventually. :)

[Deinorius]

I vote for MP4/MOV because demuxing of MKV files is easier imho. MP4 ist ISO too. MKV can come after that.

As comatose mentioned it, could it be possible if DGAVCIndex recognizes VFR in MKV files?

[kemuri-_9]

As comatose mentioned it, could it be possible if DGAVCIndex recognizes VFR in MKV files?

that makes it seem like MP4 can't do VFR, which it can! so don't be so misleading.

[Guest]

OK, guys, we can stop the voting now. It looks like a tie, so I'll toss a coin. :)

The plan is to support both.

[stax76]

MKV has won all polls I've seen by far, some examples:

http://forum.doom9.org/showthread.php?t=133342

http://www.planetdvb.net/node/378

DivX 7 wil use mkv which is likely to boost mkv's popularity even more.

[Rodger]

A shame there is still almost no progress in PAFF decoding.
Though the improvements of dgavc itself are very nice.
:thanks:


@ Stax

Well....WHY would I use DivX7?
I got x264!!! Won´t get much better!

[Guest]

A shame there is still almost no progress in PAFF decoding. Don't lose hope. Things are happening behind the curtain that could bear fruit.

[Dark Shikari]

@ Stax

Well....WHY would I use DivX7?
I got x264!!! Won´t get much better!DivX's main business is in making standalones support their format, and x264 can encode into "DivX7", since DivX7 is just going to be MKV with L4.0 H.264 High Profile video (not sure about audio yet).

[nm]

A shame there is still almost no progress in PAFF decoding.
I haven't seen sources (PAFF or other) that libavcodec would fail to decode properly after Michael's fixes in August, and he has been fixing more problems in the last few weeks (see the log (http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/h264.c?view=log)). If people here still have samples that the decoder fails on, you might want to report them now, when Michael is still working on these things. Remember to test with the latest FFmpeg/libavcodec SVN, with MPlayer or ffplay, for example. And follow the guidelines (http://ffmpeg.mplayerhq.hu/bugreports.html) on bug reports.

[Guest]

As I have said several times, there are regressions for random access. Things are apparently OK if you only want to play straight through. I have recently been in touch with Michael about it and sent him a sample. Let's see if something can be done so that the random access needed by DGAVCDec can be made to work correctly with the latest code. If it could work I would have done it long ago, and again, I have tried to work with him in the past about it, without much luck. Now he has written me and I responded with the sample and an explanation. That is where things stand right now. If you'd like to encourage him to help us, I'd be grateful.

[Deinorius]

that makes it seem like MP4 can't do VFR, which it can! so don't be so misleading. This way or another, it doesn't answer my question.
If VFR could be supported, it will be better to be able to activate/deactivate it. Escpecially if mp4 supports VFR too. But honestly I've never seen any VFR.mp4 (but I didn't search for too) and I've no idea, if any SAP supports VFR at all.
Well....WHY would I use DivX7?
I got x264!!! Won´t get much better! Dark Shikari said enough, but don't forget, DivX7 will support H.264 Decoding. If I'm not false, an Encoder will come too. It might not be as good as x264, but I'm neutral (with advantages for x264 ;)).

[Dark Shikari]

Encoder will come too. It might not be as good as x264, but I'm neutral (with advantages for x264 ;)).Encoder is already out; its pretty much terrible; quality is comparable to x264 on fast-ish settings without AQ, and speed is worse than x264 by a wide margin. Of course, its just an alpha at this point, so one would expect it to get quite a bit better.