Support forum for DG Tools

I ran across the following problem with my homebrewed transcoder tools based on DGIndexNV.

In olden days, I used DGIndex and would automatically calculate the sample aspect ratio of the source material from the "Aspect_Ratio=" and "Picture_Size=" lines in the old-format index files. Then my script would feed that value to x264 as a "--sar" option and all would be well.

With DGIndexNV (necessary for modern input codecs), the .dgi files seem to contain only the "Picture_Size=" information (after the SIZ token), but not the "Aspect_Ratio=" information. Fortunately that is usually not a problem because most material with modern codecs have a 1:1 SAR, so I just defaulted to that.

However, I recently switched over to DGIndexNV for all my transcodes, including SD DVD material, and--as you know--almost all DVD material has a non-1:1 SAR (typically, 8:9 for SD TV material, 32:27 for movies). This results in my SD transcodes being noticably stretched or squished.

So, is there some way to extract the original SAR from .dgi files? If not, would it be feasible to add the equivalent of the old "Aspect_Ratio" information as, e.g., a SAR or PAR line?

Hi Carl. Welcome to the forum.

That's an excellent point you raise.

I will add that to the DGI file as you suggest. I'll try to do that later today but certainly within a few days.

Until I get that done, you can enable the info log and then the info is available in the generated log file.

Thanks for the prompt response and forthcoming update!

Before I go ahead with this, is there some reason you can't use the info log?

The DGI file is not really intended as a general information repository; its purpose is to communicate the information needed by the source filter. SIZ is needed to allocate the frame stores. The aspect ratio would not be used by the source filter.

Thanks, now that my code actually parses the log file I see that it contains the info I need as well as a lot of other useful info (like colorimetry) and getting the info from there works for me.

That said, ideally, I'd love to see all the other useful info that DGIndex has, but which can't be derived from the dgi file contents, dumped at the end of the dgi file. It would have a minimal impact on the size compared to all the frame info and, even if DGSource does not need it, a lot of other software interpreting dgi files, such as mine, would be very grateful for it.

Unless you can show a critical need, it's hard to see how I could find time for it considering we need HEVC support and some other stuff. Sometimes people think it's easy to just dash off a few lines of code. I wish.

Forgive me for harping on this point, which certainly has a smaller interested constituency than HEVC support, but I may have spoken too soon when I said that I can always derive the SAR reliably from the .log contents. Having thrown a larger variety of source formats and tried to parse the various .logs, I am not sure that I can always reliably derive the SAR from the variably offered data.

Sometimes, the SAR is right in the log and the problem is trivial. But others have no SAR:

For example, I've seen VC1 streams which contain only this relevant information:
codedsize = 1920x1088; dar = 16x9; displaysize = 1920x1080

Of course, you can easily guess that this is a 1:1 SAR file, but how can I tell reliably from these bits of data? If I interpret displaysize correctly, its ratio should always be the same as the DAR, so I cannot derive the SAR. In principle, one could calculate the SAR from the dar and the codedsize, but codedsize also includes padding, so you would be slightly off.

For MPEG2 files, my small data set contains relevant .log entries of this type:
codedsize = 720x480; displaysize = 720x480; aspectratio = 4:3 [2]
codedsize = 720x480; displaysize = [not specified]; aspectratio = 16:9 [3]
codedsize = 720x480; displaysize = [not specified]; aspectratio = 4:3 [2]

Again, you could guess at the SAR, by using the aspectratio (presumably display, not sample, AR) and the codedsize, but is padding possible with MPEG2s? I cannot say I have ever seen padding on MPEG2s, but I suspect it is legal for odd frame sizes. Also note that the displaysize of the first MPEG2 example is the same as the codedsize and not consistent with the aspectratio (if it is supposed to be DAR). So maybe I am misinterpreting that figure too.

I regret that I do not have time to do a research project on this. If you have a specific recommendation I will consider it.

Putting the SAR in either the .log or the .dgi for all input file formats for which it can at all be determined would certainly work. Without studying the source, I have no idea whether that would be a few lines (if, e.g., the sar is always already stored in some variable and just needs to be consistently dumped out) or a major effort (if calculating the SAR was complicated and heavily format dependent).

CarlEdman wrote:Putting the SAR in either the .log or the .dgi for all input file formats for which it can at all be determined would certainly work. Without studying the source, I have no idea whether that would be a few lines (if, e.g., the sar is always already stored in some variable and just needs to be consistently dumped out) or a major effort (if calculating the SAR was complicated and heavily format dependent).

Read the specs and tell me if the SAR is available in the stream for your problem case (or can be derived from stream information). As I said, I don't have time to do this research for you. Consulting contracts are always welcome, however.