GSpot v2.60 b00

[Bathrone]

Not sure if this has been reported before but on vista x32 I found the RC1 gspot crashed on detecting directshow codecs but recovered with the user message about the setting being disabled etcetc.

[stegre]

I've just posted an early release of GSpot 2.70 (http://www.headbands.com/gspot/) -which should be Vista compliant now. It also now also supports (though not 100% completely yet) MOV and WMV/ASF containers, and has extended MP4 support including full ftyp identification (http://www.ftyps.com/).

[HeadBangeR77]

Thank you, gonna download and test & use of course. ;)
cheers,
HDBR77

[Bathrone]

Awesome, thanks

[SeeMoreDigital]

Thanks Steve,

Just noticed 2.70 is not correctly reporting the channel order of 2Ch or 6Ch AAC-LC or HE audio streams placed within .MP4 or .M4A ;)


Cheers

[stegre]

Hey SMD- Is that a new bug? What's the prev version report?

[SeeMoreDigital]

Hey SMD- Is that a new bug? What's the prev version report?Yes it's new.... 2.60 RC1 correctly displayed the channel total.

Do you require some "audio only" samples?

[JarrettH]

2.70 is displaying my 5.1 AAC-LC MP4 files as 2 channel too. Also, the video bitrate is reported wrong (2.60 RC1 worked). Shows the bitrate as about 300kbps higher. Does GSpot work with MKV files?

[HeadBangeR77]

- Ctr+O still not working (it's the most important shortcut for me ;))
- XviD 1.1.2 displayed as XviD MPEG-4 ISO, as it used to be with some older version than RC-1, and G-Spot can't determine, if decoder is installed, what has never happened to me before.

If I find sth more, I will update this post.

cheers,
HDBR77

UPDATE:
- the same (as for XviD) is valid for DivX 6.4 (G-Spot cannot read the exact version + codec status undetermined), while RC-1 used to work;
- it's got problem with older XviD encodes as well: 1.1.0, 1.0.3.,1.0.2 are the ones I've tried so far + DivX 6.0, 5.2.1, 5.1.1 (seems MPEG-4 ASP in general ?)

RC-1 works like charm. :confused:

+ sometimes after minimizing the statistics for frames are missing - I mean the stripe with percentages of each frame type - the stripe goes black.

[stegre]

OK, apparently some last minute bugs had crept in that caused a variety of issues - please replace with v2.70a (http://www.headbands.com/gspot/), available now. Supports Ctr+O, too :)

[SeeMoreDigital]

Thanks Steve,

Small thing.... I've just used BeLight to generate some 2Ch and 6Ch AAC-HE and LC ADTS .AAC test streams. Using the "MPEG-2" and "MPEG-4" encoding options.

After feeding the files thru' GSpot 2.70a, MPEG-2 AAC streams are reported as being MPEG-4 and MPEG-4 streams are reported as being MPEG-2.

UPDATE: After muxing the 2Ch and 6Ch AAC-HE and LC ADTS .AAC test streams into the .MP4 container using YAMB/MP4box. Everything is correctly reported.


Cheers

[HeadBangeR77]

OK, apparently some last minute bugs had crept in that caused a variety of issues - please replace with v2.70a (http://www.headbands.com/gspot/), available now. Supports Ctr+O, too :)

All the bugs I've described above are fixed now. No problems with shortcuts or MPEG-4 ASP (DivX, XviD).

Thanks very much for the quick reaction. :)

[zambelli]

Hi Stegre,

Just installed GSpot v2.70a - very nice work!

I have one request, since I keep an eye on these things: can you fix the WM codec names? Right now WMV codecs are identified as "WMP" codecs, which doesn't make much sense (Windows Media Player?). The Wikipedia article on WMV has the correct list of codec names: http://en.wikipedia.org/wiki/Wmv. Look under "Versions". Thanks!

[smok3]

something got bork with commandline i think,

gspot.exe file.avi /x (not working)
when
gspot.exe file.mp4 /x (is working)

(version 26 does work fine)

?

[Mtz]

I hope this question wasn't already in this thread but is hard to search for "DV".
I have a MiniDV camera Sony DCRHC96. I can record with it in "progressive" mode. I loaded the DV file in Gspot and it reported as I/L (interlaced). Loading the same file in AutoGK for conversion, during the analyze pass it reported as Progressive. Looking at the video in virtualdub I cannot see the movie interlaced and seems to be progressive.
Sample files are here: http://www.sendspace.com/file/1sejtj
Which is the true? I need to know this because of settings in CCE.

enjoy,
Mtz

[stegre]

I'm downloading your files and will examine them & check more into this subject - it's probably something I think is called "PSF" ("Progressive Segmented Frame") where it stores alternate lines in two fields, like interlaced, but each pair of fields is sampled at the same instant in time. Then, 1/25th sec later it samples another pair. By contrast, in "real" interlaced video each frame is sampled 1/50th of a sec after the previous one, so the odd and even scan lines never "line up" on consecutive frames for moving subjects.

That's OK for watching TV live at 50FPS, but the PSF system is a much better for xfer to computer formats because you can perfectly mesh pairs of fields and get perfect 25FPS video with no interlace artifacts and no de-interlace "filters" required to "blur" the lines together.

If all the above is true, the answer is kinda "both", but GSpot would see that as interlaced, since that's how it's stored, and there may not be a flag bit to identify it otherwise (I think the VC-1 format has a flag for this, which is cool, but that's besides the point). Anyway, lemme find out more about it & see if I'm even on track here.

[Mtz]

From the manual (if something wrong in english, is not my fault:

##########

Progres.Rec (25p)
You can reduce image blur when recording moving pictures on tapes, intended for import to your compter as still images. This is especially useful for analyzing high-speed action, such as sport scenes.

Note on the progressive recording mode:
In a normal TV broadcast, the screen is divided into 2 finer fields and these are displayed in turn, every 1/50 of a second. Thus, the actual picture displayed in an instant covers only half of the apparent picture area.
In progressive recording, the picture is fully displayed with all the pixels. A picture recorded in this mode appears clearer, but a moving subject may appear awkward.

##########

About Gspot: make a comparison between Gspot and BitrateViewer regarding interlacing for mpeg files. In Gspot all are reported as I/L but in BitrateViewer some of them are progressive.

enjoy,
Mtz

[SeeMoreDigital]

Hi Mtz,

I've just had a look at your files.

After some jiggerie pokerie with QT7 Pro, I managed to get your "ProgressiveSonyDCRHC96__DV.avi" source, to be detected as "progressive" in GSpot: -

http://img443.imageshack.us/img443/6883/dvsourcetu8.png

Also, when I feed your "InterlacedSonyDCRHC96_XviD.avi" into MPEG4 Modifier.... it's not detected as being "interlaced": -

http://img477.imageshack.us/img477/8113/xvidirm4.png


Cheers

[Booji Boy]

Wow, great to see some development on GSpot again...

I have a quick feature request (quick means I haven't checked if it was requested before):

Add [or remove] GSpot Quicklauch Shortcut

[Mtz]

Hi, SMD!
You made a conversion from my DV from type 2 to type 1 and because of that Gspot I think reported as progressive. Also you can make this with a very nice and free program called DVDate.

Regarding the XviD files, I wrote some details on sendspace, but are not displayed (truncated info).
Some info about XviD:
- both DV files was encoded with AutoGK. Always AutoGK make some analyzing and if the source is found as interlaced, it will deinterlace it. The InterlacedSonyDCRHC96__DV.avi was found as interlaced and AutoGK applied deinterlacing.
The ProgressiveSonyDCRHC96__DV.avi was found as progressive and no deinterlacing was applied.
- I made both test to see if the progressive recording is better than normal recording (interlaced) if the user want the output as progressive. Maybe the sample is too small to judge it.
- some time ago I asked len0x to implement a hidden setting in AutoGK to keep the files interlaced. Analyzing in AutoGK is time consuming and if I want to keep it interlaced (for standalone purpose) I can't make it. Is not just about be, because I can use Gordian Knot instead, but for Average Joe with a standalone. At that time, len0x said something like: "Mtz, this is a useful feature"... and useful remained. len0x stopped development on AutoGK and Average Joe is forced to deinterlace. I know you have many standalones and I think if you have some DV material you'll want to keep it interlaced. The difference between SMD and Average Joe is that SMD can make nice encodes without AutoGK.

enjoy,
Mtz

[foxyshadis]

MeGUI has the option to turn off deinterlacing, though. Not in its one-click mode, but you could open the script editor after it starts the process to uncheck it.

[stegre]

Hey, Mtz, I saw your post over in the DV section while I was trying reading trying to sort out all this interlace vs. progressive DV myself. There are a number of "progressive" systems which don't qualify as true progressive (e.g. this "green vertical pixel shift system" (http://web.archive.org/web/20010124081100/http://www.dv.com/magazine/2000/1100/wilt1100.html) - though I assume that's outdated now). But back to your camera, besides the description you've given from the manual, I've also found that Sony describes your camera's progressive as follows:
Progressive Shutter System: A mechanical shutter system that provides progressive scan performance while utilizing an interlaced scanning system. Digital still images will be sharp and clear with excellent definition. Maybe some of the DV experts here or in the DV forum can shed further light on exactly how that differs from true progressive. Because GSpot's indicator notwithstanding, your progressive clips sure look progressive to me, and I would probably treat them that way. They certainly don't need any de-interlacing.

Now, as far as what GSpot's reporting, it seems to an accurate reflection of how your camera is identifying it - I guess that ties in with Sony's phrase "while utilizing an interlaced scanning system".

Since your Xvid encodes are "two steps" away from the original, so I didn't even really look at them, but I did take your Type 2 DV AVI files and "de-muxed" them back to a RAW DV stream, which is probably bit for bit identical to what came out of your camera. I then confirmed that "bit 4 of PC3 of the VAUX source control pack" (not too get too technical or anything ;) was indeed set to "1" - which indicates "interlaced" - on both your samples.

So I don't know what the "upshot" of all this is. As I said, I'd ignore GSpot ;) - treat them as progressive. As far as what I should do with GSpot - if I should make some kind of change or anything - I'm going to wait until I understand the whole subject a bit better.

[SeeMoreDigital]

Maybe some of the DV experts here or in the DV forum can shed further light on exactly how that differs from true progressive. Because GSpot's indicator notwithstanding, your progressive clips sure look progressive to me, and I would probably treat them that way. They certainly don't need any de-interlacing.Agreed. However the camcorder does it, it seems to be doing it very well indeed.

I saved each frame as a still image and they look excellent :)

[jolson]

Thanks for GSpot :-)

[zambelli]

Agreed. However the camcorder does it, it seems to be doing it very well indeed.
I saved each frame as a still image and they look excellent :)
I don't think this is as mysterious as it sounds. In order to make the images progressive, all the camera has to do is reduce the shutter speed to 1/25 (if PAL) or 1/30 (if NTSC). The rest of the camera continues to work exactly as it did before, recording the images as interlaced, but because the same image remains persistant for two 50ths or 60ths of a second, there will be no temporal difference between the fields of an interlaced picture.

For most practical purposes the image can be treated as progressive. HOWEVER, because it's actually encoded as an interlaced image, the chroma in the 4:1:1 and 4:2:0 images is going to be sited using interlaced mapping, so any conversion from YUV to RGB or spatial scaling should be done using the interlaced method.

[stegre]

...The rest of the camera continues to work exactly as it did before, recording the images as interlaced, but because the same image remains persistant for two 50ths or 60ths of a second, there will be no temporal difference between the fields of an interlaced picture...

I was thinking about it too, and I totally agree with above quoted part of your explanation. But as far as the exposure time itself - using PAL numbers here - I think one thing you could not get is a "1/25th sec exposure".

If his camera had manual exposure time control, the longest exposure time possible in interlaced mode would be 1/50th of a sec, and Im guessing the same remains true in his camera's progressive mode. I think the "mechanical shutter" device mentioned is a reference to a mechanical shutter (duh), which, in progressive mode, blacks out any additional light from coming in on every second field. Then, during the second field time, the camera proceeds to clock out the other half of the scan lines from the CCD, which, as you say, still contain the same "persistent" image as the prior field. No temporal difference & hence no interlace artifacts.

However, this method could, and probably often is, used with very short exposure times, which is why one of the advertised features is that it's "you can reduce image blur when recording moving pictures on tapes, intended for import to your computer as still images. This is especially useful for analyzing high-speed action, such as sport scenes".

What this means is that with short exposure times, this "shutter system" approximates true progressive - when it too is set to a fast shutter speed - almost exactly. In both systems each frame would be a series of clear frozen snapshots representing, say, the first 1/1000th of sec of each 1/25 sec interval of real time. This would be good for creating stills for analyzing high speed action.

At the other end of the spectrum is one of the only ways it differs from a film camera or true progressive - something I'm guessing you can't do with his camera's system. With real film or real progressive, if you wanted to, you could set the longest possible exposure time to be 1/25th sec. Then fast moving objects would be integrated over that time into a blur, but the "end of one blur would be the beginning of the next" on consecutive frames, which might be desirable as a film effect for a fast moving object. With this system, at the max shutter speed of 1/50th sec, you'd get a 50th sec of "blur" and then a lapse in time. The following frame's "blur" would start at another position - there'd be a gap in between. And that may tie in with their statement about how "a moving subject may appear awkward".

All the above is speculation, but besides basing it on the manufacturer's statements I mentioned, I did take a close look at DJ's "progressive" samples, and they individually appear to be quite clear - as if short exposure times - then there's a big "distance" jump to the next frame. The frames do not look like an exposure that was averaged over the entire 1/25th sec.

[stegre]

Anyway, to other posters, I'm not ignoring you.

"Thank you for the thank you's", and...
I'm looking into any bug / suggestion posted here.

In fact, I'm working on GSpot as we speak. The whole "progressive discussion" above is a bit of a distraction, albeit an interesting one.

[GrofLuigi]

Anyway, to other posters, I'm not ignoring you.

"Thank you for the thank you's", and...
I'm looking into any bug / suggestion posted here.

In fact, I'm working on GSpot as we speak. The whole "progressive discussion" above is a bit of a distraction, albeit an interesting one.

Since you mentioned, any chance of implementing the "total running time of the clip" in "big shiny letters" "at all times"? :)

I really need this for synchronizing video and audio - usually I process them separately and it's pain to load multiple instances of virtualdub (which doesn't give the time of audio only without the video). Audio editors take long time to load the audio. Highest precision (in miliseconds) is preferred.

Thank you in advance (even for negative answer). :)

GL

[stegre]

Yes, I'd been meaning to add an "audio duration" field separate from the current "duration" which currently is, and would be re-labeled as, "video duration". Your phrase "total running time" seems ambiguous, though. I'm assuming having each duration value available separately, as described above, would be better, if anything. In containers like AVI they audio & video will always both start at the same time, so the durations should match, and if they don't I suppose the longer one could be called the "total running time".

But I think I'll simply list each separately - if you saw they were significantly different then presumably you'd want to change the framerate, or truncate the beginning or end of the audio, or pad the beginning or end of audio, or either those two for the video, or possibly even resample audio to a different duration. But that would certainly be up to the user how to get them in sync if they’re different. What you'd like, I'm guessing, is just to have the two values available at glance; hopefully most of the time they'll be a match.

What's ambiguous and complex are more advanced containers that support time stamps or otherwise somehow correlate the video to the audio, in which case a file could say, have two minutes of video and two minutes of audio, yet be three minutes long (and, if by design, maybe even in perfect sync!)
0.........1.........2.........3
|<--- video ---|--->|
|<---|--- audio --->|
|
^ may even be in perfect sync hereI suppose for such a concoction I could list "2 secs audio" and "2 secs video" with "3 secs total running time", but the above example is pretty contrived and I'm not going to worry about it.

Thanks for reminding me of this though. In fact I’ve actually wanted that the audio duration feature in GSpot myself when I occasionally open just a plain wav/mp3/AAC/AC3 or whatever file. Even though GSpot wasn't originally conceived as a tool for plain audio, in most or all of those cases it does give you the encoding type, sample rate, bitrate & other basic info - but indeed it neglects to display duration - a rather basic characteristic. So I'll definitely add that.

[GrofLuigi]

Stegre: do whatever you can, I'm most thankful. :)

GL

[Mtz]

If his camera had manual exposure time control, the longest exposure time possible in interlaced mode would be 1/50th of a sec, and Im guessing the same remains true in his camera's progressive mode. I think the "mechanical shutter" device mentioned is a reference to a mechanical shutter (duh), which, in progressive mode, blacks out any additional light from coming in on every second field. Then, during the second field time, the camera proceeds to clock out the other half of the scan lines from the CCD, which, as you say, still contain the same "persistent" image as the prior field. No temporal difference & hence no interlace artifacts.
I made this 2 simple scripts:
1.
AVISource("I:\MiniDV\InterlacedSonyDCRHC96__DV.avi")
separatefields()

2.
AVISource("I:\MiniDV\ProgressiveSonyDCRHC96__DV.avi")
separatefields()

and opened 2 instances of VDM and I jumped from frame to frame in both examples. Differences:
1. jumping to next frame as expected
2. repeating the last frame and than jumping to the next. The repeated frame I think is the second field.

I don't know what to say about this because I'm not an expert here.

enjoy,
Mtz

[unskinnyboy]

Steve, GSpot is at v2.70a and supporting more formats and containers, and that's all very good, but I just want to make sure that something which we discussed (http://forum.doom9.org/showthread.php?p=897647#post897647) sometime back isn't being forgotten in the midst of all this. :) I am talking about demuxing the whole video stream (including all the parts) out of a Multipart OpenDML AVI to get the bitrate information. As of v2.70a, the video bitrate of a Multipart OpenDML AVI is still reported incorrect.

[unskinnyboy]

Steve, OK you still seems to be offline. But, when you are back, I have yet another request pending for you - expand the export format, which hasn't been updated since 08/14/06. i.e. add more fields. I'd like to see the following exported:


AR in ratio format (e.g. 5:2) (it appears that %VIDEO_ASPECT_FRAC% which used to give this value is no longer available in the latest builds of GSpot. I am not sure when this might have been taken away, but in v2.70a, trying to use %VIDEO_ASPECT_FRAC% gives me an ***ERROR***. Why was this removed?

Channel distribution information for AC3 (e.g. 3/2.1, 2/0). Now, I understand that is constant all the time and you have probably hard coded this in your program - something like IF 6Ch, then write 3/2.1, IF 2Ch, then write 2/0, etc., but I'd still like to see this exported. The idea is to get the channel distribution information too in the output specs.

Container details like video %, audio % and AVI overhead.

The video frame information for the Interleave/Preload values (e.g. 2.3 v.frames)