DGAVCDec 1.0.9

[Guest]

Alpha 8 package is now updated.

[Koti]

http://ffdshow-tryout.svn.sourceforg.../?pathrev=1523

Track1.264

yw

[check]

I'd like to see a 'frame type' (ie, I, P, B) box in the info window. I'd like it partly for plain interest, and partly to know possible cut points.

[foxyshadis]

http://sourceforge.net/project/showf...roup_id=173941 is where the actual builds are published, in case you want to test them for compatibility.

[raziel666]

I have a VFR MP4. I try to extract the raw AVC stream with Yamb and then use DGAVCindex to play with it, but what I get is a 29.97 fps video. In the bottom I see that the fps has a value of 60000 / 2002 (=29.97fps), but the video originally is 23.976fps except for a part that is 60fps. Am I doing something wrong? Or maybe there is some kind of evil problem with DGAVCindex handling VFR AVC streams?

[LigH]

Originally Posted by neuron2

Is the wedding clip PAFF? If so, can you point me to it? Thank you.

http://forum.doom9.org/showthread.ph...42#post1053242

Comes from a SONY AVCHD camera. May contain some PAFF (DGAVCIndex 1.00a6 complained it).

I indexed and converted a longer video (~ 20 min, with interlaced/progressive changes due to changing lightness) without problems, too.

VirtualDub crashed (simply disappeared) when dragging the position slider around on a loaded AviSynth script. But this is not really the recommended treatment anyway.

[Guest]

Originally Posted by raziel666

I have a VFR MP4. I try to extract the raw AVC stream with Yamb and then use DGAVCindex to play with it, but what I get is a 29.97 fps video. In the bottom I see that the fps has a value of 60000 / 2002 (=29.97fps), but the video originally is 23.976fps except for a part that is 60fps. Am I doing something wrong? Or maybe there is some kind of evil problem with DGAVCindex handling VFR AVC streams?

You didn't give me the stream so I can only guess...

Probably it has 23.976 parts pulled-down to 29.97 mixed with 29.97 parts. To handle that, DGAVCDec could honor the pulldown flags and then you can decide in your Avisynth script how to deal with that (just as for DGMPGDec), or DGMPGDec could apply Force Film. But I haven't yet implemented the Honor Pulldown Flags or Force Film functionality, so you'll have to be patient.

It's not so easy, because when decoding, libavcodec.dll is doing the work and it doesn't honor pulldown either, so I have to do it after decoding the frame. But I don't have access to the picture timing SEI, because libavcodec.dll decoded the frame and all I get back is the decoded frame data. So I either have to make a special build of libavcodec.dll that passes back data I need (which I prefer not to do so that users can switch out different libavcodec.dll versions as they come along), or I have to parse the NALUs as they flow by on the way into libavcodec.dll. I can do the latter but some redesign will be needed. I'm working on it.

[raziel666]

Thanks for your quick answer neuron2. The stream is some 800mb so I don't know how I can give it to you.

But according to the timecodes I get if I mux into mkv, there are 60fps parts and 23.976 parts. It's an anime episode and the part in 60fps is the ED.

P.S. What I noticed some minutes ago, is that i get some 886 frames less than I should have got. I don't know if this is related with your explanation though...

[Guest]

Originally Posted by raziel666

But according to the timecodes I get if I mux into mkv, there are 60fps parts and 23.976 parts. It's an anime episode and the part in 60fps is the ED.

This sounds like a big rule 6 violation. You better knock it off if you want to stay on this board.

[SeeMoreDigital]

Originally Posted by neuron2

This sounds like a big rule 6 violation. You better knock it off if you want to stay on this board.

Given .MKV appears to be the container of choice for pirated high-def downloads, I reckon we're going to get a lot more questions from people wanting to know how to gain access to the elementary streams. Not to mention re-muxing the elementary streams to other containers!

[LigH]

Are there any ... well, kind of statistics, which kind of generator / encoder / producer prefers which kind of "interlaced vs. progressive" encoding? I have a suspicion that e.g. hardware encoders (like in AVCHD cameras) may prefer the more generic and faster solutions (e.g. switch to low-res progressive on low brightness), and that different HDTV broadcasters may use different encoders and settings.

Furthermore, I wonder why PAFF was harder to implement than MBAFF, although to me it sounds like PAFF defines the "interlaced" behaviour of all macroblocks in the whole frame, in contrast to MBAFF which defines it per macroblock -- or did I misunderstand them?

[bob0r]

Encoding anime to .mkv is highly illegal, they have banned it in The Netherlands.

[J_Darnley]

What? Can you point to any article which reports this? From what I know encoding any source to any other format is just as illegal anywhere in Europe. Why should anime be different from any other source? I'm glad I don't live a bit further north then.

Or have I just been trolled?

[tjmitchem]

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.

When I opened the file, dgavcindex hung for about 10 minutes, then came back and gave me the paff warning. I cheerfully told it to go ahead and blow up in my face

At this point, it's been unresponsive for about 2 hours. Interestingly enough, it has generated a 99k .dga file, so it definitely processed some of the stream.

If anyone wants to test this, the first 15MB of the stream are at:
http://mostlyharmless.dyndns.org/264/sample.264

The DGA file is at:
http://mostlyharmless.dyndns.org/264/test.dga

Terry

[Guest]

This version adds the Info dialog functionality.

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

One tip: To see the frame types, set the playback speed to Single Step before starting your preview. Otherwise that field is just a blur.

The changes were extensive as I had to implement the parallel parsing I described in my earlier post. So pound on it with relish.

[Guest]

Originally Posted by tjmitchem

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.

Looking at it in a hex editor, it doesn't look like a clean raw stream. And I can't play it in any of my players, nor is it accepted by my muxers. Maybe it's encrypted?

[Guest]

OK, have at it.

[drmpeg]

Originally Posted by neuron2

Looking at it in a hex editor, it doesn't look like a clean raw stream. And I can't play it in any of my players, nor is it accepted by my muxers. Maybe it's encrypted?

It's a Transport Stream. Didn't the 0x47 at the beginning tip you off?

Ron

[LigH]

Great, "Info dialog" was a missed little gem!

Due to the possible complexity of AVC, it may be useful to see a few more AVC specific details here, like the referencing amount. If you like...

[SeeMoreDigital]

Originally Posted by tjmitchem

If anyone wants to test this, the first 15MB of the stream are at:
http://mostlyharmless.dyndns.org/264/sample.264

The DGA file is at:
http://mostlyharmless.dyndns.org/264/test.dga

Terry

In order to get at the elementary .h264 stream I used MP4box. And MP4box again to mux the elementary stream into the .MP4 container.

Anyway, here's what AVInaptic (18-11-2007) had to say about it: -

 
[ About file ]

Name: sample.264_pid17.mp4
Date: 20/11/2007 09:18:57
Size: 5,591,649 bytes (5.333 MB)

[ Generic infos ]

Play duration: 00:00:16 (15.76 s)
Container type: MP4/MOV
Major brand: ISO Base Media version 1
Compatible brands: JVT AVC
Creation time: 19/11/2007 09:18:57 UTC
Modification time: 19/11/2007 09:18:57 UTC
Number of streams: 1
Type of stream nr. 1: video (avc1) {GPAC ISO Video Handler}
Audio streams: 0

[ Relevant data ]

Resolution: 1440 x 1080
Width: multiple of 32
Height: multiple of 8

[ Video track ]

Codec: avc1
Resolution: 1440 x 1080
Frame aspect ratio: 4:3 = 1.333333
Pixel aspect ratio: 4:3 = 1.333333
Display aspect ratio: 16:9 = 1.777777
Framerate: 25 fps
Number of frames: 394
Bitrate: 2834.996446 kbps

[ About H.264 encoding ]

SPS id: 0
  Profile: Main@L4
  Num ref frames: 4
  Aspect ratio: Custom pixel shape (4:3 = 1.333333)
  Chroma format idc: YUV 4:0:0
PPS id: 0 (SPS: 0)
  Entropy coding type: CABAC
  Weighted prediction: No
  Weighted bipred idc: No
  8x8dct: No
PPS id: 4 (SPS: 0)
  Entropy coding type: CABAC
  Weighted prediction: P slices - explicit weighted prediction
  Weighted bipred idc: #undef#
  8x8dct: Yes
  Custom inter4X4 chromau: 
      8   8 244 244
    254 246 243 241
    254 243 242 241
    242 242 241 241
  Custom inter4x4 chromav: 
      9   9  11  12  12  11  12  12
     12  13  12   9  12  12   9   9
     50  54  52  95  41   0   0   0
      0   0   0   0 100 101  45 117
    110 100 101 114 108 105 110 101
     45 102 105 101 108 100  45 118
     97 108 117 101   0 101   0  51
     40   0   0   0  65   0   0   0
  Custom intra8X8 luma: 
      9   9   6   6  15  15  14  13
     12   6  13  16  16  14  22  16
     19  10  16  16  15  22  16  16
     10  11  17  15  22  16  13  15
     10  16  15  12  16  13  14  15
     16  16  15  20  13  13  95  84
     16  15  17  13  13  95  84  84
     18  17  14  14  98  84  84  84
  Custom inter8X8 luma: 
      9  12  17  17 206 207 206 206
     12  18 210 211 207 206 206 237
     18 211 211 208 206 206 236 237
    211 211 208 206 211 236 237   3
    211 209 208 211 236 216 211   3
    209 208 211 236 216 212   3   3
    209 211 227 216 217   3   3   3
    224 224 216 217   3   3   3   3

[ Profile compliancy ]

Resolution: 1440 x 1080 > 720 x 576
Framerate: Ok
Warning: If you need a more complete report, then click on "DRF analysis"

This report was created by AVInaptic (18-11-2007) on 20 nov 2007, h 09:25:32

Cheers