Problem: DGIndex and 1080P@23,976FPS

[AllTimeSToneD]

Hi,

i know DG took a break from video coding for some time now but maybe someone else can add this on the todo list ;)

I'm having problems to serve the video properly using DGIndex and it only happens on 1080P@23,976FPS (aka 24FPS) material.
1080P@24FPS is a part of the ATSC standard. It does not air on any station afaik but im used to remaster it and remux it.

I've linked image so the error can be seen.
http://img130.exs.cx/img130/4951/error7.jpg

[Fer]

I have had the same problem with 1080p material. I have found a solution to reencode in VirtualDub using DGIndex as frameserver. I have used MpegRepair to decode and save the Input Stream as Elementary mpg video. Such mpg is opened in DGIndex anf the d2v project generated is free of macroblocks and any other problems in VirtualDub.

http://www.pixeltools.com/MpegRepair.html


Fer

[AllTimeSToneD]

I've found the problem in the meanwhile.
The problem itself is not in the Video stream as its free of errors no dropouts/glitches etc
The problem itself is that DGIndex does not like the multiplexed transport stream even though its ISO standard http://www.lilapple.com/products/mp2tsms.htm

When the Video ES itself is served the problem is gone.
Lets hope DG finds a solution for that problem and makes DGIndex like the ts created with mp2tsms. :D

[Cyberia]

I will add this to the list for him to look at when he returns.

[AllTimeSToneD]

Thx Cyberia :)

[Nic]

Jeeze 29 meg for a bloomin' PS/ES->TS converter...I'll try and fix the problem. Your probably better off using a free PS->TS converter...Are you just going from a program stream to a transport stream?

-Nic

ps
Yeah, DGDecode definitely doesn't like the streams, I wonder why...hmm. I'll see if I can spot why.

http://nic.dnsalias.com/DGDecodeProblem.ts (7.9mb)

[Nic]

Ok, problem solved.

DGIndex doesn't believe it's a Transport File, unless it has a valid extenstion.

Rename your .mpg file that was output by the transport stream muxer to .ts - Then try loading it into DGIndex. It should work then :)

It's a bug that should be fixed, I could fix it, but it's very easy so I'll let Donald do it, you should never rely on extensions to discover file type.....(Because of the extension it was treating it as a elementry stream)

Cheers,
-Nic

[AllTimeSToneD]

Your probably better off using a free PS->TS converter...Are you just going from a program stream to a transport stream?

First of im not just doing PS->TS i do Video ES_and_2x Audio ES->TS and yes i have have been looking out for a free solution but there was none that would let me take two audio streams and a video to mux it to a proper ts that actually plays. Manzanitas commercial one does exactly what i need and its worth the money :)

Rename your .mpg file that was output by the transport stream muxer to .ts - Then try loading it into DGIndex. It should work then
Im not sure about the trial version but mine outputs the file as an .ts including the extension. Loading the file into DGIndex is no problem the problem is the serving. Once the d2v file is created and served to VDub you get all jerky output as seen on the screenshot. :(

Edit:
I've tried your ts (the manzanita demo ES) and same result
http://img13.exs.cx/img13/5200/nics_ts.jpg
also tried renaming the .ts to .mpg and dgindex crashed :scared:

[Nic]

First of im not just doing PS->TS i do Video ES_and_2x Audio ES->TS and yes i have have been looking out for a free solution but there was none that would let me take two audio streams and a video to mux it to a proper ts that actually plays. Manzanitas commercial one does exactly what i need and its worth the money
Ok, I can think of other solutions, but I'm sure your current one is good for you now.

Ah, ok misunderstood the problem, I'll look into it again :)

Cheers,
-NIc

[Nic]

http://nic.dnsalias.com/DGDecode.zip

Try that version, should fix your problem :)

-Nic

[AllTimeSToneD]

Yay! It works now! Thank you Nic :)
What was the problem? Was it the transport stream or the dll itself?

[Nic]

The DLL...if you're a bit of a coder, get the source, and look in a file called getbit.c search for the word "lazy". DG was obviously feeling a bit lazy that day, and even commented on it ;) (So I fixed that bit)

Glad it worked :)

Cheers,
-Nic

[Cyberia]

Way to go Nic! Thanks!

[chilledoutuk]

yes i had this problem on a x-men HDTV capture so thanks for the fix nic.

[Cyberia]

@Nic: You should probably bump the DGIndex version and we can push this as a new version...

[Leak]

Originally posted by Nic
http://nic.dnsalias.com/DGDecode.zip

Try that version, should fix your problem :)

-Nic

I'm wondering if you could perhaps find out what causes another bug that's been annoying me a bit lately:

Everytime I reload an AviSynth script in VirtualDubMod by hitting F5, the frames returned by DGDecode look horribly broken until what I assume is reaching the next keyframe - isn't DGDecode supposed to start decoding at the previous I-frame so this shouldn't happen? If I seek to a different frame after the first frame has been loaded this doesn't happen anymore until I reload the script and VirtualDubMod jumps to back the frame I was at.

To illustrate what I'm talking about:

Expected result (http://140.78.145.103:8888/~kp/Stuff/GITS_SAC_01_917_normal.png) (i.e. jumping to frame 917 after opening my AviSynth script that only contains the MPEG2Source line)
Actual result (http://140.78.145.103:8888/~kp/Stuff/GITS_SAC_01_917_b0rked.png) (hitting F5 right after taking the previous snapshot)

I'm not sure, but I don't think this happened with earlier versions of DGDecode and only has popped up in recent versions. :confused: Or am I the only one to experience this?

np: Fizzarum - Live at 35mm 26.11.2004

[AllTimeSToneD]

Or am I the only one to experience this?
No, i've been experiencing the same problem but it only happens sometimes so i got used to it :D I uselly get rid of it when i jump 50 frames back and forward using VDs shortcut though it never happend while i was encoding only while previewing.

[Leak]

Originally posted by AllTimeSToneD
No, i've been experiencing the same problem but it only happens sometimes so i got used to it :D I uselly get rid of it when i jump 50 frames back and forward using VDs shortcut though it never happend while i was encoding only while previewing.

Yeah, but this makes adjusting filters a b*tch - also, jumping 50 frames back and forward returns a frame cached by AviSynths internal cache for me, so I'll get the same garbage on the frame unless I jump back far enough and single step forward to the frame I wanted to be... :(

np: Iwasaki Taku - R.O.D (Opening Version) (R.O.D The TV Original Soundtrack 1)

[len0x]

Originally posted by Cyberia
@Nic: You should probably bump the DGIndex version and we can push this as a new version...

I second that :)

[Nic]

@Leak: I can't replicate that bug here, everytime I press F5, it all works ok (???) (I've only tried with a couple of clips, but it doesn't happen for me (one was an anime clip which is hard to decode))

@Lenox + Cyberia:
Well, here's the thing, with Microsoft Visual Studio 6 Service Pack 6, you can't compile the code correctly. So I had to compile it with the Intel Compiler which can't compile the 3dnow instructions. So 3dnow is turned off in my DGDecode (it will default to the best non-intel setup). So if I fix anything else, I'll compile it properly in VS 2003 and then raise the version number....How's that ? ;)

-Nic

[Leak]

Originally posted by Nic
@Leak: I can't replicate that bug here, everytime I press F5, it all works ok (???) (I've only tried with a couple of clips, but it doesn't happen for me (one was an anime clip which is hard to decode))

That's strange... :/

If you don't mind I'll throw my script and part of that VOB together at home and put it up on my server for you. Are you using postprocessing options? I'm using cpu=4 and ipp=true with moderate_h=30 and moderate_v=60 (from memory, maybe I've mixed up both values) and the SSE2 DCT...

@Lenox + Cyberia:
Well, here's the thing, with Microsoft Visual Studio 6 Service Pack 6, you can't compile the code correctly.

Let me guess - the processor pack won't install with SP6, right? :)

np: Shadow Huntaz - American Dreams (Corrupt Data)

[len0x]

Originally posted by Nic
So if I fix anything else, I'll compile it properly in VS 2003 and then raise the version number....How's that ? ;)


Sounds good, but what's the problem with compiling it now in VS2003?
I have it installed, so I can compile it as well if needed.

[Nic]

@Leak: Cool, send me a PM or whatever as to where to get it and i'll test.

@Lenox: I could do, but something as widely used and big as DGDecode i'd want to make sure I got right. DG uses _aligned_malloc, and i've got the latest Platform SDK, but for my version I #ifdef'd XviD's malloc and free code into DGDecode to get it compiling correctly in VC6. So i'd rather compile it up when I've got more time :)

-Nic

[len0x]

ok, got it. np

[Leak]

Originally posted by Nic
@Leak: Cool, send me a PM or whatever as to where to get it and i'll test.

Will do, I'm just uploading it via ISDN and since it's ~30MB it'll take another hour.

Anyway, I just tried using MPEG2Source with only a filename and it still does the same, so it's not related to post-processing or DCT or anything.

I'll PM you when it's done and I've taken a bath... :)

np: RJD2 - To All Of You (Since We Last Spoke)

[Leak]

Ouch.

Just did an encode of the opening (2181 frames) and got this frame (http://140.78.145.103:8888/~kp/Stuff/GITS_SAC_01_1381_b0rked.png), which definitely happened in the middle of an encode, not while previewing. It definitely doesn't look that way in the source, and since I encoded to HuffYUV I doubt it's a borked codec, as I noticed the same bad frame when I used XviD a few minutes earlier... :(

My script:


source=MPEG2Source("e:\DVD\GITS_SAC_1\GITS_SAC_01\VIDEO_TS\Video.d2v",cpu=4,moderate_h=30,moderate_v=60,iPP=true,idct=7)

a=source

a=a.TFM(mode=1,pp=7,display=false)
a=a.TDecimate(mode=1,hybrid=1,vidThresh=0.5,display=false)

newWidth=(Int(a.width*1.05+1)/4)*4
newHeight=(Int(a.height*1.05+1)/4)*4

a=a.LanczosResize(newWidth,newHeight)
a=a.Crop(18,8,720,480,align=true)

a=a.MipSmooth(preset="AnimeHQ") #,temporal=0,temporal_chroma=0)

a.Trim(0,2180)

AssumeFPS(25.0)


Now, I don't think that this is caused by TFM or TDecimate, as these operate with full fields when producing new frames and only operate on blocks to calculate the metrics for the fields. It also doesn't seem to be MipSmooth, as those blocks in the picture have clearly been resized, and I can't believe it would be the resize, the crop, the trim or the AssumeFPS.

This might be caused by TFM or TDecimate requesting frames out-of-order, going back and forth over the file, but that still shouldn't cause such artifacts to pop up. :(

Maybe releasing a new DGDecode version should be postponed a bit... :(

EDIT: re-starting VirtualDubMod, loading the exact same script jumping to frame 1100 and advancing forward with cursor right to frame 1381 gives me exactly the same broken output, so I'd say it's reproducible as well.

Also, I guess MipSmooth's temporal filtering might also cause out-of-order frame fetches, as putting a "return a" after the TDecimate call doesn't produce a broken frame. Hmmm - maybe putting a debug output statement into DGDecode that logs which frames are fetched would be a start?

np: Keishi Urata - Blind Faith (Texhnolyze OST The Man Of Men)

[Nic]

Great find in that clip you sent me Leak :) Very reproducable problem...will look into it now. That shouldn't be happening...Thanks for providing everything needed :)

-Nic

[Leak]

Originally posted by Nic
Great find in that clip you sent me Leak :) Very reproducable problem...will look into it now. That shouldn't be happening...Thanks for providing everything needed :)

Well, if you want you can have the whole intro - or do you think the bustage after refreshing and the cause for those broken frames while encoding are the same?

I'll bring a CD with the whole intro into work tomorrow and if you want I can upload it too (~85MB) - just give me a holler. :)

np: Yoko Kanno - Beauty is Within Us (Ghost In The Shell Stand Alone Complex OST 1)

[Nic]

@Leak:
Well, I know roughly what the problem is...

It's to do with DG's addition of Quick Seeking to frames. In DGIndex he marks in the d2v any frames that only references frames inside the current GOP.

I'm finding it hard to tell where the problem lies, in DGIndex or DGDecode. I have a feeling it's in DGIndex. One possible reason for the problem is when a VOB has the closed_gop flag set, but really isn't closed and has b-frames referencing other GOPs. That would cause this problem as DGIndex would mark the B-Frames as being Quick-Seekable frames.

Anyway, I think a lot of people wouldn't care about having Quick Seeking, as the difference in speed would only be very small in most instances (and in linear encoding, no speed difference at all). So I could add a Registry Key so people can turn it off in DGDecode and then the problem would go away....

Sound good?

@Leak: If you can, upload away :)

-Nic

[Leak]

Originally posted by Nic
@Leak:
Well, I know roughly what the problem is...

It's to do with DG's addition of Quick Seeking to frames. In DGIndex he marks in the d2v any frames that only references frames inside the current GOP.

I'm finding it hard to tell where the problem lies, in DGIndex or DGDecode. I have a feeling it's in DGIndex. One possible reason for the problem is when a VOB has the closed_gop flag set, but really isn't closed and has b-frames referencing other GOPs. That would cause this problem as DGIndex would mark the B-Frames as being Quick-Seekable frames.

Anyway, I think a lot of people wouldn't care about having Quick Seeking, as the difference in speed would only be very small in most instances (and in linear encoding, no speed difference at all). So I could add a Registry Key so people can turn it off in DGDecode and then the problem would go away....

Sound good?

Well, old versions of DVD2AVI were slow as hell when seeking to a non-I-frame, and jumping around or ($DEITY forbid) going backwards through a file was a real pain, so when Donald speeded things up I was really jumping for joy. After all, when looking for cutting points or trying out filter combinations you tend to seek around in the file a lot...

Does this only happen with B-frames? If that's the case, how about keeping P-frames quick-seekable instead of throwing this out completely? Or could DGIndex be changed (with a reasonable amount of changes) to notice those frames that do reference other GOPs and thus be fixed properly?

@Leak: If you can, upload away :)

Okay, I've done it already and I'll PM you the link. :)

np: El-P - Squeegee Man Shooting (Original Version) (FanDam Plus (Disc 2))

[Nic]

Does this only happen with B-frames? If that's the case, how about keeping P-frames quick-seekable instead of throwing this out completely? Or could DGIndex be changed (with a reasonable amount of changes) to notice those frames that do reference other GOPs and thus be fixed properly?

Well, I could make it so just B-Frames are non exact seekable, but MPEG-2 files mainly consist of B Frames, so it wouldn't alleviate slow seeking much...

Can DGIndex be fixed to work 100% of the time? Probably, but the problem would be testing for each individual situation, which would take time...I'll try somethings out...

-Nic

ps
EDIT: Ok, something isn't make much sense. Even with B-Frames set to non quick-seekable, it still happens on some frames (such as frame 343). Not sure how this is happening at all now, unless DGDecode is doing something seriously wrong...(such as screwing up seeking when they're are repeated fields...)

pps
Ok, Scratch that...I think frame 343 is broken in the first M2V file that Leak is sending me...So maybe it's errors in the file, that are causing this problem.

[Nic]

Ok,

I was in error, with my last few ps's.

As far as I can tell DGDecode/Index are broken. Proper broken when concerning certain files.

Try comparing seeking with it compared to DVD2AVI 1.77.3 and MPEG2Dec3. You end up with completely different frames on certain files. Also frame 343 in the test MPEG that Leak gave me is corrupt no matter how you decode it with DGDecode.dll (including seeking and playing back normally). The file is completely fine in MPEG2Dec3 !!!

Very strange I know....Long story short, I finished MPEGDecoder to be a replacement for DGDecode a while back (after Mug Funky, had pointed out bugs). But couldn't get it to seek like DGDecode with some files even though I thought my code was 100% correct....Now I think I know why.

Here's the file Leak gave me, can someone else (Lenox?) do some tests:
http://nic.dnsalias.com/GITS_SAC_01.m2v (31mb)

-Nic

[len0x]

Originally posted by Nic
Here's the file Leak gave me, can someone else (Lenox?) do some tests:
http://nic.dnsalias.com/GITS_SAC_01.m2v (31mb)


What are we testing exactly ?

[Nic]

Ok,

Load that M2V file into DGIndex & DGDecode as well as into DVD2AVI & MPEG2Dec3. Check frame 343 in both (frame 343 doesn't even reference the same picture in both, but you'll see what I mean). Look at how that picture is corrupt in an AVS using DGDecode and not in MPEG2Dec3 (even when just playing back the file)....

I think DGDecode & MPEG2Dec3 seeking to completely different frames and DGDecode causing corrupt frames is a pretty bad thing....But I may just be misunderstanding something obvious, and that's why I'd like others to check

-Nic

ps
Actually maybe DGDecode can decode frame 343 ok, it's sometimes hard to tell because of frame cacheing. It certainly can't seek to it no matter what (even with a d2v marked with no easily seekable frames)

pps
The seeking to different frames part, from testing also seems like the issues got when the file doesn't start on a closed GOP, so DGDecode/Index correctly have the right number of frames when MPEG2Dec3 doesn't. However, there's no warning of this in DGIndex like normal...

[len0x]

As far as I can tell only random seeking is broken. When I open this sample file in VDubMod and go to a specific frame - its broken, but after a while of advancing frame by frame, it becomes normal (and looks like VDubMod actually caching frames, because if you go back you still see broken frames). So next I opened d2v in GK (which uses DGDecode directly and requests a frame every time its needed): it seeks to frame 339 automatically and that one is broken, scroll upto 344 - it becomes OK, then scroll back - everything seems to be fine.

[Nic]

Ok, cool, I'll work on that assumption, thanks Lenox :) (You know the apps far better than me I'm sure).

I can hack a fix pretty easy, but don't know why the fix works...or what's going wrong in the first place...grrr ;)

-Nic

[Cyberia]

Boys. Me thinks you have a bad clip.

Open the clip directly in VdubMod (1.5.10.1) and get the File Information. Did VDubMod GPF? It does for me, every time.

AviSynth refuses to return anything from the info() command when called on the d2v file.

You can also open the mpeg in AviSynth using DirectShowSource and it says the mpeg has 890 frames.

VirtualDub (1.6.1) says the d2v file has 1017 frames.
DGIndex says it has 1016 frames.
Gspot says it has 890 frames.

[Leak]

Originally posted by Cyberia
Boys. Me thinks you have a bad clip.

Maybe, but that still doesn't explain why these errors only show up with the DGIndex/DGDecode combo.

Open the clip directly in VdubMod (1.5.10.1) and get the File Information. Did VDubMod GPF? It does for me, every time.

Yes, it does - and it does it on the 3 other clips I've tried it with as well, each of which came from a different DVD and were ripped with DVD Decrypter. I'd chalk that up as a VirtualDubMod bug, not as a problem with this specific file...

AviSynth refuses to return anything from the info() command when called on the d2v file.


source=MPEG2Source("GITS_SAC_01.d2v",cpu=4,moderate_h=30,moderate_v=60,iPP=true,idct=7)

source.Info()


works as expected for me.

You can also open the mpeg in AviSynth using DirectShowSource and it says the mpeg has 890 frames.

VirtualDub (1.6.1) says the d2v file has 1017 frames.
DGIndex says it has 1016 frames.
Gspot says it has 890 frames.

Yeah, that's strange, but that's what the current version of Cuttermaran produced. If I play it in Graphedit using ffdshow as the MPEG2 decoder, I still get 1013 frames out of it. I don't think that this impacts the frames themselves, though.

Also, no matter what frame I hit F5 in VirtualDubMod on, I always get a broken frame first that gets gradually cleaned up until DGDecode hits an I-frame. Maybe that's bad authoring on the discs part, but I never get the same thing when I seek around in MPC on the M2V file generated by DVD Decrypter...

Okay, so I never had this behaviour with other discs, and maybe Bandai's authoring house really jumped the shark, but since other decoders don't produce bad frames on this DVD I'd have to assume that DGDecode has a bug.

np: Yasushi Ishii - Requiem For The Living (Hellsing Original Soundtrack Raid)

[Cyberia]

I got info() to work, typo.

More differences:

When opened through DGDecode, Info() indicates the clip is TFF, FRAME based.

When opened through DSSource, Info() indicates the clip is BFF, FRAME based.

DGIndex indicates the clip is TFF, FIELD based.

DGParse indicates EVERY FRAME is a pattern break. (I think I'm reading that right.) That's wierd.

[Nic]

Maybe you're right Cyberia, and this clip is just one of those weird clips and that normal clips are 100% fine in DGDecode...(Which I hope)

But still, it would be nice for this clip to be working 100% in DGDecode (as it does in MPEG2Dec3).

So maybe it's not a big problem, but it's one i'd like to fix and look into more. Although, i'm short on time right now. But at least there's a reference here in this thread that we can come back to :)

Cheers,
-Nic

[Leak]

Originally posted by Nic
Maybe you're right Cyberia, and this clip is just one of those weird clips and that normal clips are 100% fine in DGDecode...(Which I hope)

But still, it would be nice for this clip to be working 100% in DGDecode (as it does in MPEG2Dec3).

So maybe it's not a big problem, but it's one i'd like to fix and look into more. Although, i'm short on time right now. But at least there's a reference here in this thread that we can come back to :)

Ummm - whatever you did in DVD2AVI_Nic, it's working perfectly now... :D

Since I'm still using the same DGDecode.dll I've always used there must've been something funky in DGIndex, as the offsets in the D2V file your DVD2AVI produces are completely different - and using that DGDecode magically starts working... ;)

To wit:

DGIndex:
7 0 96 0 0 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 190816 0 0 2 2 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 403554 0 0 12 12 12 12 12 12 12 12 12 12 12 12
7 0 661437 0 0 2 2 12 12 12 12 12 12 12 12 12 12
...

DVD2AVI_Nic:
7 0 0 0 0 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 190464 0 0 2 2 12 12 12 12 12 12 12 12 12 12 12 12 12
7 0 403456 0 0 12 12 12 12 12 12 12 12 12 12 12 12
7 0 659456 0 0 2 2 12 12 12 12 12 12 12 12 12 12
...

I have only one problem now - DVD2AVI_Nic is missing the command line support that DGIndex has, which would be what I need to use it as a drop-in replacement for DGIndex; I assume that currently your DVD2AVI completely ignores it's command line? :(

Still, thanks a lot for a program that generates working D2V files for this DVD... :)

np: Gescom - Keynell 2 (Keynell EP)

[Nic]

Glad I'm doing something right with DVD2AVI_Nic. It's in the early stages...I'll try and add Commandline support (same as DGIndex) soon :)

-Nic

[Leak]

Originally posted by Nic
Glad I'm doing something right with DVD2AVI_Nic. It's in the early stages...I'll try and add Commandline support (same as DGIndex) soon :)

-Nic

I fear I have to correct myself - with the D2V file generated by DGIndex, I got artefacts no matter where I hit F5; I just found one spot in the file where I still get those artefacts. In other words, it got better, but it's not perfect - YET. :D

Then again, it looks like this only happens when seeking to this frame, as I get a perfectly fine frame if I framestep there from 50 frames away. Before, I had a few frames in the intro that were garbled no matter how I seeked there, so there'd be garbage even when encoding, which doesn't seem to be the case here.

Also, TIVTC magically doesn't choke anymore on a few scenes and scenechanges that it had problems with before...

I'm curious - could you perhaps add a bit of code to DGDecode that writes the currently used file offset (and/or D2V line number) and flags as debug output? That'd make it easy to find the entry in the D2V file that's the culprit...

np: Autechre - Second Peng (Anvil Vapre)

[Leak]

Originally posted by Leak
I fear I have to correct myself - with the D2V file generated by DGIndex, I got artefacts no matter where I hit F5; I just found one spot in the file where I still get those artefacts. In other words, it got better, but it's not perfect - YET. :D

Okay, I'm giving up on this for now - I've noticed that one prominent scene in the intro still gets weird when playing through it, but the first frame that's borked this way looks totally fine if I hit F5 on it in VirtualDub.

Then again, the whole scene looks fine in Media Player Classic using the built-in MPEG2 decoder... something is totally screwed up here, and I still can't believe that it's my M2V file...

I'll try using mencoder to transcode the file to HuffYUV and see what happens then...

EDIT: After using mencoder to convert the whole M2V to an AVI and watching DebugView while using my script on it, I noticed that ffdshow did a lot of jumping around while processing - it turns out that TFM and TDecimate only use a frame cache of 1, but process cycles of 5 or more - adding a SetCache(clip,25) after the source took care of the seeks and the artifacts in the intro magically vanished as well... d'oh! :eek:

np: Gescom - Keynell (Mix 1) (Keynell (AE Mixes))

[Guest]

Originally posted by Nic
The DLL...if you're a bit of a coder, get the source, and look in a file called getbit.c search for the word "lazy". DG was obviously feeling a bit lazy that day, and even commented on it ;) (So I fixed that bit) Sorry for being lazy. I'm going to fix these issues, starting with this one.

Please tell me where to get the source with the fix for this lazy thing? Thank you.

EDIT: Never mind, I figured it out and fixed it. Actually, that lazy comment I think came from another developer (I ported the transport code). My comments start with capital letters and end with periods. :)

OK, now I will look at the seeking issue.

EDIT2: I have the Leak clip and confirm the seeking bug. I've fixed problems like this before so I know what to do. Obviously, it's important to have bullet-proof seeking.

[Guest]

This seeking bug is really weird. Everything looks correct but it still happens. I'm wondering if they change quant matrices throughout the file. That would be bad for the random seeking if we seek directly to a picture header and miss a quant change in a previous sequence header. Still investigating...

EDIT: Yup, that's it. I used the General Parser utility to examine all the sequence header quant matrices. There is one set for the first two GOPs and then it changes on the 3rd GOP and remains for the rest of the file. Next I tested Leak's file by loading it and playing the first 100 frames and stopping, in order to pick up the quant change. Then if you random access to frame 343 it is fine.

Now I have to decide how to fix it. I remember thinking vaguely about this when deciding to index the GOP with the first picture header. Now it seems it needs to be to the sequence header. That should not be too difficult.

[Nic]

@Neuron2: Wow, well spotted. That never even occurred to me....Good luck solving it.

[Guest]

Ouch, this is harder than I thought. The problem is that it is legal to have just one sequence header and then just repeat GOPs the rest of the way with no more sequence headers. Obviously, you can't index sequence headers in that case.

Gotta sleep on this one...

[Guest]

OK, here's the plan. Per frame, I will index the sequence header if there is one, otherwise I will index the picture header. This assumes that a stream that changes quant matrices will include sequence headers for every GOP. If they did not, random access would be a nightmare, because you'd have to record and jump back to the sequence header that contains the new quants, etc. I have never seen a stream that does that.

Any thoughts, Nic?

EDIT: Here's a beta of this fix. It works correctly with Leak's file.

http://neuron2.net/fixd2v/DGIndex1.0.13b3.zip

[Leak]

Originally posted by neuron2
Here's a beta of this fix. It works correctly with Leak's file.

http://neuron2.net/fixd2v/DGIndex1.0.13b3.zip

Not only that, I also couldn't find other bad spots in the whole episode (even though I only seeked round randomly in it and hit F5 a lot... :))

Seems to be working poifectly... ;)

np: Iwasaki Taku - Tactics (Witch Hunter Robin OST 1)