DGAVCDec 1.0.9

[ACrowley]

Im a little bit confused..

1.0.9 is the latest Version ,including dll

Megui made a update on dgavcindex and dgavcdecode today. Its DGAVCIndexd/Decode 1.0.1-1 ? The exe and dll are 1.0.0.0 from 30.04.2009 ? So its a updated Version ?

[Guest]

I don't know anything about those version numbers. You can ask the Megui guys what is going on.

[Sharktooth]

@ACrowley: No, it's 1.0.1 (the -1 means it was repackaged - the reason for repackaging was: missing libavcodec.dll).
however, ill update degavcindex/dec packages with the new version as soon as i get home.

[ACrowley]

@ACrowley: No, it's 1.0.1 (the -1 means it was repackaged - the reason for repackaging was: missing libavcodec.dll).
however, ill update degavcindex/dec packages with the new version as soon as i get home.

Ok, Thx

obviously its the old 1.0.1 Version. Mhh...so i used the old dgavcdecode Decoder for some BluRay to x264 encodes via megui. I havent noticed that megui use/updates a old Version.
But i cant see any Problems in these x264 encodes encoded through dgavcdec.dll 1.0.0.0

[krosswindz]

I am not sure if this has been discussed earlier, but I find that encoding BluRay to x264 using AVCSource is 4-5 times slower that using DirectShowSource with ffdshow+haali for me. Is this a known issue or am I doing something weird. I would prefer to use AVCSource as it is frame-accurate while DirectShowSource decoders neednt be frame-accurate. Any information regarding this is appreciated.

[Guest]

Nah, they both use the same decoder: libavcodec. You must have changed something else between the cases. Five times slower would have been noted by now.

[stpdrgstr]

Hi neuron2

I'm getting this problem with lossless encoded h264 raws.

http://img25.imageshack.us/img25/8336/problemh.png (http://img25.imageshack.us/my.php?image=problemh.png)

While getting this warning when loading the h264 stream.

PicParset 0 references are invalid (uninitialized) Sequence Parameter Set with ID 0, expect the unexpected... (lol yeah)

Hit Yes continue notifying this specific error type; hit No to disable it.
Hit Cancel to supress all further errors.

If I press Yes, it goes right away to the second frame, with the same Warning. If there I press Yes again, it will stop displaying the error until I advance to any other frame, where it will display the warning and not show anything else but a black frame. If I press No, I get the problem in the screenshot.

Here's the sample (http://www.mediafire.com/?it2hynexeoy)

[nixo]

You need to use the old lossless mode, meaning x264 builds earlier than revision 994. The version of libavcodec.dll in dgavcdec is too old to decode the new lossless mode.

--
Nikolaj

[stpdrgstr]

Damn, that's not cool :(

Is there any difference from indexing it through here and loading it with DSS2 using CoreAVC or libavcodec from lastest ffdshow?

[b66pak]

i have the same problem as stpdrgstr...how can be properly decoded the new x264 lossless mode?
_

[ChronoCross]

You need to use the old lossless mode, meaning x264 builds earlier than revision 994. The version of libavcodec.dll in dgavcdec is too old to decode the new lossless mode.

--
Nikolaj

i have the same problem as stpdrgstr...how can be properly decoded the new x264 lossless mode?
_

see the above quote.

[LoRd_MuldeR]

i have the same problem as stpdrgstr...how can be properly decoded the new x264 lossless mode?
_

Try muxing your "raw" H.264 stream into an MKV container via MKVToolnix (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) and then use FFVideoSource() (http://forum.doom9.org/showthread.php?t=127037) or even DirectShowSource() instead of AVCSource().

[G_M_C]

@ACrowley: No, it's 1.0.1 (the -1 means it was repackaged - the reason for repackaging was: missing libavcodec.dll).
however, ill update degavcindex/dec packages with the new version as soon as i get home.

Talking about wich;

I know you used a "custom" libavcodec in your package Neuron2. But i forgot if it was possible to to update your package with a current "regular" vversion of libavcodec. I seem to remember that that was possible, but i'm not shure about it atm.

I ask this cause libavcodec changes once in a while, and getting more/better/faster/whatever decoding through DGAVCIndex (if applicable) by simply changing the libavcodec is simple to do.

[StifflerStealth]

I have a MKV with one h264 video stream and one aac audio stream. I demux them out with mkvextract from the MKVToolNix package, and then open it with the indexer. I then use that file with my AVS script. The audio is converted to Wave64 which is opened with the NicAudio package. The two streams are then AudioDubed together. I use Info() at the end of the script. The Indexer reports correctly that the video is 29.97FPS, the info function shows the video frame rate as 60000/2002 instead of 30000/1001. Also, the video plays fast in MPC. The Info function shows the video as being 18 minutes long and the audio is 22 minutes long. The correct time is 22 minutes. The video is all there, but playing faster than what it should. I tried all three settings under video on the indexer (honor pulldown, ignore pulldown, and force film), but all three settings produce the same results. I looked in the dga file and at the end, there is this:
SIZ 720 x 480
FPS 60000 / 2002
CODED 33629
PLAYBACK 33629

So, it is telling MPC that the frame rate is that number, which is 29.97 FPS, but I have always heard of it as being 30000/1001. Is this the reason why it's playing fast?

[Guest]

But i forgot if it was possible to to update your package with a current "regular" vversion of libavcodec. It's not possible because I check that it is the DLL that I supply. I cannot use the newer versions because they are broken for accurate frame random access.

[Guest]

So, it is telling MPC that the frame rate is that number, which is 29.97 FPS, but I have always heard of it as being 30000/1001. Is this the reason why it's playing fast? No, because 60000/2002 = 30000/1001. You can just change it to 30000/1001 in the DGA file if you like. I don't expect it to behave any differently.

[G_M_C]

It's not possible because I check that it is the DLL that I supply. I cannot use the newer versions because they are broken for accurate frame random access.

Thx for the fast reply Neuron2 !

[nm]

The Indexer reports correctly that the video is 29.97FPS, the info function shows the video frame rate as 60000/2002 instead of 30000/1001. Also, the video plays fast in MPC. The Info function shows the video as being 18 minutes long and the audio is 22 minutes long. The correct time is 22 minutes.
Those numbers suggest that the correct framerate is ~24 fps. Upload a sample clip (to MediaFire, for example).

[StifflerStealth]

I uploaded a segment to MediaFire. MPC detects it as 29.97 FPS as well as the AVC Indexer. Avidemux (latest SVN build) always gets the audio out of sync when I try to edit it (Bleach episodes have annoying end of part 1 things that I am trying to edit out for fun and experience and do some filters to enhance the picture. :D). Also, I tried the indexer that came with FFmpegSource2, and it showed the video as 24 fps, but it was out of sync with the audio. -_-' So, the detection of the fps has a bug somewhere, either this tool or ffmpegsource2 or both. :P Or something else is wrong, like my ripping/coding. I thought I got all the details correct for the encode. Anyways, I hope you can tell me what's wrong and how to open this in AviSynth or other programs so that the video is in sync. :)

{Link removed since issue solved}

Thanks.

[Guest]

@StifflerStealth

You have posted an MKV. Where did you get it?

[StifflerStealth]

I muxed it. :S I thought you would want the audio and the video together for comparison. Should have everything that I am working with, except shorter. You can go through what I do, demuxing, importing to avisynth and all that. Maybe I am doing something wrong? I used the new MKVToolNix Gui as the muxer. Why, did I mux it incorrectly? Or did you just want the raw h264 stream and you didn't need the audio with it? But, I thought you wanted to try the audio going out of sync thing. :S Confusing.

[nm]

I uploaded a segment to MediaFire.
It's VFR (variable framerate). The default framerate is set to 30000/1001 in the Matroska headers, but the actual frame timings imply 24000/1001 fps video. I only looked quickly at the timecodes given by "mkvextract timecodes_v2 file.mkv 1:file.tc.txt" though, so there could be some 30000/1001 segments, especially in the complete video.

Editing VFR video requires special care and tools like Avidemux might not support it fully. Try using mkvmerge for cutting. For filtering (that doesn't change the number of frames), extract timecodes first, filter and re-encode the video and mux back to Matroska with the original timecodes.

[StifflerStealth]

Thanks nm. :) I guess I should read a bit more before I use new codecs. I did all this before I moved to Win7, and I don't know if AnyDVD works with win7 yet or not, so I don't feel like re-ripping. XD I will just re-encode the h264 stream this time without VFR. Now I just need to figure that out. Any chance of seeing VFR support in the future for DGAVCDec? :D Though, I must say, I do feel a bit stupid for not properly reading encoding instructions to begin with. :o Sorry for the ruckus. :(

[Guest]

@StifferStealth

I want an explanation of what you ripped it from. If from a DVD give the title and region. Also explain how you claim to have made a VFR encode when you apparently cannot even recognize such a thing. If you do not answer satisfactorily you'll get you a rule 6 strike. Awaiting your full explanation...

@nm

Do not respond when rule 6 concerns are raised. You can get a strike for it too.

[halsboss]

Not necessarily. I'm working on using CoreAVC as the underlying decoder. I don't know if it will be successful.
Hello, any news or gossip about progress on this ?

[saint-francis]

Hello, any news or gossip about progress on this ?

Waiting on CoreAVC 2.0. It will provide an API which DGAVCDecode and use.

[Sharktooth]

id be glad if, in the meantime, libavcodec could be updated with the latest one, multithreaded and supporting x264 lossless encoding...

[LoRd_MuldeR]

id be glad if, in the meantime, libavcodec could be updated with the latest one, multithreaded and supporting x264 lossless encoding...

I cannot use the newer versions because they are broken for accurate frame random access.

:scared:

[Sharktooth]

doh!!

[Mtz]

This (http://www.sendspace.com/file/a2ep4l) is a TS with 4 audio and 8 subtitles. The subtitles are detected as AC3. Is possible to correct detect the subtitles and output them (demux) in some way?

enjoy,
Mtz

[Mtz]

DGAVCDec project is dead?

[Guest]

Bugs will be fixed, but no more major development unless and until CoreAVC releases an API.

[Mtz]

OK, thank you!
Do you think is possible to export the DVB Subtitles in some format, or this is also dependent of that API?

enjoy,
Mtz

[Guest]

Do you think is possible to export the DVB Subtitles in some format If you can point me to the relevant spec and provide a test stream.

[Mtz]

Here (http://www.bjpace.com.cn/data/tec/tec-DVB/DVB%20BlueBooks%20Standards/Specifications%20and%20Standards/subtitling/dvb-sub/Ets300743_e1.pdf) and here (http://broadcasting.ru/pdf-standard-specifications/multiplexing/dvb-si/en300468.v1.5.1.pdf) I found some documentations.
In my previous post (http://forum.doom9.org/showthread.php?p=1287806#post1287806) is a link for DVB Subtitles (as bitmap) which can be viewed by VLC and here (http://www.sendspace.com/file/ktzc52) seems to be a file with both types of subtitles (teletext and bitmaps) as reported and viewed by VLC. I think for MPEG2 only teletext subtitles are used, but for H264 can be used both types.
ProjectX can extract the DVB Subtitles but sometimes the palette of idx is wrong and the SUP file saved is SD not HD.
I saw in some eac3to log that the program can detect the DVB Subtitles correct even it cannot export them.
In my two provided samples the subtitles are detected as AAC or AC3.

enjoy,
Mtz

[nm]

I think for MPEG2 only teletext subtitles are used, but for H264 can be used both types.
Bitmap-type DVB subtitles are used along SD MPEG-2 broadcasts in some countries (at least by YLE here in Finland).

[abero]

Since this thread is 92 pages long, i've checked and searched but couldn't find an answer, so maybe this is old news, but i've got a problem with a recently recorded hi-def .ts file.

I've opened the .264 in DGAVCIndex and save the project, created a .avs file, which looks like this:


loadplugin("DGAVCDecode.dll")
AVCSource("Disney Cinemagic HD - Saludos Amigos.dga")

Video looks ok in DGAVCIndex, but if i open the .avs file in virtualdub, megui, media player etc. i get a garbled frame every few frames which look like these :

http://img3.imagebanana.com/img/gz115lhy/thumb/saludos.jpg (http://img3.imagebanana.com/view/gz115lhy/saludos.jpg)http://img3.imagebanana.com/img/hmknzgo3/thumb/saludos2.jpg (http://img3.imagebanana.com/view/hmknzgo3/saludos2.jpg)

Any1 know where my problem lies and what i can do about it?

Thanks

[ministrix]

I got a question. I've tried searching this thread but to no luck. For some reason dgavcdec wont do two .m2ts ( ive tried add both files but yet it only decodes the first ), so i wonder is there a way to load two avcsources like this
AVCSource("00000.dga"+"00009.dga") ?

I tried diff ways but to no luck.

[Audionut]

Get the latest beta from here: http://forum.doom9.org/showthread.php?t=147945

One of the fixes is multiple file support.

[SeeMoreDigital]

Get the latest beta from here: http://forum.doom9.org/showthread.php?t=147945

One of the fixes is multiple file support.But those versions of DGAVCDec only work with (certain types of) Nvidia graphics cards.

[Audionut]

But those versions of DGAVCDec only work with (certain types of) Nvidia graphics cards.

Ah yes, I had forgot about the non nvidia versions.

Sorry ministrix, the version I linked to will only work with a nvidia card that has vp2 or greater.

[Guest]

You can either concatenate the M2TS files before loading into DGAVCIndex or you can demux to one file using tsmuxer.

[MatLz]

I have noticed the loss of some kb when I demux video, compared to original stream. What is the reason?

[Guest]

When you demux you no longer have the other elementary streams, such as audio. You also no longer have the muxing overhead.

[MatLz]

When you demux you no longer have the other elementary streams, such as audio. You also no longer have the muxing overhead.

In fact it's when I just put a .264 it happens. For example, when I put the stream out of a mkv or a mp4 (like as I did for test the inloop deblocking : put out from my mkv with mkvextract)
So it remains some overhead?

[Guest]

Your question is so vague it's hard to make sense of it.

Case 1: You have just an AVC elementary stream in the MKV. You demux the AVC stream and compare the size of the MKV to the size of the demuxed AVC stream.

Case 2: You start with an AVC elementary stream, put it into an MKV, extract it and then compare the extracted AVC stream to the original AVC stream.

Case 3: ...

You have to tell me exactly what you are doing.

[MatLz]

I have test the deblock=false in the dgavcdec filter. For that, that I have extract the .264 stream out the mkv I made.
I puted this .264 file in dgavcindex and use demux video stream.
Result: a loss of some kb.

[Guest]

I puted this .264 file in dgavcindex and use demux video stream. It makes no sense to demux from an elementary stream. Why are you doing that?

If you post the AVC stream that you input into DGAVCIndex I can try to identify why the operation is not acting as a no-op.

[Guest]

OK, I duplicated it and here is the explanation.

DGAVCIndex maps 00 00 00 01 xx start codes to 00 00 01 xx. According to my reading of the spec and my testing, this is not a problem, and in fact no-one has ever reported any problem with it.

If you have a compelling reason why the original extra 00 bytes should be retained, I can consider outputting them.

[MatLz]

I know "demux" word, but I did it, point. I'm curious, that's all.
Well, so curious I just tried with .264 stream directly encoded by X264 (not extract out of a mkv).
There is a negligible loss of 0.014% but a loss at all.
That was my question.