DGAVCDec 1.0.9

[lucassp]

Neuron'll lynch you for not demuxing it...

I demuxed it using MPlayer (read a few posts back ;) ). the link is from the source TS file.

[Guest]

I demuxed it using MPlayer (read a few posts back ;) ). the link is from the source TS file. May I please have the ES? I don't have all these obscure demuxers installed. Thank you.

It's perverse to me that you have demuxed the ES for testing and then instead of giving it to me, you give me the container file!

[lucassp]

May I please have the ES? I don't have all these obscure demuxers installed. Thank you.

It's perverse to me that you have demuxed the ES for testing and then instead of giving it to me, you give me the container file!

sorry...here it is. hope you're not too mad at me :D

http://rapidshare.com/files/19752559/sky.264

[Guest]

Here you go. The IDR line contains the location in the file of the IDR frame. Everything is fine until it reaches 2GB and turns negative:

IDR -2147217683
FRM 0
FRM 3
FRM 2
FRM 1
FRM 6
...

Then the seek fails and just goes to the start of the file. :p

I thought I had __int64 everywhere important but obviously not. I think it is the fprintf().

I'll fix it. Thanks for pointing it out. That's why it's called an alpha. :)

[Revgen]

The IDR line contains the location in the file of the IDR frame. Everything is fine until it reaches 2GB and turns negative:

IDR -2147217683
FRM 0
FRM 3
FRM 2
FRM 1
FRM 6
...

Then the seek fails and just goes to the start of the file. :p

I thought I had __int64 everywhere important but obviously not. I think it is the fprintf().

I'll fix it. Thanks for pointing it out. That's why it's called an alpha. :)

Glad I could help.:)

[Guest]

here it is I fixed the crash and it now plays properly. It will be in the next alpha release.

EDIT: It was actually a crash in libavformat, strangely enough.

[lucassp]

I fixed the crash and it now plays properly. It will be in the next alpha release.

u the man :D :thanks:

[Eragon4ever]

Looks good.:thanks:

However:
1. Load a file in DGAVCIndex.exe (e.g. your test.264).
2. Hit 'Index'.
3. Hit 'Index' again while it is still working.
-> DGAVCIndex crashes.

[Seba-]

I have a problem when I am trying to make dga from .264 file which size is like 9GB (ERROR: Undefined level).
When the file is smaller everything is fine...

[tomos]

strange. worked fine for me with a 264 file 14.4 GB in size

seeking is strange and it tends to crap out and give me a green screen if i jump to a frame too far into the vid. just re-encoding etc though works fine with it

[Guest]

3. Hit 'Index' again while it is still working.
-> DGAVCIndex crashes. Fixed for alpha 3. Thank you.

@Seba-

Does it happen with a smaller fragment of the file? If so, please post a link to it.

@tomos

The raison d'etre of DGAVCDec is seeking, so alpha 2 doesn't work fine. But as I said, it is fixed in alpha 3, which will be out soon.

[fenomeno83]

I didn't understand...Can I use this decoder to decode an h264 movie for example with kmplayer,setting dgavcindex as h264 external decoder?and in realtime sat stream as luxehd with dvbviewer?

[Eragon4ever]

An other odd thing:
1. Index a file (again, you may use your test.264).
2. Index the file agian (or an other one) but DO NOT close DGAVCIndex.
-> The output of the first run is fine however the second one seams not to finish. For test.264 the broken output ends at line 502 of the fine one (551 lines).

It seems to break when the path length is >256chars :)

Hm. For me it breaks with paths >99 chars.

[Guest]

I didn't understand...Can I use this decoder to decode an h264 movie for example with kmplayer,setting dgavcindex as h264 external decoder? and in realtime sat stream as luxehd with dvbviewer? DGAVCDec is an Avisynth source filter. It is not a DirectShow filter.

[bob0r]

@neuron2

So you want all http://x264.nl/h.264.samples/ demuxed into .264, then you will test them?

[Guest]

So you want all http://x264.nl/h.264.samples/ demuxed into .264, then you will test them? For you, bob0r, I will be happy to demux them and test them. I have Manzanita Muxer, which has a demuxing tool. I tried it on the first sample and everything worked fine.

[Inventive Software]

@Neuron: What does H.264 need to seek accurately? Currently, you use IDR frames, which is fair enough. Any chance of increasing this so reference frames are used too? (This assuming reference frames apply to I, P and B frames.)

[Guest]

What does H.264 need to seek accurately? Currently, you use IDR frames, which is fair enough. Any chance of increasing this so reference frames are used too? (This assuming reference frames apply to I, P and B frames.) There are three possibilities for starting valid decoding in a bitstream:

1. IDR
2. Recovery point SEI
3. All-I-slice frame (not IDR, slice_type=7)

I support 1 and 2 now. I have not yet seen an instance of 3 in the wild. I will support 3 if and when needed.

I don't understand your point about reference frames. A frame can be a reference frame without being a valid starting point for decoding.

Note that we distinguish between being a valid starting point for decoding and being seekable. Any frame is seekable but it may not be a valid starting point for decoding. Don't forget that you can seek to any frame by backing off to the previous frame of types 1, 2, or 3 as above and then decoding from there, finally outputting the picture you want. That is what both DGMPGDec and DGAVCDec do.

EDIT: Possibility 3 is not a valid starting point. See the discussion lower in this thread.

[Inventive Software]

Right, i misunderstood the reference frames thing.

[Guest]

I have a problem when I am trying to make dga from .264 file which size is like 9GB (ERROR: Undefined level). OK, I have fixed this. It will be in alpha 3.

[Guest]

This version:

* Fixes bugs (as described in the above posts).
* Adds a checkbox to enable info/warnings encountered when parsing your stream.
* Adds the ability to decode the stream with the JVT reference decoder and display that with an Avisynth script.
* Adds the ability to disable AVC deblocking.
* Removes the sample streams from the distribution.
* FRM line in DGA file now contains frame type field (P=0, B=1, I=2).

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

You need to update all your DLLs!

I forgot to bump the DGA file version, so remake existing DGA files.

[Revgen]

Thanks.:)

The seeking works fine in the vid now. Deblocking works too.

[Guest]

Oops, had to withdraw Alpha 3 temporarily. It has a rather large memory leak.

EDIT: I put it back because it appears to not be a problem with the filter but just something strange with one stream that plays and then gets slower and slower and then crashes VirtualDub. I am investigating.

EDIT2: Stupid PAFF again! I'll add an error popup to the next alpha.

[Guest]

@bob0r

Here are the test results for the streams you linked:

anixe.hd.264 -- fails (PAFF)
arte.hd.ts -- fails (PAFF)
astra.hd.ts -- ok
bbc.hd.ts -- ok
euro1080.hd5.ts -- ok
hd.forum.tf1.hd.ts -- ok, but with minor artifacts (file corruption?)
lux.hd.ateme.ts -- ok
lux.hd.ts -- ok
premiere.hd.ts -- ok
prosieben.hd.ts -- ok
sky.movies.9.hd.ts -- ok

I'm considering having a go at adding PAFF support to libavcodec.

[Guest]

I updated the Alpha 3 release with a check for PAFF. So re-download it if you want that.

I'm still looking for streams with soft pulldown or frame repeats, so let me know if you think you have one.

[orbitlee]

I updated the Alpha 3 release with a check for PAFF. So re-download it if you want that.

I'm still looking for streams with soft pulldown or frame repeats, so let me know if you think you have one.


Here is a sample(some corruption in the middle though)
http://www.sendspace.com/file/t1mee0

Every frame has PIC_TIMING SEI,
pic_struct=4, number_clock_ts=2
pic_struct=5, number_clock_ts=3
pic_struct=6, number_clock_ts=3
pic_struct=3, number_clock_ts=2

I wish that's what you are looking for.

For frame repeats sample, do you mean hard telecine or something else?

[Sergey A. Sablin]

There are three possibilities for starting valid decoding in a bitstream:

1. IDR
2. Recovery point SEI
3. All-I-slice frame (not IDR, slice_type=7)


considering multi-reference encoding point 3 is not possible.

[Guest]

Here is a sample... I wish that's what you are looking for. Yes, that's it. Thank you. If you have any other uncorrupted ones like that, that would be helpful too.

For frame repeats sample, do you mean hard telecine or something else? That would be streams using pic_struct 7 (frame doubling) or 8 (frame tripling).

[Guest]

considering multi-reference encoding point 3 is not possible. I don't understand your point. Can you please try to explain it some more? Thank you.

[Sergey A. Sablin]

I don't understand your point. Can you please try to explain it some more? Thank you.

fe you have next sequence:

IDR P P P P P P P P P I P P P P P ...
^ ^ |
|_|_|
if there are more than 1 effective ref frame (lets take 2) then it is impossible to start decoding from I-frame (which fe consists of only I-slices, i.e. slice_type = 7), cause first P-frame after I-frame might take use of P-frame just before this I-frame (see picture) - so P-frames after I-frame can't be decoded correctly.

BTW, one could create 3:2i (interlaced pulldown) and 3:2p (frame doubling & tripling) videos using Elecard Converter Studio.

[Guest]

Yes, you're right. I was thinking of trick modes, where one could do fast forward/reverse play by displaying just the all-I-slice frames. Thank you for the correction, and for the pointer to Elecard.

[bob0r]

@neuron2

So you are saying only PAFF-interlaced frames cause a problem?

Most of those files are PAFF, but with only progressive frames.

Oh btw, that possible corrupt file, i plays fine and demuxes fine, however its the only different guessed encoder file: scientific atlanta hd.forum.tf1.hd.ts (see h.264.samples.info.txt)

[Seba-]

When trying to index file about 9gb size i have this error in alpha3:

http://img177.imageshack.us/img177/2258/error2ob3.jpg

[bob0r]

I think neuron/haali/mosu really need to sit around a table, and fix support for 1-100gb files once and for all :D

[Guest]

The test for PAFF is done for every slice and looks like this:

if sps->frame_mbs_only_flag=0 and field_pic_flag=1
PAFF encountered

So, yes, if the stream fragment contains no such slices, it can't be considered PAFF and it will decode correctly with DGAVCDec (libavcodec).

[Guest]

I think neuron/haali/mosu really need to sit around a table, and fix support for 1-100gb files once and for all :D I generally fix things pretty quickly when they are brought to my attention, and this filter is just a baby. So I somewhat resent that comment, even with the smilie.

Furthermore, that memory leak is in the JVT code. :) That doesn't mean I won't fix it, of course.

[bob0r]

I should have typed: neuron can you help mkvtoolnix and haali's muxer to work with 1-1000000000gb files? :D

And yup about the PAFF, that makes sense then.


..... maybe ask for coreavc source :devil: ?

* runs

[Guest]

I should have typed: neuron can you help mkvtoolnix and haali's muxer to work with 1-1000000000gb files? Wow, I didn't know that they made hard disks that big. Can you donate one to allow me to duplicate this problem?

[bob0r]

http://x264.nl/slap.gif

[Diodato]

VFAPIConv 1.05 can't load the simplest Avisynth file - states 'invalid'.

Is it a bug?

Just for reference the avs file is:
loadplugin("C:\dgavcdec100a3\DGAVCDecode.dll")
AVCSource("C:\xxx.dga")

BTW, thanx for the nice work.


Edit: No bug, all OK. Forgot that VFAPIConv accepts only RGB colorspace.

[guada2]

@Diodato

Is it a bug?
No.
You must put "VFAPIConv 1.05" at the same place of VDM, as DGAvCindex.

[Hans Ohlo]

I'm considering having a go at adding PAFF support to libavcodec.
other than your great work with this DGAVCDecode, adding PAFF to libavcodec would make _very_ much people fall on their knees for you!

[Guest]

Just an update on progress. I have converted DGAVCIndex into a DGIndex look-alike. It opens the file and previews it, allowing you to navigate around without making a project, just like DGIndex. I will release that when I clear out a few small bugs. That makes the toolset start to be useful.

My big question now is which container format to start with. I'm thinking transport, but mp4 is also possible. Your thoughts?

PAFF will come.

[HookedOnTV]

Got one that I can't get to decode. Using rev 3 of your tool. After reading the thread I'm thinking maybe it is PAFF but I don't know how to determine that. Link to ES in PM.

[Inventive Software]

TS. I think people with H.264 transport capture streams would love you more that way. MP4 would also be nice too.

[Revgen]

MKV would be nice.

TS files are often interlaced as PAFF and MBAFF, so I don't know what good it would do to include it yet.

[ToS_Maverick]

for me it the prioritylist goes like that:
TS > MKV > MP4

TS or MKV would be really nice and it wouldn't make a difference for me, which one is first.

[lucassp]

1. TS (there are lots of progressive streams)
2. EVOB :D
3. MKV
4. MP4

[bob0r]

With container you mean file>open support or file>mux support?

If you go for mkv also, i am sure Haali is willing to write a patch, same as for x264 :D

[Guest]

Got one that I can't get to decode. Using rev 3 of your tool. After reading the thread I'm thinking maybe it is PAFF but I don't know how to determine that. Link to ES in PM. What player are you able to successfully play that stream with? Where/how did you get it?