DGAVCDec 1.0.9

[karl_lillevold]

TSRemux 188 byte TS output:
DGAVCIndex gives no errors.

Opening avcsource via Avisynth in VDub:
AVCSource: No GOPs found (no IDRs or recovery points)

TSRemux to 192 byte output still crashes DGAVCIndex.

Will look into the other suggestions when I have time later today (TSmuxer and HDVinfo)

EDIT: It sees 188 byte TS output also results in the same DGAVCIndex warning, and then crash when I press "No".

[Guest]

OK, I have it fixed. It was a bug in my code to detect M2TS on file open, so the code thought it was an elementary stream.

I'll give you a fix when I get home tonight. Also a fix for the demuxed audio being held locked.

[SeeMoreDigital]

Hi Don,

Should this not read 16:9?



Frame size is 4:3. The output is 16:9....


Cheers

[Guest]

No, it is correct. In AVC, that is the stretch ratio. It is telling the decoder to stretch the coded 1440x1080 by 4:3 for display. You turn 4:3 into the fraction 4/3 and multiply the coded width by that to get the display width.

4/3 * 1440 = 1920

[karl_lillevold]

hey, that's me and one of my R/C helis

[Isochroma]

About the aspect ratio, it seems that DGAVCDec should report the AR as 16:9, rather than reporting how much it must be stretched to look right. After all, the value reported is "aspect ratio" not "stretch amount".

[Guest]

Originally Posted by Isochroma

About the aspect ratio, it seems that DGAVCDec should report the AR as 16:9, rather than reporting how much it must be stretched to look right. After all, the value reported is "aspect ratio" not "stretch amount".

I prefer to follow the terminology of the AVC specification. After all, that Info field is reporting the value of the aspect ratio syntax element, and it is specified (correctly) as 4:3.

Don't you chaps read specs?

I'll clarify the users manual a bit more. After all, saying there that it is the stretch factor is apparently not enough.

[Isochroma]

It probably isn't enough, considering that the text in the UI next to the value says "Aspect Ratio", not "Stretch Amount". People make mistakes, especially when they are misled.

[Guest]

* Fixed a problem that caused some M2TS files to be detected as elementary streams.

* Fixed a problem that caused demuxed audio files to be held locked by DGAVCIndex.

* MPEG audio is now demuxed with file extension .mp1, mp2, or mp3, depending on the layer detected (previously .mpa was always used).

http://neuron2.net/dgavcdec/dgavcdec.html

On some streams, libavcodec.dll reports an unknown NAL unit type. If you dismiss the warnings things seem to go OK. I've verified that no such NALU is being passed from my code and I'm investigating the reason for this warning. For now, just dismiss these messages.

[hajj_3]

nice progress

[Atak_Snajpera]

Neuron I've discovered something weird. If I open this file http://www.sendspace.com/file/rjohqw via command line with -h switch DGAVCIndex crashes but if I remove -h everything is fine.

[Guest]

Originally Posted by Atak_Snajpera

Neuron I've discovered something weird.

Yes, it is indeed weird. Here's what happened. You cut the stream and truncated an SEI message at the end of the file. The SEI parser code that I took from the JM reference software happily keeps parsing past the end of the available data and runs into whatever is on the stack. On the stack after the SEI message buffer is the command line string. So when the -h is not there the parser fortuitously terminates and returns. When the -h is there, it carries on and blows past the size of the SEI message buffer and crashes.

I put a check in to prevent this. I didn't want to make a new release so I updated the alpha 18 package. Please re-download it and test it.

But worse, this points up a deficiency of the AVC specification. The spec says that the end of a NALU is determined by when the following NALU starts, or when EOF is encountered. That means the spec gives no way to avoid passing back a truncated NALU at the end of the file (because there's no way to know the NALU isn't complete when we hit EOF). It's up to the application to not crash! So I'll probably have to implement a try/except block because finding and testing all possible crash locations is not ideal. For now, I've just patched the SEI parser, as this is the only known crashing case on premature EOF to date.

Thank you for finding this weird issue.

[Guest]

Originally Posted by Isochroma

It probably isn't enough, considering that the text in the UI next to the value says "Aspect Ratio", not "Stretch Amount". People make mistakes, especially when they are misled.

As I explained, the name of the field in the AVC specification is "sample aspect ratio" (section E.2.1 and Table E.1). You have an attitude problem if you think that by following the specification I am misleading people.

[Isochroma]

The unqualified term "aspect ratio", generally refers to "Frame Aspect Ratio". It has been since the first days of photography and beyond into film, the width of the frame, divided by its height. It is the final presentation geometry, after whatever the industry has defined as corrective measures.

What the AVC specification calls "sample aspect ratio" or as it is also known, "pixel aspect ratio" aka. "PAR" (Windows Media Encoder), is usually referred to using those qualified names, in order to differentiate it from the unqualified term.

If you don't believe me, then show me one example of image or video software where the UI refers to the unqualified term "Aspect Ratio" and the value presented is not presentation width divided by height, aside from your own.

If you want to present various values, here's a couple good ways to do it:

Resolution: 1440x1080
Aspect Ratio: 16:9
Pixel Aspect Ratio: 4:3

or

Resolution: 1440x1080
Frame Aspect Ratio: 16:9
Pixel Aspect Ratio: 4:3

[Brother John]

Imo Isochroma has a valid point. “Aspect Ratio” is ambivalent. We’ve been living with DVD’s DAR 4:3 for years and now there’s PAR 4:3 for HD material. That’s a prime source of confusion. Even SMD got trapped, and he’s anything but a newbie.

Why not change the name to “Pixel AR” or “Sample AR”? AR is a very well known acronym. Such a labelling would be precise, would fit into the current dialog width and prevent confusion at least among the more experienced users.

[SeeMoreDigital]

How about something like this: -

[G_M_C]

Originally Posted by SeeMoreDigital

How about something like this: -

Actually,

That not bad ... good compromise

[Isochroma]

There's many ways to provide the frame/pixel information to the user unambiguously, as the suggestions indicate. A garden of variety from the creativity of society.

[Guest]

Here's what I did.



...and here is the help text:

Frame Size - Displays the encoded size of the frame in the currently displayed video. Note that this is the encoded frame size, which differs from the display frame size (see below).

SAR - Displays the sample aspect ratio specified in the AVC stream.

Display Size - Displays the display frame size that results from applying the SAR to the encoded frame size. Here's how it works: Suppose you have a 1440x1080 video with a reported SAR of 4:3. You convert 4:3 to the fraction 4/3 and multiply that by 1440, giving a display width of 1920. Thus, the SAR field will show 4:3 and the Display Size field will show 1920x1080 as the display size.

@SeeMoreDigital

Where'd you get the source code for my dialog box?

[Snowknight26]

Its easy to change it neuron2... either with photoshop or a resource hacker.