DGAVCDec 1.0.9

[Guest]

It's a Transport Stream. Didn't the 0x47 at the beginning tip you off?
Yes, it did, but the one at location 0x50 made me think it was spurious. I should have looked at more sync bytes to find the 188-byte sync. But I was busy with the info dialog and only looked at it briefly.

After demuxing, it plays fine with CoreAVC but it crashes VLC, so libavcodec doesn't like it. Therefore, it doesn't work in DGAVCDec either. Most likely the PAFF encoding is the problem.

[tjmitchem]

Yes, it did, but the one at location 0x50 made me think it was spurious. I should have looked at more sync bytes to find the 188-byte sync. But I was busy with the info dialog and only looked at it briefly.

After demuxing, it plays fine with CoreAVC but it crashes VLC, so libavcodec doesn't like it. Therefore, it doesn't work in DGAVCDec either. Most likely the PAFF encoding is the problem.

This is weird. If that was a transport stream, then it means that the demuxer I used is not really demuxing the stream.

I just redid the file with a different demuxer. Can someone take a look at it now and tell me if it's actually a raw H.264 stream? I cut the file down to 5MB

Thanks,
Terry

[Guest]

I just redid the file with a different demuxer. Can someone take a look at it now and tell me if it's actually a raw H.264 stream? Yes, that is a raw stream.

[tjmitchem]

Yes, that is a raw stream.

Thanks.

[D-Train]

I installed 1.0.0 Alpha 8 and tried to index a file. The stream came from DishNetwork and contains PAFF. I know it's not supported, but decided to try it just for the heck of it.

I also have a bunch of Dish Network HD files I've been wanting to re-encode. You can download a small sample here (darren78.homeip.net/dish_hd.264) (hopefully downloading is not too slow).

I know these are PAFF, and I'm pretty sure they have no IDR frames. I think this combination causes issues for libavcodec. For the larger files (1 hour), seek times are really bad. Avisynth basically hangs for 20 minutes per seek. Anyways, if someone wants to experiment with this then have at it. The uploaded file indexes fine but only decodes the first frame.

Thanks neuron2, I'm mostly a lurker but have found a lot of use for DGMPGDec, and now DGAVCDec.

[Guest]

Thank you for the test stream. Fairly soon, I will be turning my attention to this libavcodec problem with some PAFF streams.

[Guest]

* Lots of GUI bugs and crashing bugs fixed.

* New info window field: max bitrate seen.

* Major code cleanup and purging of DGIndex leftovers. Conversion to exclusive C++ compilation.

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

Please delete your INI file before running this, or replace it with the one in the zip file.

Note that the previous message box popup for forcing the IVTC'ed frame rate is now replaced by Force Film in the Video menu. I have not yet implemented decimation of non-film sections, so for now this will not work on hybrid video.

With the disappearance of a lot of menu options, some explanation is in order. It is really very hard to integrate the container parsers with the stream buffering, NALU parsing, and parallel parsing and keep everything working right. For DGMPGDec, it is a nightmare that I still lose sleep over. I'm not sure I even fully understand how it works and if it is provably correct. I do know of several low-probability cases that can cause explosions. Yes, it's low probability but with enough uses, it's going to happen to someone. The code base is also very hard to modify and enhance.

So I am taking a new tack with DGAVCDec. I want to keep it simple and provably correct. So my plan is that cutting, demuxing, container verification and repair, etc., will be done by separate tools. DGAVCDec will be for serving video only. There are existing tools for these things but I plan to make my own and make them available via the Tools menu. This approach will allow me to keep my sanity as well as to continue moving forward despite my limited time for coding these days. I don't need another massive nightmare on my hands!

Probably, then, the [ and ] arrow keys will simply allow for cutting out portions of your AVC raw stream. Yes, you can use Trim() in your script, but it's more convenient this way and it's useful sometimes to generate a cut AVS raw stream as well.

[canTsTop]

thank you neuron2 for your great tool.
in my video, i noticed in information windows, aspect ration is 12:11 but i think it should be 15:11
http://img210.imageshack.us/img210/8998/infora8.png

:confused:

[Guest]

It prints what is in the stream. Why do you think it should be something else? Can you post a link to the stream?

[LigH]

It is about pixel aspect ratio (stored pixels vs. straightened-for-display pixels)

12:11 ~ 785:720 (the width of 785 was calculated as 720*12:11)

[canTsTop]

sorry for my mistake, i thought it was display aspect ratio.
576*15:11~785

this is my sample http://rapidshare.com/files/71446036/raw.h264.html

p.s. i would be grateful if some one advise how to deal with this video, demuxed audio is 3min 17s but video is 4min 11s :confused:

[Guest]

p.s. i would be grateful if some one advise how to deal with this video, demuxed audio is 3min 17s but video is 4min 11s :confused: I can't help you with just the raw stream. You'll have to supply the un-demuxed source container sample.

[canTsTop]

thank you for answer, this is un-demuxed TS sample http://rapidshare.com/files/71459314/ttt.ts.html

[g0blez]

I have a question concerning the latest alpha 10.
I've demuxed an EVO file. evodemux claimed the source was 60fps. However, looking at the number of calculated frames and taking into consideration the total length of the stream, I calculated that the frame rate was 23.976fps.

When I opened the demuxed mpv (h.264) file in DGAVCDec, the frame rate listed was 29.970030 fps.
How should I treat this stream? Should I force film it?

[bob0r]

thank you for answer, this is un-demuxed TS sample http://rapidshare.com/files/71459314/ttt.ts.html

Heh, interesting, the .ts file contain no errors, but when you demux/remux the h.264 file, it is indeed: 04:10, while the .ts plays as 03:17

I remuxed the video into .mkv and it plays uhm, variable FPS, i never seen this before.

[drmpeg]

Heh, interesting, the .ts file contain no errors, but when you demux/remux the h.264 file, it is indeed: 04:10, while the .ts plays as 03:17

I remuxed the video into .mkv and it plays uhm, variable FPS, i never seen this before.
It's a PAFF bitstream that actually switches between field and frame pictures. Here's the output from the reference decoder that shows if a frame is a field pair.

----------------------------- JM 13.0 (FRExt) -----------------------------
Decoder config file : (null)
--------------------------------------------------------------------------
Input H.264 bitstream : bits0001.mpv
Output decoded YUV : test_dec.yuv
Output status file : log.dec
Input reference file : test_rec.yuv does not exist
SNR values are not available
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
Frame POC Pic# QP SnrY SnrU SnrV Y:U:V Time(ms)
--------------------------------------------------------------------------
Warning: Decoding does not start with an IDR picture.
00023( I ) 46 96 30 4:2:0 220
00020( b ) 40 97 30 4:2:0 150
00021( b | b ) 43 97 51 4:2:0 130
00022( b ) 44 97 48 4:2:0 111
00027( P ) 54 97 33 4:2:0 160
00024( b ) 48 98 29 4:2:0 100
00025( b ) 50 98 33 4:2:0 110
00026( b ) 52 98 32 4:2:0 110
00031( P ) 62 98 31 4:2:0 181
00028( b ) 56 99 28 4:2:0 150
00029( b ) 58 99 31 4:2:0 120
00030( b ) 60 99 31 4:2:0 140
00035( P ) 70 99 30 4:2:0 180
00032( b ) 64 100 27 4:2:0 121
00033( b ) 66 100 30 4:2:0 150
00034( b ) 68 100 30 4:2:0 130
00039( P ) 78 100 29 4:2:0 190
00036( b ) 72 101 26 4:2:0 130
00037( b ) 74 101 30 4:2:0 121
00038( b ) 76 101 30 4:2:0 120
00043( P ) 86 101 29 4:2:0 200
00040( b ) 80 102 26 4:2:0 130
00041( b ) 82 102 30 4:2:0 130
00042( b ) 84 102 30 4:2:0 141
00047( P ) 94 102 30 4:2:0 160
00044( b ) 88 103 27 4:2:0 130
00045( b ) 90 103 30 4:2:0 130
00046( b ) 92 103 30 4:2:0 120
00051( P ) 102 103 30 4:2:0 141
00048( b ) 96 104 27 4:2:0 170
00049( b ) 98 104 30 4:2:0 220
00050( b ) 100 104 30 4:2:0 120
00055( P ) 110 104 30 4:2:0 151
00052( b ) 104 105 27 4:2:0 120
00053( b ) 106 105 30 4:2:0 130
00054( b ) 108 105 30 4:2:0 120
00059( P ) 118 105 30 4:2:0 140
00056( b ) 112 106 27 4:2:0 241
00057( b ) 114 106 30 4:2:0 130
00058( b ) 116 106 30 4:2:0 110
00063( P ) 126 106 30 4:2:0 130
00060( b ) 120 107 27 4:2:0 130
00061( b ) 122 107 30 4:2:0 131
00062( b ) 124 107 30 4:2:0 120
00067( P ) 134 107 30 4:2:0 220
00064( b ) 128 108 27 4:2:0 130
00065( b ) 130 108 30 4:2:0 130
00066( b ) 132 108 30 4:2:0 131
00068( P ) 136 108 30 4:2:0 140
00069( P ) 138 109 27 4:2:0 140
00000(IDR| P ) 1 0 24 4:2:0 341
00001( I | P ) 3 1 31 4:2:0 250
00002( P | P ) 5 2 37 4:2:0 190
00003( P | P ) 7 3 41 4:2:0 170
00004( P | P ) 9 4 42 4:2:0 171
00005( P ) 10 5 39 4:2:0 210
00006( P ) 12 6 40 4:2:0 190
00007( P ) 14 7 40 4:2:0 181
00008( P ) 16 8 39 4:2:0 220
00009( P ) 18 9 37 4:2:0 200
00010( P | P ) 21 10 38 4:2:0 381
00014( P ) 28 11 32 4:2:0 260
00011( b ) 22 12 35 4:2:0 210
00012( b ) 24 12 33 4:2:0 221
00013( b ) 26 12 33 4:2:0 230
00018( P ) 36 12 32 4:2:0 280
00015( b ) 30 13 29 4:2:0 261
00016( b ) 32 13 32 4:2:0 240
00017( b ) 34 13 31 4:2:0 240
00019( P ) 38 13 31 4:2:0 281
00020( P ) 40 14 28 4:2:0 240
00024( P ) 48 15 28 4:2:0 271
00021( b ) 42 16 29 4:2:0 210
00022( b ) 44 16 31 4:2:0 220
00023( b ) 46 16 30 4:2:0 211
00028( P ) 56 16 29 4:2:0 280
00025( b ) 50 17 26 4:2:0 220
00026( b ) 52 17 29 4:2:0 221
00027( b ) 54 17 28 4:2:0 230
00029( P ) 58 17 28 4:2:0 280
00030( P ) 60 18 25 4:2:0 261
00031( P ) 62 19 27 4:2:0 240
00032( P | P ) 65 20 32 4:2:0 240
00033( P | P ) 67 21 32 4:2:0 261
00034( P | P ) 69 22 33 4:2:0 400
00035( P | P ) 71 23 33 4:2:0 251
00036( P | P ) 73 24 32 4:2:0 240
00037( P ) 74 25 29 4:2:0 230
00038( P | P ) 77 26 33 4:2:0 591
00039( P | P ) 79 27 32 4:2:0 241
00040( P | P ) 81 28 32 4:2:0 260
00041( P | P ) 83 29 34 4:2:0 260
00042( P | P ) 85 30 34 4:2:0 241
00046( P | P ) 93 31 35 4:2:0 240
00043( b | b ) 87 32 36 4:2:0 230
00044( b | b ) 89 32 37 4:2:0 231
00045( b | b ) 91 32 35 4:2:0 230
00047( P | P ) 95 32 30 4:2:0 250
00051( P | P ) 103 33 31 4:2:0 271
00048( b | b ) 97 34 36 4:2:0 230
00049( b | b ) 99 34 34 4:2:0 250
00050( b | b ) 101 34 35 4:2:0 221
00000(IDR| P ) 1 0 30 4:2:0 320
00001( P | P ) 3 1 32 4:2:0 231
00002( P | P ) 5 2 32 4:2:0 220
00003( P | P ) 7 3 32 4:2:0 230
00007( P | P ) 15 4 33 4:2:0 241
00004( b | b ) 9 5 37 4:2:0 300
00005( b | b ) 11 5 35 4:2:0 270
00006( b | b ) 13 5 34 4:2:0 251
00008( P | P ) 17 5 31 4:2:0 280
00012( P | P ) 25 6 25 4:2:0 260
00009( b | b ) 19 7 29 4:2:0 281
00010( b | b ) 21 7 28 4:2:0 230

The reference decoder produces 4940 frames from this bitstream. 4940 / 25 = 197.6 seconds, or 3 minutes 17.6 seconds.

Ron

[G_M_C]

I'll tabe a stab at guessing why this is;

My guess it that it is a TS from a digital TV-station that has used this method to "speed-up" and/or "speed-down" parts of the movie, so that it'll fit nicely bewtween commercial breaks.

I've seen movies encoded in MPEG2 with variable pull-up/pull-down rhythms, for the same reasons (Finding Nemo, ABC, Xmas last year springs to mind)

[LigH]

Thread Topic Reminder:

DGMPGDec 1.0.0a10 was already released.

[Guest]

I have a question concerning the latest alpha 10.
I've demuxed an EVO file. evodemux claimed the source was 60fps. However, looking at the number of calculated frames and taking into consideration the total length of the stream, I calculated that the frame rate was 23.976fps.

When I opened the demuxed mpv (h.264) file in DGAVCDec, the frame rate listed was 29.970030 fps.
How should I treat this stream? Should I force film it? Do you see frame repeats in the Info dialog when you preview it? If so, then Force Film may be correct. If not, can I please see a sample of the stream?

[g0blez]

Do you see frame repeats in the Info dialog when you preview it? If so, then Force Film may be correct. If not, can I please see a sample of the stream?

No Frame Rpts.
I get Field Rpts however; do you still need a sample?

[g0blez]

What I've done...

DGAVCDEC:
- Opened .mpv file (h.264 stream)
- Selected force film
- Saved project as dga; during the long process (source is accessed by wifi network), I got one pop-up mentioning something about "NALUs'. Sorry, I didn't carefully read but chose to ignore it.

Notepad:

- Created AVS script:
loadplugin("C:\Program Files\dgavcdec100a10\DGAVCDecode.dll")
AVCSource("video.dga")
Lanczos4Resize(1280,720)

meGUI (x264 build 699):

- Selected SA-HD-DVD profile, RAWAVC container
- Started 1st Pass; at the end of the pass, I got the following logs:
[h264 @ 6FD461F0]reference picture missing during reorder
[h264 @ 6FD461F0]error while decoding MB 18 59, bytestream (td)
[h264 @ 6FD461F0]left block unavailable for requested intra4x4 mode -1 at 0 46
[h264 @ 6FD461F0]error while decoding MB 0 46, bytestream (td)
[h264 @ 6FD461F0]left block unavailable for requested intra4x4 mode -1 at 0 38
[h264 @ 6FD461F0]error while decoding MB 0 38, bytestream (td)
[h264 @ 6FD461F0]reference picture missing during reorder
[h264 @ 6FD461F0]left block unavailable for requested intra mode at 0 10
[h264 @ 6FD461F0]error while decoding MB 0 10, bytestream (td)
[h264 @ 6FD461F0]reference picture missing during reorder


I realize I have an issue but I'm not sure if this is caused by DGAVCDEC or something else.
neuron2, can you comment?

[Guest]

As I said, I need the source stream.

[Turtleggjp]

I have a question concerning the latest alpha 10.
I've demuxed an EVO file. evodemux claimed the source was 60fps. However, looking at the number of calculated frames and taking into consideration the total length of the stream, I calculated that the frame rate was 23.976fps.

When I opened the demuxed mpv (h.264) file in DGAVCDec, the frame rate listed was 29.970030 fps.
How should I treat this stream? Should I force film it?

I ran into this same thing when I transcoded my HD-DVD of Transformers. I was concerned, but I just added AssumeFPS(23.976) to my AVI Synth script, and everything came out fine. I used Alpha 6 (that was the latest when I did this) so there was no Force Film option available then.

[canTsTop]

It's a PAFF bitstream that actually switches between field and frame pictures. Here's the output from the reference decoder that shows if a frame is a field pair.

----------------------------- JM 13.0 (FRExt) -----------------------------
Decoder config file : (null)
--------------------------------------------------------------------------
Input H.264 bitstream : bits0001.mpv
Output decoded YUV : test_dec.yuv
Output status file : log.dec
Input reference file : test_rec.yuv does not exist
SNR values are not available
--------------------------------------------------------------------------
POC must = frame# or field# for SNRs to be correct
--------------------------------------------------------------------------
Frame POC Pic# QP SnrY SnrU SnrV Y:U:V Time(ms)
--------------------------------------------------------------------------
Warning: Decoding does not start with an IDR picture.
00023( I ) 46 96 30 4:2:0 220
00020( b ) 40 97 30 4:2:0 150
00021( b | b ) 43 97 51 4:2:0 130
00022( b ) 44 97 48 4:2:0 111
00027( P ) 54 97 33 4:2:0 160
00024( b ) 48 98 29 4:2:0 100
00025( b ) 50 98 33 4:2:0 110
00026( b ) 52 98 32 4:2:0 110
00031( P ) 62 98 31 4:2:0 181
00028( b ) 56 99 28 4:2:0 150
00029( b ) 58 99 31 4:2:0 120
00030( b ) 60 99 31 4:2:0 140
00035( P ) 70 99 30 4:2:0 180
00032( b ) 64 100 27 4:2:0 121
00033( b ) 66 100 30 4:2:0 150
00034( b ) 68 100 30 4:2:0 130
00039( P ) 78 100 29 4:2:0 190
00036( b ) 72 101 26 4:2:0 130
00037( b ) 74 101 30 4:2:0 121
00038( b ) 76 101 30 4:2:0 120
00043( P ) 86 101 29 4:2:0 200
00040( b ) 80 102 26 4:2:0 130
00041( b ) 82 102 30 4:2:0 130
00042( b ) 84 102 30 4:2:0 141
00047( P ) 94 102 30 4:2:0 160
00044( b ) 88 103 27 4:2:0 130
00045( b ) 90 103 30 4:2:0 130
00046( b ) 92 103 30 4:2:0 120
00051( P ) 102 103 30 4:2:0 141
00048( b ) 96 104 27 4:2:0 170
00049( b ) 98 104 30 4:2:0 220
00050( b ) 100 104 30 4:2:0 120
00055( P ) 110 104 30 4:2:0 151
00052( b ) 104 105 27 4:2:0 120
00053( b ) 106 105 30 4:2:0 130
00054( b ) 108 105 30 4:2:0 120
00059( P ) 118 105 30 4:2:0 140
00056( b ) 112 106 27 4:2:0 241
00057( b ) 114 106 30 4:2:0 130
00058( b ) 116 106 30 4:2:0 110
00063( P ) 126 106 30 4:2:0 130
00060( b ) 120 107 27 4:2:0 130
00061( b ) 122 107 30 4:2:0 131
00062( b ) 124 107 30 4:2:0 120
00067( P ) 134 107 30 4:2:0 220
00064( b ) 128 108 27 4:2:0 130
00065( b ) 130 108 30 4:2:0 130
00066( b ) 132 108 30 4:2:0 131
00068( P ) 136 108 30 4:2:0 140
00069( P ) 138 109 27 4:2:0 140
00000(IDR| P ) 1 0 24 4:2:0 341
00001( I | P ) 3 1 31 4:2:0 250
00002( P | P ) 5 2 37 4:2:0 190
00003( P | P ) 7 3 41 4:2:0 170
00004( P | P ) 9 4 42 4:2:0 171
00005( P ) 10 5 39 4:2:0 210
00006( P ) 12 6 40 4:2:0 190
00007( P ) 14 7 40 4:2:0 181
00008( P ) 16 8 39 4:2:0 220
00009( P ) 18 9 37 4:2:0 200
00010( P | P ) 21 10 38 4:2:0 381
00014( P ) 28 11 32 4:2:0 260
00011( b ) 22 12 35 4:2:0 210
00012( b ) 24 12 33 4:2:0 221
00013( b ) 26 12 33 4:2:0 230
00018( P ) 36 12 32 4:2:0 280
00015( b ) 30 13 29 4:2:0 261
00016( b ) 32 13 32 4:2:0 240
00017( b ) 34 13 31 4:2:0 240
00019( P ) 38 13 31 4:2:0 281
00020( P ) 40 14 28 4:2:0 240
00024( P ) 48 15 28 4:2:0 271
00021( b ) 42 16 29 4:2:0 210
00022( b ) 44 16 31 4:2:0 220
00023( b ) 46 16 30 4:2:0 211
00028( P ) 56 16 29 4:2:0 280
00025( b ) 50 17 26 4:2:0 220
00026( b ) 52 17 29 4:2:0 221
00027( b ) 54 17 28 4:2:0 230
00029( P ) 58 17 28 4:2:0 280
00030( P ) 60 18 25 4:2:0 261
00031( P ) 62 19 27 4:2:0 240
00032( P | P ) 65 20 32 4:2:0 240
00033( P | P ) 67 21 32 4:2:0 261
00034( P | P ) 69 22 33 4:2:0 400
00035( P | P ) 71 23 33 4:2:0 251
00036( P | P ) 73 24 32 4:2:0 240
00037( P ) 74 25 29 4:2:0 230
00038( P | P ) 77 26 33 4:2:0 591
00039( P | P ) 79 27 32 4:2:0 241
00040( P | P ) 81 28 32 4:2:0 260
00041( P | P ) 83 29 34 4:2:0 260
00042( P | P ) 85 30 34 4:2:0 241
00046( P | P ) 93 31 35 4:2:0 240
00043( b | b ) 87 32 36 4:2:0 230
00044( b | b ) 89 32 37 4:2:0 231
00045( b | b ) 91 32 35 4:2:0 230
00047( P | P ) 95 32 30 4:2:0 250
00051( P | P ) 103 33 31 4:2:0 271
00048( b | b ) 97 34 36 4:2:0 230
00049( b | b ) 99 34 34 4:2:0 250
00050( b | b ) 101 34 35 4:2:0 221
00000(IDR| P ) 1 0 30 4:2:0 320
00001( P | P ) 3 1 32 4:2:0 231
00002( P | P ) 5 2 32 4:2:0 220
00003( P | P ) 7 3 32 4:2:0 230
00007( P | P ) 15 4 33 4:2:0 241
00004( b | b ) 9 5 37 4:2:0 300
00005( b | b ) 11 5 35 4:2:0 270
00006( b | b ) 13 5 34 4:2:0 251
00008( P | P ) 17 5 31 4:2:0 280
00012( P | P ) 25 6 25 4:2:0 260
00009( b | b ) 19 7 29 4:2:0 281
00010( b | b ) 21 7 28 4:2:0 230

The reference decoder produces 4940 frames from this bitstream. 4940 / 25 = 197.6 seconds, or 3 minutes 17.6 seconds.

Ron

sorry for not understanding. so what does it means? libavcodec is not supporting this video or it something to do with DGAVCIndex? or maybe i need to do some workaround with Avisynth script? :confused:

[SeeMoreDigital]

sorry for not understanding. so what does it means? libavcodec is not supporting this video or it something to do with DGAVCIndex? or maybe i need to do some workaround with Avisynth script? :confused:Your sample is certainly a bit odd...

For instance. I'm able to play the .TS sample in MediaPlayer Classic (using FFdshow's AVC decoder filter) without any issues - apart from being able to see the interlaced fields.

However, if I de-mux the AVC video stream and re-mux it into the .MP4 container, the file wont play at all.


Cheers

[foxyshadis]

Isn't that because mp4box doesn't support field/frame repeats, or does it now?

[drmpeg]

sorry for not understanding. so what does it means? libavcodec is not supporting this video or it something to do with DGAVCIndex? or maybe i need to do some workaround with Avisynth script? :confused:
Sorry to be vague. I'm not sure exactly where the problem is, but whatever tool you use with this stream must be aware that some coded pictures are fields and some coded pictures are frames.

The number of coded pictures in the bitstream is 6278. If a tool thinks those are all frames, it will arrive at the incorrect length of approximately 04:10 that you have been reporting.

6278 / 25 = 251.12 = 4 minutes 11.12 seconds.

Ron

[Guest]

DGAVCDec needs to divide the field picture count by two. I thought I did that but there must be a bug. You'll have to wait until I get around to it. As the documentation says, PAFF is not yet supported.

[canTsTop]

thank you neuron2 and others for help, will be waiting for full PAFF suport

[Guest]

thank you neuron2 and others for help, will be waiting for full PAFF suport
You're welcome.

I have made the fix for your stream (and others like it) and it now comes out right at 3:17 and 4940 frames for the video. I'll put out a new beta later today for you. There are a few other things I am tinkering with. :)

EDIT: See below.

[Guest]

* Properly counts each pair of field coded pictures as one frame. Should improve PAFF support.

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

[PhillipWyllie]

Thank neuron2 for this excellent tool. I have a problem though, when I open up the an avs file(using avcsource) in VDub, VDubMod or CCE and try to look at the info (file ->file information in VDubMod for example) it crashes. In CCE when I hit the "chapters" button(a preview window usually pops up) CCE crashes.

When I try using alpha6 this doesn't happen, I also tried using libavcodec.dll from earlier releases of DGAVCDec to no avail.

I'm using alpha11.

[Guest]

Does it happen for all source files?

[PhillipWyllie]

Sorry, I don't know what you mean by all source files.

[check]

source file = the input .264 file.

[g0blez]

I ran into this same thing when I transcoded my HD-DVD of Transformers. I was concerned, but I just added AssumeFPS(23.976) to my AVI Synth script, and everything came out fine. I used Alpha 6 (that was the latest when I did this) so there was no Force Film option available then.

How did you manage that? Each time I open my demuxed stream (transformers) with alpha 6, it crashes.

[Guest]

How did you manage that? Each time I open my demuxed stream (transformers) with alpha 6, it crashes. Why do you want to use alpha 6. Use the latest alpha and select Force Film.

[g0blez]

Why do you want to use alpha 6. Use the latest alpha and select Force Film.

Because I get NALU errors with the latest alpha with or without force film.
I would send a sample if i knew which tool to use to cut an h.264 mpv from coded frame 166132 or from 6,929s.
But apparently Turtleggjp was able to transcode successfully with alpha 6.

[Guest]

Use DGSplit from my website to make five 5GB pieces. Then find which one gives the NALU error. Throw away the others. Then split the remaining one and find which one gives the NALU error. Continue until you have a 50MByte file containing the NALU error. Then upload it for me.

I could process my Transformers HD-DVD and see if I run into the same issue, *IF* I had the key. Do you have it? If not, how did you get the raw stream?

@turtleggjp

Have you tried your Transformers decode with the latest alpha?

[desta]

How did you manage that? Each time I open my demuxed stream (transformers) with alpha 6, it crashes.
Did you update your libavcodec?

[g0blez]

Did you update your libavcodec?

Using alpha 11's bundled lbavcodec with alpha 6 seems to get rid fo the crashes. I'll see if I get any error messages with alpha 6 (assuming they were implemented at that time).

[desta]

Out of curiosity, when you open the transformers raw stream in DGAVCIndex, do you get any corrupted frames in the end credits? Scroll to about 2 hrs, 22 mins, 52 secs, and then let it play.

[g0blez]

Out of curiosity, when you open the transformers raw stream in DGAVCIndex, do you get any corrupted frames in the end credits? Scroll to about 2 hrs, 22 mins, 52 secs, and then let it play.

With alpha 6 or alpha 11?
I can check tonight.

[Guest]

I have downloaded AnyDVD and I can now get the H.264 stream from my copy of Transformers. So I will try to duplicate your error.

[canTsTop]

thank you neuron2 for DGAVCDec 1.0.0 Alpha 11

its working good, except it sometimes crashes. i don't know if it DGAVCDec problem, probably its libavcodec.dll or my PC.
DGAVCDec index file without problem, crashes always happens then i try to analyze video (sample i uploaded previously http://rapidshare.com/files/71446036/raw.h264.html) for interlace detection with megui, or this tool http://forum.doom9.org/showthread.php?t=104760 this is my avs:
loadplugin("C:\dgavcdec100a11\DGAVCDecode.dll")
AVCSource("raw.dga")

also it crashed then i encoding with virtualdub (not the same sample) after ~76% was completed, this is avs:
loadplugin("C:\dgavcdec100a11\DGAVCDecode.dll")
AVCSource("bits0001.dga")
Trim(1153, 72423)
Trim(0, 3005) ++ Trim(15038, 71270)
Trim(0, 35708) ++ Trim(48150, 59238)
Trim(0, 46402)
Load_Stdcall_Plugin("C:\Program Files\megui\tools\yadif\yadif.dll")
Yadif(order=1)
Crop(16, 4, -14, -4)
LanczosResize(512,384)
Undot()

this is error report from virtualdub (if it useful):
VirtualDub crash report -- build 28769 (release)
--------------------------------------

Disassembly:
004c01a0: c20800 ret 0008
004c01a3: cc int 3
004c01a4: cc int 3
004c01a5: cc int 3
004c01a6: cc int 3
004c01a7: cc int 3
004c01a8: cc int 3
004c01a9: cc int 3
004c01aa: cc int 3
004c01ab: cc int 3
004c01ac: cc int 3
004c01ad: cc int 3
004c01ae: cc int 3
004c01af: cc int 3
004c01b0: 53 push ebx
004c01b1: 55 push ebp
004c01b2: 56 push esi
004c01b3: 8bf1 mov esi, ecx
004c01b5: 8b8624050000 mov eax, [esi+524]
004c01bb: 83e0fe and eax, 0feh
004c01be: 83f802 cmp eax, 02h
004c01c1: 57 push edi
004c01c2: 7524 jnz 004c01e8 (VideoSourceAVI::_isKey+38)
004c01c4: 8b5e10 mov ebx, [esi+10h]
004c01c7: 8b4c2414 mov ecx, [esp+14h]
004c01cb: 8b6e14 mov ebp, [esi+14h]
004c01ce: 8b542418 mov edx, [esp+18h]
004c01d2: 6a00 push 00h
004c01d4: 2bcb sub ecx, ebx
004c01d6: 50 push eax
004c01d7: 1bd5 sbb edx, ebp
004c01d9: 52 push edx
004c01da: 51 push ecx
004c01db: e880ee0a00 call 0056f060 (_alldiv)
004c01e0: 8bfa mov edi, edx
004c01e2: 03c3 add eax, ebx
004c01e4: 13fd adc edi, ebp
004c01e6: eb08 jmp 004c01f0 (VideoSourceAVI::_isKey+40)
004c01e8: 8b7c2418 mov edi, [esp+18h]
004c01ec: 8b442414 mov eax, [esp+14h]
004c01f0: 8bae1c050000 mov ebp, [esi+51c]
004c01f6: 85ed test ebp, ebp
004c01f8: 7432 jz 004c022c (VideoSourceAVI::_isKey+7c)
004c01fa: 8b4e10 mov ecx, [esi+10h]
004c01fd: 8b5614 mov edx, [esi+14h]
004c0200: 2bc1 sub eax, ecx
004c0202: 1bfa sbb edi, edx
004c0204: 8bc8 mov ecx, eax
004c0206: 83e11f and ecx, 1fh
004c0209: bb01000000 mov ebx, 00000001
004c020e: d3e3 shl ebx, cl
004c0210: 8bd7 mov edx, edi
004c0212: b105 mov cl, 05h
004c0214: e8a7ea0a00 call 0056ecc0 (_allshr)
004c0219: 235c8500 and ebx, [ebp+eax*4+00h]
004c021d: 5f pop edi
004c021e: f7db neg ebx
004c0220: 1bdb sbb ebx, ebx
004c0222: 5e pop esi
004c0223: f7db neg ebx
004c0225: 5d pop ebp
004c0226: 8ac3 mov al, bl
004c0228: 5b pop ebx
004c0229: c20800 ret 0008
004c022c: 8b8ed0040000 mov ecx, [esi+4d0]
004c0232: 8b11 mov edx, [ecx]
004c0234: 57 push edi
004c0235: 50 push eax
004c0236: 8b4210 mov eax, [edx+10h] <-- FAULT
004c0239: ffd0 call eax
004c023b: 5f pop edi
004c023c: 5e pop esi
004c023d: 5d pop ebp
004c023e: 5b pop ebx
004c023f: c20800 ret 0008
004c0242: cc int 3
004c0243: cc int 3
004c0244: cc int 3
004c0245: cc int 3
004c0246: cc int 3
004c0247: cc int 3
004c0248: cc int 3
004c0249: cc int 3
004c024a: cc int 3
004c024b: cc int 3
004c024c: cc int 3
004c024d: cc int 3
004c024e: cc int 3
004c024f: cc int 3
004c0250: 53 push ebx
004c0251: 56 push esi
004c0252: 8bf1 mov esi, ecx
004c0254: 83bebc04000000 cmp dword ptr [esi+4bc], 00h
004c025b: 57 push edi
004c025c: 7457 jz 004c02b5 (VideoSourceAVI::nearestKey+65)
004c025e: 8b5c2414 mov ebx, [esp+14h]
004c0262: 3b5eb4 cmp ebx, [esi-4ch]
004c0265: 7c43 jl 004c02aa (VideoSourceAVI::nearestKey+5a)
004c0267: 8b7c2410 mov edi, [esp+10h]
004c026b: 7f05 jg 004c0272 (VideoSourceAVI::nearestKey+22)
004c026d: 3b7eb0 cmp edi, [esi-50h]
004c0270: 7238 jc 004c02aa (VideoSourceAVI::nearestKey+5a)
004c0272: 3b5ebc cmp ebx, [esi-44h]
004c0275: 7f33 jg 004c02aa (VideoSourceAVI::nearestKey+5a)
004c0277: 7c05 jl 004c027e (VideoSourceAVI::nearestKey+2e)
004c0279: 3b7eb8 cmp edi, [esi-48h]
004c027c: 732c jnc 004c02aa (VideoSourceAVI::nearestKey+5a)
004c027e: 8b46a0 mov eax, [esi-60h]
004c0281: 8b5060 mov edx, [eax+60h]
004c0284: 8d4ea0 lea ecx, [esi-60h]
004c0287: 53 push ebx
004c0288: 57 push edi
004c0289: ffd2 call edx
004c028b: 84c0 test al, al
004c028d: 740a jz 004c0299 (VideoSourceAVI::nearestKey+49)
004c028f: 8bc7 mov eax, edi
004c0291: 5f pop edi
004c0292: 5e pop esi
004c0293: 8bd3 mov edx, ebx
004c0295: 5b pop ebx
004c0296: c20800 ret 0008
004c0299: 8b06 mov eax, [esi]
004c029b: 8b5060 mov edx, [eax+60h]
004c029e: 53 push ebx
004c029f: 57 push edi

Built on KOS-MOS on Mon Nov 19 23:14:32 2007 using compiler version 1400

EAX = 00008b94
EBX = 00c476e0
ECX = 00bd8618
EDX = 00000000
EBP = 00000000
ESI = 00c47008
EDI = 00000000
ESP = 0623fc3c
EIP = 004c0236
EFLAGS = 00010246
FPUCW = ffff027f
FPUTW = ffffffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'...

...reading address 00000010...

...while running thread "Processing" (thread.cpp:152).

Pointer dumps:

EBX 00c476e0: 005a5084 005a5088 000003c0 00000a0c 005a5080 0012f464 00c479a8 3f800000
ECX 00bd8618: 00000000 0033b574 00bd8290 037b8eb0 00bddf80 00bd8580 00040004 010801cc
ESI 00c47008: 005b3920 00000002 00bd8658 00000028 00000000 00000000 0000b543 00000000
ESP 0623fc38: 00245688 00008b94 00000000 00008b94 005b3920 0623fcc4 00c476e0 004bfbce
0623fc58: 00008b94 00000000 00c47068 004c185c 00008b94 00000000 00c478a8 00c478b4
0623fc78: 00c476e0 05d10020 00000000 00000000 00000000 00c2afd8 00bdd780 00000008
0623fc98: 0623fcbc 004f7c75 05e87c94 0623fcec 00000008 00c2a940 00cc3f98 0623fc70

Thread call stack:
004c0236: VideoSourceAVI::_isKey()
004bfbce: VideoSource::isKey()
004c185c: VideoSourceAVI::streamGetFrame()
004f7c75: VDFileAsyncNT::FastWrite()
004a0362: AVIOutputFileStream::partialWrite()
004665bf: VDDubProcessThread::WriteVideoFrame()
7c917e3f: ntdll!RtlCompareUnicodeString [7c900000+17988+4b7]
7c917de9: ntdll!RtlCompareUnicodeString [7c900000+17988+461]
004a2eae: AVIOutputFile::init()
00577010: _ceil_default()
00469164: VDStreamInterleaver::PushStreams()
00467111: VDDubProcessThread::ThreadRun()
7c812adb: kernel32!RaiseException [7c800000+12a89+52]
7c80def3: kernel32!DuplicateHandle [7c800000+de7e+75]
004f0154: VDSetThreadDebugName()
7c80def3: kernel32!DuplicateHandle [7c800000+de7e+75]
0045cc20: VDThreadInitHandler()
004f02db: VDThread::StaticThreadStart()
00573da8: _callthreadstartex()
00573e4d: _threadstartex@4()
7c80b703: kernel32!GetModuleFileNameA [7c800000+b54f+1b4]

-- End of report

[Guest]

I can't help you with crashes in MeGUI or any other app with your first stream. Talk to the authors.

Regarding your second stream (and any streams), strip your script down to just avcsource(). Does it still fail when played in VirtualDub? If so, I will look at it if you give me the stream. If not, look to the other filters for the problem.

[canTsTop]

also it crashed then i encoding with virtualdub (not the same sample) after ~76% was completed, this is avs:
loadplugin("C:\dgavcdec100a11\DGAVCDecode.dll")
AVCSource("bits0001.dga")
Trim(1153, 72423)
Trim(0, 3005) ++ Trim(15038, 71270)
Trim(0, 35708) ++ Trim(48150, 59238)
Trim(0, 46402)
Load_Stdcall_Plugin("C:\Program Files\megui\tools\yadif\yadif.dll")
Yadif(order=1)
Crop(16, 4, -14, -4)
LanczosResize(512,384)
Undot()

strange, i encoded this video one more time with same settings and it crashed again at ~76%, then i encoded third time but changed xvid settings to 1pass and it finished without errors.

i searched this forum and found this http://forum.doom9.org/showthread.php?p=1067116#post1067116 about virtualdub disappearing then moving forth and back, some times i get this to

and then playing my TS video in mplayer i get this error:
Interlaced pictures + spatial direct mode is not implemented
its probably something to do with crashes, but then its libavcodec fault

[Guest]

If you want my help, you're going to have to read what I say and answer my specific questions. If you don't I will start ignoring you.

[Guest]

Out of curiosity, when you open the transformers raw stream in DGAVCIndex, do you get any corrupted frames in the end credits? Scroll to about 2 hrs, 22 mins, 52 secs, and then let it play. Yes, I saw it. I'll investigate.

[g0blez]

I have downloaded AnyDVD and I can now get the H.264 stream from my copy of Transformers. So I will try to duplicate your error.

Thanks neuron2. An error should pop-up at coded frame 166132 when saving the dga.