GSpot v2.60 b00 [Archive]

clsid

5th September 2006, 17:55

Looks great and new features are pretty cool. Here are some of my observations after throwing a couple files at your new version. Hope this helps you to improve GSpot. I can upload the files if you need them.

File: VP62_With_Alpha.flv
Only container is detected. No codec info.

File: VP62_Without_Alpha.flv
Shows "compatibility warning: Sorenson type 8 FLV"
FourCC is identified as "FLV1". I think that should be "FLV4" in this case.

File: 6ch.HE-AAC.VBR-streaming.mp4
Audio is detected as "MPEG-4 AAC LC".
Codec status as undetermined. I guess it is not yet implemented?

File: 80e_11064_H [704x576i].mpeg
Shows "scanning @ 0 MB/s..." and doesn't seem to scan the file.
Audio is identified as "MPEG-2 LC Profile" with status "NOT installed". However audio plays fine with ffdshow audio decoder in GraphEdit.

File: mpeg1-tmpg_cbr-noB_mp4ui.mp4
Error: integer division by zero

File: asp-1b-pb_divx_mp4ui.mp4
Error: integer division by zero

File: BBCHD1-Clip.mpg
Not recognized.
File is MPEG-1 TS with H.264 and AC3.

File: BBC_H264_test6.ts
Not recognized. I guess Transport Streams are not (fully) supported yet.

Formats that show "status undetermined":
video: avc1, mp4v, FLV1
audio: MPEG-4 AAC LC, MPEG-1 Layer 3, MPEG-1, MPEG-1 Layer 2

How is determined if a required video codec is installed? Some formats (3iv2, tscc, vp3) are detected as "codec not installed", while I can play them fine with ffdshow.

I also have some issues with MPEG2_VIDEO. Sometimes it is detected as installed and sometimes it is not. Could it be related to the source filter? The video codec is detected as installed if mpg2splt.ax is used. When Gabests splitter is used GSpot detects the MPEG-2 codec as not installed. Perhaps it is because Gabests splitter gives a partial failure (it always enables the subtitle pin) in combination with some decoders?

shon3i

5th September 2006, 18:52

WOW, This is great, many thanks.

masken

5th September 2006, 22:01

indeed nice work steve!

lolent

5th September 2006, 22:18

a very good news, gspot is back ! :cool:
for a long time, I hope ;)
thanks for your soft.

stegre

7th September 2006, 05:11

Thanks again everyone. I'll address clsid's post separately, whose error reports range from "known and being worked on" to somewhat surprising to totally shocking. That'll take a day or two, and thanks, I definitely may want copies of some of those files.

SMD, I'm surprised at that too and will look into it.

But I'd like to address the post by unskinnyboy, as it indirectly brings up a subject I've only recently discovered and have very little information on - perhaps someone here could help. The quick answer to unskinnyboy's question itself is that for formats and/or containers with a header containing info on frame rate and number of frames (e.g. AVI), I used to use that info exclusively. That was for ease, speed, and as it turns out is probably more accurate as well see below). For completely streaming formats (e.g "pure" MPEG) however, I used a "trick" whereby I read the beginning and end of the file only, and then subtracted embedded timestamps. But that trick can have its problems, which I won't get into here.

For combined formats, e.g. MPEG4 in AVI such as DivX/XviD, etc, I have a choice, since I'm now completely demultiplexing the video stream from the AVI container anyway to obtain other information.

There are two main discrepancies which can come up. The first of the two involves the so called "packed bitstream", where there are extra MPEG frames which are "not coded" and have "zero time". These are often called N-VOPS. These I'm familiar with. GSpot will display the words "packed bitstream", display the NVOP "light", and show them as skinny vertical bars "between" frames on the VGS display. Besides that they are not counted, and that takes care of that issue (+/- a frame or so, I guess depending on whether you count the last one or something).

But the other issue is new to me and much more mysterious - I've only run into it recently. These are empty AVI frames with no MPEG content. Apparently the correct way to handle these on playback is to play duplicate (or "extend") the single MPEG frame for the duration of the subsequent AVI frame.

VDubMod handles these correctly, and apparently refers to them as [D] frames, though they refer to them "AVI drop frames" which is clearly misleading. In standard video parlance, a "drop frame" is a skipped frame, used to reduce frame rate. Those are usually located infrequently within a stream and almost always specifically intended to reduce 30FPS to 29.97FPS. These "[D] frames", by contrast, are "duplicated" frames and are used to increase the frame rate. In the file I've been analyzing, every sixth frame was a [D], and the point was to increase the displayed frame rate from 25FPS to 30FPS (albeit with some added "jerkiness").

So how are these frames handled by various apps? GSpot currently displays the correct #of AVI frames and correct rate of 30FPS which gives the correct time on the main screen. The VGS display displays the correct number of MPEG frames but that results in the incorrect time, contradicting the main screen.

MPEG4-Modifier displays the correct breakdown of MPEG frames on its summary screen, yet contradicts that on its "list" output by giving the number of AVI frames (and none are marked "M", I guess they're marked the same as the previous frame). The timestamps next to each frame are wrong though, apparently taken from the MPEG frame count, so the total duration of the file is also off by 20%. VDubMod handles them pretty well, though it leaves them out of its summary altogether. When "scrolling" thru the file, though, the duplicated frame is displayed with a [D] designation, and all times are correct. My only objection there is the designation "AVI drop frame", which seems to be at misleading name, at best. Though [D] could conveniently stand for "duplicate" as well, which is the direction I'm heading.

I've prepared a series of screenshots with descriptions, as well as a sample file - it's located here (http://www.headbands.com/gspot/v26x/avi_d_frame/). A doom9 forum search for the exact phrase "AVI drop frames" (to eliminate false matches for the "regular" use of the phrase "drop frames") led me to a single post (by "foxishadis" who seemed to know what they were, and that ffmpeg was capable of creating these files - I'm going to check into that). Meanwhile, anyone have any more info one these? Are they common?

squid_80

7th September 2006, 08:29

Depends what you call common. If you make an avi file by capturing, there's a possibility at some point that frames will be lost somewhere along the way and not get delivered to the host program; when this happens an empty frame is inserted to keep the audio and video in synch. On the other hand if you're transcoding a dvd you're not going to see them at all.
Other cases are mixing 24 and 30 fps content into the same avi file; this is made possible by adding dropped frames to pad the framerate to a constant 120fps.

SeeMoreDigital

7th September 2006, 08:39

A few months ago Celtic_Druid created a build of XviD that allows the user to more easily generate MPEG-4 encodes with N-VOP's and P-VOP's.

I have used it to generate the following MPEG-4_VOP_Test_Cards (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPEG-4_VOP_Tests.zip) examples. Which I've been using to test various stand-alone players.

The encodes might help reveal differences between MPEG4 Modifier and GSpots VOP reporting too.

Cheers

clsid

7th September 2006, 18:17

I have already uploaded a few of those sample files for you. Another place to get many sample files is on mplayer sample page (http://samples.mplayerhq.hu/V-codecs/).

http://rapidshare.de/files/32286069/VP62_With_Alpha.flv.html
http://rapidshare.de/files/32286129/VP62_Without_Alpha.flv.html
http://rapidshare.de/files/32286743/80e_11064_H__704x576i_.mpeg.html
http://rapidshare.de/files/32286828/asp-1b-pb_divx_mp4ui.mp4.html

stegre

8th September 2006, 04:46

squid_80: Interesting, you're "frame missed on capture" scenario could explain why one use might use the word "drop": indeed it's possible a frame was dropped (past tense) in the sense that it was lost, so a a "dup" frame is created to compensate. But when I get around to handling these properly I'm still definitely going to call the extra compensation frame "dup" frame, especially considering phrase "drop frame" already has another, entirely different meaning, one which is basically the opposite.

Anyway, it's interesting that in my example file it was done for neither of the reasons you cite (i.e. no lost frames or mixed frame rates), but rather to increase the rate from exactly 25FPS to exactly 30FPS for (for what exact reason I'm not sure). But your info is interesting.

SMD & clsid: thx for the file links, these are gonna great for getting all the bugs fixed. They're gonna keep be busy for a while. SMD, your NVOP file is showing up bugs in a few places (GSpot's confusing it with a packed bitstream), and I'm gonna go fix those now.

SMD, I'd also like to see your "1024 x 576 PIC" file, but that brings me to a question: Do you consider GSpot's size & aspect display of the "4.3 (720-to-768x576)" files you posted to be correct? I personally do - i.e. it is working as designed. It shows that the files is internally stored as 720 x 576 (a 5:4 ratio) but because it should be displayed using a pixel aspect ratio of 1.067 as shown in GSpot's "PAR" field, the viewer should really be watching a 4:3 picture - also shown correctly in the display aspect ratio ("DAR") field.

The fact that I don't display the numbers "768 x 576" don't appear anywhere is because that's just one of an infinite number of sizes at which the user could view the file and still see a proper aspect ratio. That particular size might be considered "special" because it just happens to be the one where the width is increased and the height left unchanged from its internal value. But equally so is "720 x 540", the size obtained by leaving the width unchanged and reducing the height to get the correct ratio. And, as I say, besides those two, there are an infinite numbers of other "correct" display sizes you can get by changing both numbers properly.

squid_80

8th September 2006, 05:01

There's a bit more information about these weird framerate files here: http://www.virtualdub.org/blog/pivot/entry.php?id=103#body

G_M_C

8th September 2006, 10:05

Hi, glad to see you're back with a new update of GSpot ! Been using it for years now, and even Ye Olde Versions still work for me :)

I've got one request though (for a new feature or such); Lately i've been re-encoding some Avi's, and found a need for a tool that gives more info about the audio-stream of a given video-file.

This because lately i see many Avi's where the Audio and the Video-stream don't have the same length and/or are offset (to get them in sync).

Is it possible to build in a feature that display's the length of the audio-stream and the delay (the offset) of the audio-stream ?

It would make my live (en probably many others' lives) easiere, because syncing audio to video can sometimes be e f***ing hassle. Help in the form of a info-tool would be great !

unskinnyboy

8th September 2006, 12:46

Is it possible to build in a feature that display's the length of the audio-stream and the delay (the offset) of the audio-stream ?
Even if Steve doesn't get around to it, File -> File Information in VirtualDubMoD will give you the exact audio length. As for the delay, well..there is no tool which can reliably detect it. It is more of a human thing - the ability to detect the correct delay/sync.

G_M_C

8th September 2006, 14:06

Even if Steve doesn't get around to it, File -> File Information in VirtualDubMoD will give you the exact audio length. As for the delay, well..there is no tool which can reliably detect it. It is more of a human thing - the ability to detect the correct delay/sync.

It should be possible. If you demux a DVD using DGindex, you for instance get a file MOVIE_AC3_DELAY80.AC3.

When converting that movie to XviD, you heve to specify a deley of 800 microsecs when remuxing the audio. So DGIndex shows it is possible to detect delay in DVD/VOB's.

I hope it is possible to detect the delay in AVI's too, through GSpot.

PS: length of audio, i allready know. But still, the delay would be nice, ive seen some strange encode's the last few months

Bathrone

10th September 2006, 01:53

Lovely :)

Would be nice if MKV and WMV info's were shown as well.

SeeMoreDigital

10th September 2006, 17:17

SMD, I'd also like to see your "1024 x 576 PIC" file...Sure, here are some samples (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPEG-4_ARS_in_MP4_Tests.zip) for you.

but that brings me to a question: Do you consider GSpot's size & aspect display of the "4.3 (720-to-768x576)" files you posted to be correct? I personally do - i.e. it is working as designed. It shows that the files is internally stored as 720 x 576 (a 5:4 ratio) but because it should be displayed using a pixel aspect ratio of 1.067 as shown in GSpot's "PAR" field, the viewer should really be watching a 4:3 picture - also shown correctly in the display aspect ratio ("DAR") field.Yes the output resolutions are correctly calculated and exactly match the pixel information provided by MP4Box.

When the MPEG-4 stream is de-muxed to an elementary (.CMP or .M4V) stream, GSpot reports the correct resolution.

By-the-way, currently you identify/reveal the "Aspect Ratio Signalling" value as a decimal. Have you considered offering it as a ratio instead?

Cheers

stegre

11th September 2006, 01:12

OK, that's cool about the AR's, and thx for the new files. BTW, I "loved" your test pattern file which was just all NVOPS except for two keyframes. That rather unusual file showed up bugs in GSpot in a surprisingly wide variety of areas, ranging from incorrect "packed bitstream" detection to basic parts of GSpot's AVI demux code, which failed when frames were exceedingly short. I spent about a day with that file alone and have resolved most of those problems. The AVI demux fix actually involved removing some "broken" but as it turns also unnecessary code, so GSpot may even run a bit faster now.

In some fields I do show decimal ratios as integers, especially if they're internally specified as integer ratios, which is the case for certain fields in certain file formats. In some other cases, I also "reverse compute" ratios - I actually already have a routine that "un-converts" decimals to ratios of integers only if such integers both exist and are both "smallish" numbers and the resulting ratio is "close enough". So I may need only to add that routine to that field. I actually like to display both formats, too, if there's room.

I know I haven't still haven't even commented on a bunch of the other posts above, I'll do so as time permits... thx everyone.

Steve

SeeMoreDigital

11th September 2006, 16:08

If you liked those then have a gander at these MPEG-4 N-VOP Test Cards in AVI and MP4 (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPEG-4_N-VOP_Test_Cards_in_AVI_and_MP4.7z) samples!

They all have a 60 second run time and have been encoded with just 2No I-VOPs (one at the start, one at the end).

What I can't understand is why the file sizes are so big when they only contain 2No I-VOPs and max out at 96Kbps!

By-the-way, I got the idea of generating these types of files after I de-muxed the MPEG-2 stream from a THX test card and found it only contained a few frames. Here's an example (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPEG-2_720x576_Test_Card.7z).

The mystery of MPEG-4 N-VOPs eh?

masken

11th September 2006, 18:34

Will GSpot ever handle DVD's?

Like indexing chapters and their bitrates & length, audio tracks, subtitles etc?

SeeMoreDigital

11th September 2006, 19:00

Will GSpot ever handle DVD's?

Like indexing chapters and their bitrates & length, audio tracks, subtitles etc?It can read individual .VOB files and list everything you mentioned except chapters and subtitles!

Cheers

stegre

12th September 2006, 02:16

SMD may be a little optimistic on that. I have "no official comment" on VOB file handling ;)

Seriously you're probably both right: in "sort of handles them": what I do now, so far, anyway, is just scan them as if they were any other MPEG file, so it will find and extract a lot of correct MPEG2 info and display it. Addition of "full fledged" DVD support would probably be a big job; it would be cool, but I have bunch of smaller items on the "to-do" list first (like the fixing bugs and unrecognized file types such as those an earlier post by clsid, and adding support for some really common file types it's missing now, [e.g WMV, MOV, RA] as well as adding support for Matroska containers and other stuff).

And even in the case of newer filetypes which I have recently added which do display correct info, much of it is still incomplete, showing blank fields where the info really should be available. And then there's all the codec related stuff, as a many GSpot users only want a simple non-technical answer to "why won't this file play", and could care less about the file's technical details.

I've just noticed when I open MP4 files containing MPEG-4 Part 2 streams with aspect ratio signalling, the "PIC" dimensions given are "after" aspect ratio signalling has been applied...

For example an 720x576 stream with 16:9 DAR (64:45) signalling is listed as having a "PIC" size of 1024x576
I have your file now, and you are quite correct about it being wrong. As the "PIC" tooltip says, it's supposed to display the size as "internally stored" which is indeed 720 x 576. In this case, I got that info from the MP4 container, not the demuxed MPEG video stream (in fact if you demux the file, it shows the correct info). I incorrectly interpreted the meaning of the field in the container. I'm working on that now.

SeeMoreDigital

12th September 2006, 08:25

Is there any possibility you can configure GSpot to provide FPS speed information of raw/elementary MPEG-4 Part 2 streams?

I did not know whether it would be possible so I asked about it here: -
http://forum.doom9.org/showthread.php?t=115774

Cheers

GodofaGap

12th September 2006, 09:23

But when I get around to handling these properly I'm still definitely going to call the extra compensation frame "dup" frame, especially considering phrase "drop frame" already has another, entirely different meaning, one which is basically the opposite.
If you want to deviate from this might I suggest the term "null frame" (as Avery Lee uses in his blog). It describes exactly what it is, a frame with a 0 byte lenght. Personally I find duplicate even more misleading than AVI dropped frame, because nothing is duplicated, at best it is a padding.

SeeMoreDigital

12th September 2006, 11:12

Personally, I'm of the opinion that "N-VOPs" (Not coded/Null frames) and "Packed Bit Stream" should be treated as two totally separate implementations...

If we into "frame naming" suggestions how about: -

C-VOP = Crammed ie: Packed Bit-stream
D-VOP = Duplicate coded frame
F-VOP = Filler coded frame (if we are not calling them N-VOPs)
R-VOP = Reduced coded frame ie: Dropped frame

No doubt others will leap in and correct my foolishness!

Cheers

foxyshadis

12th September 2006, 11:45

Haha! Perhaps we need to think up a frametype to go with every letter of the alphabet.

PB-frame seems to be pretty common (and easily understandable) term for the packed frame. I'm not quite clear on whether it's two VOPs packed into one avi frame, or two frames merged into a single VOP (likewise, if the empty frame is an avi null frame or an mpeg N-VOP), which might affect the terminology if you're being sticky about it.

masken

12th September 2006, 13:00

@Steve, but GSpot could be used for so much more, like an external plug-in for a movie database for example :) It is very nearly the only necessary technical information tool as it is today. Adding (for example) a separate DVD-tab which displays all track with their bitrates and length, audio tracks, chapters and subtitles would make it complete :)

iNFO-DVD

12th September 2006, 13:09

like an external plug-in for a movie database for example :)oh no, please no.....

masken

12th September 2006, 13:50

What are you oh-noing about info-dvd? :p

It is that today with the command-line export. Not suggesting anything else, the export functions are quite good as they are.

If a tool has multiple uses directly related to what the tool was built for, why not expand the capability?

GodofaGap

12th September 2006, 14:29

If we into "frame naming" suggestions how about: -

C-VOP = Crammed ie: Packed Bit-stream
D-VOP = Duplicate coded frame
F-VOP = Filler coded frame (if we are not calling them N-VOPs)
R-VOP = Reduced coded frame ie: Dropped frame
This is nonsensical. MPEG4 has already a naming scheme for their frames. (I-VOP, P-VOP, B-VOP, S-VOP, N-VOP)

When talking about AVI, the VOP terminology has no meaning since AVI simply doesn't have VOPs. An N-VOP is not the same thing as a frame marked with [D] in VirtualDub. It is an AVI specific thing.

I'm not quite clear on whether it's two VOPs packed into one avi frame, or two frames merged into a single VOP (likewise, if the empty frame is an avi null frame or an mpeg N-VOP), which might affect the terminology if you're being sticky about it.
It are two VOPs packed in one AVI chunk. The empty frame is an N-VOP, not an AVI null frame.

stegre

13th September 2006, 06:44

Yes, all of what GodofaGap is extremely accurate, though technically there are only four kinds of MPEG frames (it's specified with only 2 bits) - there are only I, P, B and S VOPs. Then there's a "not-coded" bit which could be applied to any of them, so in a sense you could say there are 8 VOP types, but that's not important in practice.

The so-called N-VOP's in question, as used in a "packed bitstream", are really P-VOP's (or possibly I or S also, I'm checking into that) but in any case to qualify they must additionally have the "not coded" bit set and also must coded to "zero time duration". This makes them really do nothing, though it takes about 7 bytes to specify all that nothing.

As GodofaGap says, everything above is purely MPEG related and has nothing to do with AVI (not yet - I'm getting to that). As I understand it, historically, somewhere along the line the DivX people decided to occasionally create these "nothing" MPEG frames, and when they do, they stick each one in its own AVI frame (using another 8 bytes of overhead for that, so now we have 15 bytes that do "nothing"). They apparently needed a "marker" of some sort which they could use to mark the end of each set of B-frames but would otherwise have no effect (though I'm not sure exactly why).

So, having done that - and I guess wanting to avoid having a more total AVI frames than there were MPEG frames - for every such extra AVI frame they create they compensate elsewhere by packing two "real" MPEG frames into one AVI frame (which actually re-saves 8 of the 15 lost bytes, btw) - but I guess the point is the final number of AVI frames and "meaningful" MPEG frames do end up matching. The final result of all the above has come to be called a "packed bitstream".

See diagram below, and note how the "double packed" ("P+B") AVI frames contain the exactly sum of the number bytes of two original AVI frames in the unpacked version - e.g. 3684 + 1627 = 5311.

http://www.headbands.com/gspot/v26x/avi_d_frame/images/packed_bitstream.png

Finally, GodofaGap is also correct that the [D] frames we've been discussing above are purely an AVI construct - indeed they are AVI frames of zero length & thus cannot have any MPEG (or any other) content. They use 8 bytes of overhead to specify "nothing here in this chunk". Scroll to the bottom of the page I previously posted here (http://www.headbands.com/gspot/v26x/avi_d_frame/) to see how the zero length chunks of the AVI [D] frame contrast with the 7-byte NVOP chunks above. What's ironic is that, unlike the NVOP frames, the zero byte AVI chunks are not ignored by the player and each adds one actual frame of time during playback.

squid_80

13th September 2006, 06:57

As I understand it, historically, somewhere along the line the DivX people decided to occasionally create these "nothing" MPEG frames, and when they do, they stick each one in its own AVI frame (using another 8 bytes of overhead for that, so now we have 15 bytes that do "nothing"). They apparently needed a "marker" of some sort which they could use to mark the end of each set of B-frames but would otherwise have no effect (though I'm not sure exactly why).

So, having done that - and I guess wanting to avoid having a more total AVI frames than there were MPEG frames - for every such extra AVI frame they create they compensate elsewhere by packing two "real" MPEG frames into one AVI frame (which actually re-saves 8 of the 15 lost bytes, btw) - but I guess the point is the final number of AVI frames and "meaningful" MPEG frames do end up matching. The final result of all the above has come to be called a "packed bitstream".

It was more the other way around. Packing 2 frames together was done for frame accurate editing of .avi files (with unpacked files there is a 1 frame lag) and the n-vop was added to the end so the final frame (the one packed with the b-vop) could be returned.

GodofaGap

13th September 2006, 07:51

What's ironic is that, unlike the NVOP frames, the zero byte AVI chunks are not ignored by the player and each adds one actual frame of time during playback.
Of course, if this wasn't the case, there wouldn't be any reason for them to be there in the first place. :)

SeeMoreDigital

13th September 2006, 08:22

I'm still a bit lost...

How is it I'm able to generate "Simple Profile" MPEG-4 samples (without packed bit-stream) at 25FPS and have them contain just 2No I-VOP's and make them run for 60 seconds?

If the other 1498 frames are not N-VOP's, what are they?

If the other 1498 frames are P-VOP's the file size would shoot up massively.... Here's an example (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPEG-4_P-VOP_Test_Cards_in_AVI_and_MP4.7z)!

Cheers

foxyshadis

13th September 2006, 09:21

squid_80

13th September 2006, 09:34

A not coded P-VOP (N-VOP) means show the last reference frame the codec received. In the case of an N-VOP insterted for packed bitstream reasons, the last reference frame is the P from the P+B packed combo. In the case of your samples, the reference frames are the I-VOPs.

VOPs have timestamps, not durations. N-VOPs inserted for packed bitstream have the same timestamp as the reference frame which replaces them.

SeeMoreDigital

13th September 2006, 09:45

Hmmm!

I was of the impression the reason DivX elected to use "packed bit-stream" when generating ASP streams with 1B-VOP was because the frame order in AVI is a compromise ie: generating ASP streams in MP4 offers a slightly different frame order!

GodofaGap

13th September 2006, 10:11

No. AFAIK both AVI and mp4 use decoding order. Of course MP4 does not need the N-VOP for padding, frames are re-aranged automatically. Although, I am not yet convinced the hack was really necessary for AVI, it is however for VFW. A Directshow (or any private API) decoder should be able to buffer as much as it wants, I think.

bond

13th September 2006, 18:37

my description of packed crapstream:
http://forum.doom9.org/showthread.php?s=&threadid=80430

Wilbert

13th September 2006, 21:04

@bond,

Could you post this stuff (or a reference to it) in one of the faqs?

SeeMoreDigital

13th September 2006, 21:53

@bond,

Could you post this stuff (or a reference to it) in one of the faqs?Indeed... good idea!

Is the information still fully current. Does any of it require updating/tweaking?

stegre

14th September 2006, 04:03

Based on stegre's explanation (which belongs in any video glossary!), I'd guess that they're P-VOPs with a not-coded bit, aka N-VOPs, only unlike packed bitstream these ones have an actual duration. I need to decompose some elementary streams and look at this myself!
Thanks :) I actually got "distracted" (in a good way, I guess) and ended up spending so much time on that "composite screenshot" and the associated post last night that I now hardly have time to read, much less respond to, many of the other (both older & newer) posts in this thread. But I'll be back here as soon as I have some time.

But I do want to mention that, yes, foxyshadis, you are absolutely 100% correct. Which is why I posted earlier that SMD's file he mentions above was so "interesting" to me: I so rarely, if ever, run into the "regular" NVOPS - ones with non-zero time - that I had, in some spots in the code, assumed that any "not coded" frame was just a "packed bitstream marker", without bothering to check for the "zero-time" requirement (even though I was actually aware of this). The currently released beta version does have this bug in a number of spots, causing some functions (like the GSpot's "VGS" display of SMD's file) to display quite erroneously.

But sure, definitely look into it yourself if you're so inclined! - it'll help me make sure I've got this all straight myself.

Ezhihua

15th September 2006, 12:11

I've just released a new GSpot, v2.60 b00 - the first update in almost two years. So far it's kind of a pre-pre-beta, but it may be of particular interest to readers of this forum as many of the new features are of a highly technical nature. See the screenshots at the site to get an idea of what I'm talking about, and I'll be adding new info to the site as time permits.

I'll be checking back here on this thread (or others) for any comments - thanks..

http://www.headbands.com/gspot/

- Steve G

:thanks:

could you release a unicode version?

bond

15th September 2006, 23:19

@bond,

Could you post this stuff (or a reference to it) in one of the faqs?i posted a link to it in the mp4 faq already for a long time

people just really need to read it ;)

stegre

16th September 2006, 06:20

Ahh, indeed, Bond's description (http://forum.doom9.org/showthread.php?s=&threadid=80430) is an excellent post, thanks. I now understand the reasons why they did it.

...as I understand it, historically, somewhere along the line the DivX people decided to occasionally create these "nothing" MPEG frames, and when they do, they stick each one in its own AVI frame... So, having done that... they compensate elsewhere by packing two "real" MPEG frames into one AVI frame It was more the other way around. Packing 2 frames together was done for frame accurate editing of .avi files (with unpacked files there is a 1 frame lag) and the n-vop was added to the end so the final frame (the one packed with the b-vop) could be returned.
Correct, I now see that, having read Bond's post.

...DivX elected to use "packed bit-stream" when generating ASP streams with 1B-VOP was because the frame order in AVI is a compromise ie: generating ASP streams in MP4 offers a slightly different frame order!No, as GodofaGap's answer to your post also was saying in a slightly different way, the MPEG people had already "optimized" the coding order by making it different from the display order. Any info required to display "current" B frame, which requires info from a "future" I or P frame, was solved by actually including that I or P earlier in the file than the time corresponding to when it is to be displayed. And the process works for any number of consecutive B's, not just one. So the AVI file is not in any way "re-ordered" from the MPEG; it's just framed differently.

A not coded P-VOP (N-VOP) means show the last reference frame the codec received. In the case of an N-VOP inserted for packed bitstream reasons, the last reference frame is the P from the P+B packed combo. In the case of your samples, the reference frames are the I-VOPs.

VOPs have timestamps, not durations. N-VOPs inserted for packed bitstream have the same timestamp as the reference frame which replaces them.
Yes, correct too, I referred to them as "zero duration" for simplicity, indeed there is no "zero" to be found, you only "see" zero when you subtract its "timestamp" from an identical "timestamp" on a previous reference frame, as you say.

Though, (just to be argumentative ;) the values in the elementary stream are not exactly "timestamps" either - not in an absolute sense, like an MPEG System Stream has - one where you could look at a frame and say "oh, this is 12 min 57 sec into the file". But you're right, neither are they a relative "duration" for how long to display the frame for, nor are they even a relative duration for "how long to wait from the previous frame before playing this one". It's actually kind of a hybrid - it's normally a "timestamp" for when to play this frame relative to some other "reference" frame, but within a given one second interval only. Associated with it is a "carry value" (almost always "1" when it's not zero). When set to "1", it means you "lap" to a the next second. Then the "timestamp" values are become relative again. So in at least in a sense it's a "relative" ("duration-like") vs. "absolute" ("timestamp-like") system, though I agree your terminology is probably more accurate in this case.

Just to digress a bit, though: what's interesting, is what actually constitutes the "last reference" frame". It's usually the previous "non-B" frame, so unless you have a very slow frame rate or a lot of consecutive B's, this "carry value" mentioned above is usually zero and never exceeds one. But another interesting thing about SMD's "NVOP file" he created is that the timestamp does continue to increase and the carry values do keep going up, to 2, 3, 4 and even higher (even there are no B-frames at all). I assume that the encoder did its job correctly, though I'd like to check into that further.

Since the people who created the MPEG spec expected low values for that filed, almost always zero or one, they encoded it in an unusual fashion which is efficient only for small numbers. The variable length field's value is simply equal to the number of consecutive "1" bits in it until you hit a "0". So the otherwise semi-identical NVOP frames in SMD's file actually get keep getting longer and longer. If it got to say, 31 seconds of continuous N-VOPS without an I frame, that frame would be 4 bytes longer than the first frame. Not that that's a lot, and it's still a great savings overall compared to the same file encoded in a more "normal" way, i.e not using those N-VOPS.

But it's weird using what is at that point a 32 bit field to represent the number between zero and 31, when a normal 32 bit binary encoded field could represent a any number between zero and over 4 billion. But by making the field variable length like that, the field only takes 1 or 2 bits the great majority of the time, so they've obviously thought this all out....

bond

16th September 2006, 08:19

Is the information still fully current. Does any of it require updating/tweaking?yes, the info is still correct and also valid for avc for example

what is missing is what is done when using b-frames as references (as possible in x264) as this needs an even longer time lag as when using "normal" b-frames

SeeMoreDigital

16th September 2006, 10:36

Hi Steve,

I've generated another N-VOP file for your collection. This sample has a bit of motion... and helps to show why N-VOP's are so useful: -

Speaker Mapping File (MPEG-4+6Ch AC3).7z (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/Speaker_Test_File_MPEG-4+6Ch_AC3_in_AVI.7z)

Cheers

unskinnyboy

2nd October 2006, 13:18

v2.60 b00 still indicate the number of AC3 channels wrong. It was a problem with the previous builds too. For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.

One very common and annoying problem with the previous builds was that, on some files, it would report the wrong audio information and then use *that* to calculate the video bitrate, and in the end report wrong video bitrate too. In v2.60 b00, since the video is being demuxed out first, the video bitrate is accurate, so at least that part is OK. Just the audio info is wrong.

SeeMoreDigital

2nd October 2006, 15:06

v2.60 b00 still indicate the number of AC3 channels wrong. It was a problem with the previous builds too. For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.In my experience, previous GSpot builds would report 6Ch AC3 streams as having 5 channels!

I've just used VDM to mux an MPEG-4 video stream together with an 6Ch AC3 stream and got this: -

http://img96.imageshack.us/img96/2571/gspot6chac3testku7.png

Cheers

clsid

2nd October 2006, 15:16

Perhaps it only reports the numbe of channels incorrect in specific situations. If unskinnyboy provides a sample file, then Stegre can try to reproduce and fix the problem.

unskinnyboy

2nd October 2006, 16:24

In my experience, previous GSpot builds would report 6Ch AC3 streams as having 5 channels!
Note that your screenshot says 5.1 and not 5, and that is correct. 6 Channels is also referred to as 5.1, where the 5 stands for the normal-range speaker outputs (RF, C, LF, RR, LR) and the 0.1 for the LFE. So what you see is correct.

Perhaps it only reports the numbe of channels incorrect in specific situations. If unskinnyboy provides a sample file, then Stegre can try to reproduce and fix the problem.
Yes, it happens only with certain files. I will upload a sample later.

SeeMoreDigital

2nd October 2006, 16:41

Note that your screenshot says 5.1 and not 5, and that is correct. 6 Channels is also referred to as 5.1, where the 5 stands for the normal-range speaker outputs (RF, C, LF, RR, LR) and the 0.1 for the LFE. So what you see is correct. Yes... I know it's correct!

I am however, unable to replicate what you are seeing. So as clsid suggests, can you provide a sample?

Cheers

stegre

2nd October 2006, 20:30

Yeah, as unskinny boy says "5.1" is correct and technically more informative than "6" (well, in this particular case, for AC3, "6" would have to mean "5.1", as AC3 only supports 5 "full bandwidth" channels max so a sixth would have to be an LFE (i.e. "Low Frequency Effects" i.e. a "subwoofer" channel). The "5.1" style terminology is not something I made up, btw, it's commonly used by audiophiles and in audio equipment specs.

As you can see in the spec below, "nfchans" ("number of full bandwidth channels") maxes out at 5. For clarity I could change the terminology to say ("6 chnls [5.1.]") or something.

The existence of an extra "LFE" channel can be added to any of the modes below, so there are really 16 different combinations ( at least in theory): any of the eight below with an extra LFE and any of them without one. They treat the LEF channel as a separate entity presumably because it's coded to use less bandwidth than the "full" channels (since there's no need - in fact it's probably undesirable - to encode all the hi-frequency components to send to a subwoofer).

So actually, when I use the "dot" terminology, it's more informative. Note the chart below (where, btw, "S" means "surround" aka "rear": e.g. "SL" is "rear left"). Ignoring the first oddball mode "0", if I said "2" channels it would have to be "L + R". I'd say "2.1" if it were "L, R" plus subwoofer. In the latter case VirtualDubMod, I assume, would say "3", which could mean either L + R (2 full range channels) with one LFE subwoofer channel, or it could also mean either L, R, C or L, R, S (each of those being 3 full range channels).

In fact, even my current terminology doesn't fully specify speaker placement, (my "3" could mean L, R, C or L, R, S) but at least it pares down the combinations in that regard, and in any event always identifies the LFE channel as separate entity, as it is indeed "different" than the other channels.
http://www.headbands.com/gspot/misc_images/ac3.png

stegre

2nd October 2006, 20:36

...For e.g: a file with 6Ch AC3, GSpot says it is 2Ch. VirtualDubMoD reports the channel info correctly.But back to this original question, yes, if it's reporting 2 channels for a "5.1" / 6 chnl AC3 stream that's clearly in error. I was about to post a GSpot update, beta 01, as early as today -- but let me take a quick look at the AC3 handling first. I'll test it on a bunch of files I have here, but it would be great if you could post your testfile as well in case I can't reproduce it. And I admit, I'm already seeing some weird things in a few very quick tests I did in the last few minutes, so there are indeed probably some bugs in that area.
...it would report the wrong audio information and then use *that* to calculate the video bitrate, and in the end report wrong video bitrate too. In v2.60 b00, since the video is being demuxed out first, the video bitrate is accurate, so at least that part is OK. Just the audio info is wrong.
Yes, what you're describing is exactly what I did in earlier versions: In the absence of better info, I'd often use (when I only had the movie's duration, audio bitrate and overall total filesize):

TotalAudioSize = AudioBitrate * Duration
TotalVideoSize = TotalFileSize - TotalAudioSize;
VideoBitRate = TotalVideoSize / Duration

But I'd like to use that only as a last resort in these newer versions. As you say, one disadvantage of the above is that if there IS an error in the audio calc, it gets propagated to the video. It also introduces errors related to container overhead, and possibly significant errors if the container contains additional unidentified streams (though I do account for the simple case multiple audio streams when I do the above calculation).

As I add more capabilities to GSpot internally, my options increase - in fact to list a few, all of which are preferred over the above (though not necessarily in this order):

1) Display VideoBitRate as specified in a container, if available.
2) Display Video Bitrate as specified in a "header" chunk of a video stream demuxed from the container, if available, and if GSpot "understands" the format it's demuxing.
3) Display VideoBitRate calculated after demuxing the entire video stream, counting the bytes, and dividing by the duration (which doesn't necessarily require "understanding" the format of the demuxed video stream).

I have been improving, as you mentioned, and will continue to attempt to improve on using the best method available for each given situation.

unskinnyboy

2nd October 2006, 23:22

Houston, we have a problem. On the whole file (which is a full length encode), GSpot reports 48000Hz 384 kb/s total (2 chnls), but on a sample cut out of it, GSpot says 48000Hz 384 kb/s total (5.1 chnls), the latter being the correct info.

Steve, I don't mind uploading the full file to you if it will help troubleshoot this issue. I will follow up with a PM.

unskinnyboy

9th October 2006, 04:46

Steve, what exactly in the avi are you looking at when you report 'garbage at end'? And why only for OpenDML avis > 2 GB? Would like to hear you out on this. Thanks.

FYI - http://forum.doom9.org/showthread.php?t=116852

stegre

9th October 2006, 06:14

I'll get back to that question and some other stuff about various updates I've made, especially ones related posts in this thread, but I just wanted to quickly mention that I've just posted an update: so here's quick links to the GSpot v2.60 b01 download page (http://www.headbands.com/gspot/v26x/index.html) and the associated list of changes page (http://www.headbands.com/gspot/v26x/b01_updates.html). BTW, regarding representation of AC3 channels (earlier in this thread) I did my "doom9 homework" and found this sticky thread (http://forum.doom9.org/showthread.php?p=332259#post332259) under Doom9's Forum > General > Audio encoding, where the fifth section down, "Basic Parameters", specifically discusses the proper "official" way to represent the number of full range channels, LFE channel, and speaker layout as well - a representation basically backed up the referenced specification document there. So I've adapted the terminology described there in this new version, as mentioned in my update notes (along with a small screenshot).

Anyway, I'll be back - I need a brief rest now ;)

clsid

9th October 2006, 14:03

Great update. Here are my test results and comments:

* Codec & Filter list: 'Set filter merit' should be disabled when you right-click on an ACM or VFW codec.

* I have VMware installed. GSpot will list the file "vmnc.dll" as missing. However the file is present and working correctly. I think something goes wrong when GSpot tries to instanciate the codec (or whatever it does to gather additional info). Let me know if I need to upload the file for you.

* GSpot does not yet recognize the file type of .amr files.

* Missing FourCC: l263 (small L) = Leadtools h264

* FLV file shows compatibility warning "Requires Flash 6+ capable player". Gabest's FLV splitter (SVN rev611 build) is capable of playing FLV files. Both splitting and decoding the FLV1/FLV4 video. So there isn't really a requirement for a special player.

* QuickTime v7 MOV files (containing H.264/AAC) are very similar to regular mp4 files. Perhaps you can add parsing of that specific type of MOV files when you add MP4 parsing.

* I have got a few Matroska files that contain a lot of different audio streams. Opening such a file in GSpot will freeze the system for short while (half a minute or so). After that GSpot will still be unresponsive (with 0% cpu usage), but I regain system control. Sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv).

* GSpot does not yet recognize the file type of .nsv (Nullsoft video).

SeeMoreDigital

9th October 2006, 14:30

Hi Steve,

Great work with the new build...

Nice to see you've included the "MetaData" build information for MPEG-4 streams... Very useful :)

Many thanks for making the VOP information easier to understand too!

I like it mate :D

Cheers

unskinnyboy

17th October 2006, 03:55

stegre

24th October 2006, 06:08

GSpot v2.60 b02 (http://www.headbands.com/gspot/) is available now, with a bunch of fixes (including some stuff I "broke" on the previous version;) and other updates I'll mention here and in more detail on the web page shortly.

BTW, The AC3 still wasn't completely right on even on b01; I found it often erroneously indicated ".1" (LFE) channel even when it wasn't present. I think it should finally be accurate now.

Jekill

25th October 2006, 10:23

Hi Steve, I have to make you a question about two files I've been testing with your latest versions.

The test files I'm dealing with are taken from DivXTest CD of DivXTest.com.
Here are the links to the single downloads:

Multi B-Frame no packed bitstream (http://www.webalice.it/m.dibacco/multi_B-Frame_no_packed_bitstream.avi)
Multi B-Frame with packed bitstream (http://www.webalice.it/m.dibacco/multi_B-Frame_with_packed_bitstream.avi)

In particular, I encountered problems with the recognition of Packed Bitstream.
Reading the "posts" and "links" of this thread, I learned that NVOP should be the clue of Packed Bitstream.

The question is why with GSpot 252 b01.rar and GSpot 260 b00 NVOP is retrieved for both files while, using GSpot 260 b01 and GSpot 260 b02, it isn't detected for no one of them.

Am I wrong or there should be a problem with the files themselves?

The fact is that the two latest betas doesn't detect PB also for another file I created, for which, on the contrary, it was retrieved by the former versions.

Hope I've been useful.
Bye.

SeeMoreDigital

25th October 2006, 10:53

Hi Jekill,

Those particular, 1B-VOP, 2B-VOP and 3B-VOP clips were encoded separately and joined together into one continuous stream afterwards. The same was done with their GMC sample!

Meaning, neither are representitive of what you'll be able to encode yourself!

I recommend you forget about them and not consider using them!

Cheers

Jekill

25th October 2006, 19:47

Ok, thanks a lot, SeeMoreDigital.
I didn't consider that.

Bye.

stegre

26th October 2006, 05:55

Actually, thanks, those files are interesting, regardless of how they were created. I haven't seen those before, and I'm going to take a closer look to decide if I'm reporting everything the way I think I should. It does seem that the NVOP "light" should be on, and I also had, in previous versions, a "Packed Bitstream" message in the container information area. It does seem like those should be present for the one file.

But yes, SMD, is correct in that they are "weird", as they were apparently created by setting the encoder to a certain setting (e.g. "1 B-Frame max"), encoding a segment, then changing the encoder parameters and encoding a different segment, etc, and then appending all the segments together. But there's nothing really "illegal" about doing that or the files themselves (not that I see so far, anyway) so I'm going to convince myself that I'm reporting it all correctly. For example, for a while the files say (and do) have "1 consec B-Frame", then they "2" for a while, and finally "3". And I do report "3 max consecutive B-Frames", which certainly would be the correct value for the file overall.

In fact if you press the "VGS" button on GSpot on those files, it visually shows an areas with one, then two, and then later three consecutive B-Frames (the green rectangles are the B-frames). And it shows occasional vertical blue bars which are "packed bitstream markers" on the file that's supposed to have them (see screenshot below), and not on the other file. So that much seems correct. But I'm not quite sure what's going on in the very beginning of these files, nor am I sure why I'm not displaying NVOP and/or "Packed Bitstream" message in the main dialog for the one file, as you've asked. Whatever's going on in the beginning may be confusing it, oir maybe I've just broken something. So thanks, I'll check into that.

http://www.headbands.com/gspot/v26x/avi_d_frame/images/multi_B-Frame_with_packed_bitstream.avi.vgs.png

PS I've been very busy which is why I haven't even updated my web site as to what's new in the latest version, nor responded to a lot of the previous questions here. Nor have I spent much time checking the app itself much yet ;) But I will do all that, soon as I can.

Jekill

26th October 2006, 08:23

Ok, thanks for the regard.

So, as you explained in first notes of 2.60 version, it's possible to detect PB from vertical blue bars in VGS.
It's a good way and it does work well.
Hope you'll succed in solving NVOP "light" displaying problems.

Glad to be useful.

Bye.

bobbel

28th October 2006, 07:02

Thanks a lot for the update.
It's an amazing app and it makes fun to play with :)

Have a nice weekend!

unskinnyboy

29th October 2006, 00:36

http://img301.imageshack.us/img301/2576/gspotbugwc0.png

"Copy All Lines to Clipboard as Text" doesn't work. I would expect it to copy all the entries under a section, but it copies only the last entry, whichever line I highlight. Under "Container", it copies only the AVI Overheard information and under "Userdata / Metadata", it keeps copying only the [USER] userdata string. Clearly a bug.

Build is v2.60 pß02.

numaios

29th October 2006, 03:30

Thank you very much for this new version!

I've been using GSpot since a long time ago and it is essential to me. And even more now that I can see how many consecutive B-frames there are.

Added: I've analyzed an MP4 file encoded with Nero Recode 2 in AVC profile, with HE-AAC 5.1 audio, and it's reported as "MPEG-4 AAC LC" and "24000Hz 160 kb/s tot (6 chnls)". Maybe it's a problem with the metadata created by Nero Recode?

clsid

29th October 2006, 13:18

I have some suggestions for the tests at the bottom of GSpot:

I think the label "MS A/V" is a bit unclear. Perhaps you could rename it to "Render test".

It would be useful if the render log would display the details of the filters used in the DS graph (below the current info). I know I can hover over the filters to see their filenames. But I think it would be easier if the information was displayed more directly. For example just an enumeration of all filters in the graph with the following info: name, path + filename, clsid and file version. Similar to what the CCCP insurgent tool does.

A 'copy to clipboard' context-menu item would be a handy addition. So that people can post their render logs at forums, etc.

stegre

1st November 2006, 07:33

OK, I'll get back to the above comments/suggestions/bug reports shortly, but:

...The question is why with GSpot 252 b01.rar and GSpot 260 b00 NVOP is retrieved for both files while, using GSpot 260 b01 and GSpot 260 b02, it isn't detected for no one of them....

Jekill is correct that the last version (or two?) had messed up NVOP / "packed bitsream" detection - there's now a b03 version (http://www.headbands.com/gspot/v26x/) which not only fixes but also enhances that whole area (screenshot below). I'll explain more later.

http://www.headbands.com/gspot/v26x/images/pb.gif

Jekill

1st November 2006, 14:40

Hey, first I have to express my gratitude for the shown attention.

Great work.
I've tested your last release and found it really accurate, both in detecting "PB" presence and in distinguishing different packaging methods and frame kinds.

I found it very instructive and I'm sure it'll spread further knowledge, among people, about digital videos several characteristics.

Hi and good job... :)

unskinnyboy

5th November 2006, 01:10

On a Multipart OpenDML AVI 2+ GB, v2.60 pß03 reports wrong length, and hence wrong bitrate, Qf, everything. On the muxed file, where the real length was 02:06:18, GSpot said 1:52:59. I demuxed the video out and things got a bit better - GSpot now said the length was 02:04:15. Close, but no cigar.

In both cases, under the 'Container' info, GSpot says there are a few bytes unneeded junk at end of file. I don't remember seeing that with other 2+ GB files before. I don't have other 2+ GB files available immediately for testing that though. Not sure how I can help you troubleshoot this one, but if needed I can upload the full file to you. Or if you need more info, just ask.

stegre

6th November 2006, 03:09

JarrettH

6th November 2006, 07:37

thanks for updating. i'll switch back now!

numaios

7th November 2006, 01:01

Thanks for the new version :)

Is it possible to fix the AAC profile identification? It reports LC when it's actually HE.

unskinnyboy

7th November 2006, 06:23

OK there's a version b04 (http://www.headbands.com/gspot/v26x/index.html)already, addresses various things in this thread & others, I'll be back to discuss all the prev stuff, and meanwhile anyone please feel free to post comments on old or new stuff. Can't work or even post much myself for the next few days though, gotta get a bunch of stuff finalized in the next few days for next week's "trade show" related to my day job.The issue I reported about the incorrect length in my previous post is gone with ß04. Another thing bugging me though. The video is not being demuxed out for certain files (including the file with which I had the length issue), but for certain others, they are. :confused: The bitrate on the ones not being demuxed/scanned and right away reported are a bit off. Are you caching the values for files previously checked or something?

stegre

7th November 2006, 09:23

The issue I reported about the incorrect length in my previous post is gone with ß04. Another thing bugging me though. The video is not being demuxed out for certain files (including the file with which I had the length issue), but for certain others, they are. :confused: The bitrate on the ones not being demuxed/scanned and right away reported are a bit off. Are you caching the values for files previously checked or something?

I think what's happening is this: Right now, the "main" portion of the GSpot code has no problems with "multi-part" AVI files, but the newer ("demux & scan") related features only scan the first part. This is a temporary limitation; I'll probably have it fixed in the next version. Normally, it wouldn't be much of a problem, as AVI files don't even need a second part until they reach 2GB (though some people say 1GB) in length. When they originally envisioned AVI's, they never thought they'd get that big so didn't really properly allow for it. The "multi-part" format standard was created to combat the limitation. But even now, most files are shorter than 2GB, and even if they aren't GSpot should be able to get a pretty good representation for estimation from scanning the first one or two gigs.

But "Alex", as I think his name is, author of AVIMuxGui, decided a few years ago to depart with tradition (and probably the "spirit, though not the letter" of the AVI format's specification) - and he did it for a rather unusual reason. He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;)

Anyway, off that subject, here's good news: 1) I'm gonna update GSpot to scan all the parts of all multi-part AVI's, regardless of why and how they were made, and, 2) meanwhile, while you're waiting, you can confirm my hypothesis: the two latest GSpot versions now report how many parts there are in any "multi-part" AVI, as well as how may frames are in the first part and how many in the others. So if you're curious, you can confirm that the files you have that aren't getting the "full scan" have a relatively small number of frames in the first part (in which case no doubt you'll also see an "AVIMuxGui" tag in the metadata section!).

Anyway, in other news, believe it or not I just had to release another beta version, beta 05 (http://www.headbands.com/gspot/v26x/index.html), after only two days -- because I inadvertently put in two lines of code that made the beta 4 version "non-Win9x-compliant". And starting getting a bunch of hate mail ;) But there's a couple of other fixes in there too, including much better recognition of which exact version of XviD or DivX encoded a given file, for those who are interested in that kind of thing.

foxyshadis

7th November 2006, 10:27

Ah, so that's why some people I know dislike Avimuxgui so much.

SeeMoreDigital

7th November 2006, 11:33

But "Alex", as I think his name is, author of AVIMuxGui, decided a few years ago to depart with tradition (and probably the "spirit, though not the letter" of the AVI format's specification) - and he did it for a rather unusual reason. He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;) There's some information about this on Alexander Noé's web site: http://www.alexander-noe.com/video/amg/en_faq.php

Cheers

unskinnyboy

7th November 2006, 14:08

meanwhile, while you're waiting, you can confirm my hypothesis: the two latest GSpot versions now report how many parts there are in any "multi-part" AVI, as well as how may frames are in the first part and how many in the others. So if you're curious, you can confirm that the files you have that aren't getting the "full scan" have a relatively small number of frames in the first part (in which case no doubt you'll also see an "AVIMuxGui" tag in the metadata section!).OK, for avis muxed with AVI-Mux GUI, what you said holds true and I understood your theory too. But, your hypothesis is not true, because for my Multipart OpenDML AVI 2+ GB with 2 parts where the first part is 162515 frames and the second is 19178 frames, the file is _not_ being scanned and it was _not_ muxed by AVI-Mux GUI either (it was muxed by VirtualDubMoD 1.5.4.1 b2178).

Regardless of the number of parts there are, or the size of each part, I would suggest that you should demux the entire video and then compute the bitrate and other values. I don't think any amount of guesstimation should be done here. Accuracy is more important here, not the time elapsed.

As for alexnoe, I am OK with what he has been trying to do. He has always been careful never to break the specs, although I do admit that he lives on the edge. If something is not explicitly disallowed in the specs, you can be sure that he'd take a whack at it.

Ah, so that's why some people I know dislike Avimuxgui so much. This is OT for this thread, but alexnoe does provide standalone specific profiles which would allow AVI-Mux GUI to write out the AVIs à la VirtualDubMoD. They should be using that instead of disliking the tool.

stegre

8th November 2006, 03:22

Ah, so that's why some people I know dislike Avimuxgui so much.
...or maybe it has something to do with this dialog I got using it the other day

http://headbands.com/gspot/misc/stupid_user.png

:eek:

But his app does produce good output, has override options, and this is indeed OT....But, your hypothesis is not true, because for my Multipart OpenDML AVI 2+ GB with 2 parts where the first part is 162515 frames and the second is 19178 frames, the file is _not_ being scanned and it was _not_ muxed by AVI-Mux GUI either (it was muxed by VirtualDubMoD 1.5.4.1 b2178).You're absolutely right, I mis-stated my "temporary resolution" above, I just looked and what I did was coded to "not scan at all any AVI that has more than one part"
Regardless of the number of parts there are, or the size of each part, I would suggest that you should demux the entire video and then compute the bitrate and other values. I don't think any amount of guesstimation should be done here. Accuracy is more important here, not the time elapsed.I totally agree, and that's exactly what I'm going to do.

GrofLuigi

9th November 2006, 03:42

Please display the total playing time of the clip at all times, if possibly with big shiny numbers. :)

For me, it is the most important feature of the clip, and I often have to wait for the bitrate scan to finish (which, as we know, can take quite some time - and I don't want to give up on that too). Maybe a separate box if not too hard to implement?

Also, display the total playing time for audio files? I've tried with .wav and .ac3 and GSpot doesn't show it.

Apart from that, it's a very nice program indeed.

Thank you!

GL

stegre

21st November 2006, 05:46

Meanwhile, I do have an update which I've now designated GSpot v2.60 RC01 (http://headbands.com/gspot/). Since the app is now officially recommended by Microsoft in their main WMP 11 FAQ (http://www.microsoft.com/windows/windowsmedia/player/faq/codec.mspx#q14_5), I figured I'd name it something a little less likely to scare off the newbies, so it's no longer a "beta" ;)

Anyway, on a more interesting level, a new feature is the ability bring up the "third party" property sheets (http://headbands.com/gspot/v26x/prop_sheets.html) for DirectShow filters that support them.

SeeMoreDigital

21st November 2006, 10:45

... I figured I'd name it something a little less likely to scare off the newbies, so it's no longer a "beta" ;)So you're hoping the name "GSpot" isn't going to scare them then.... LOL?

Cheers

G_M_C

21st November 2006, 12:11

[...] as AVI files don't even need a second part until they reach 2GB (though some people say 1GB) in length. When they originally envisioned AVI's, they never thought they'd get that big so didn't really properly allow for it.
[...]

That why we have OpenDML AVI's ;) They have absolutely no problem with beeing bigger than 2 Gb's. If i understend correctly they max out fat into the terabyte region ;)

PS: I regulary make AVI's @ 4.660.000 Kb length (== DVD size). For instance a 4 part docu, that I encode into 1 very big file and then split up in its seperate parts. Just to make shure I use every bit that I can on parts that need it ;)

stegre

6th December 2006, 08:28

FYI, I'm updating the MP4 support and to, among other things, show information extracted from "ftyp" values:

http://www.headbands.com/gspot/misc/ftypes.png

which got me sidetracked trying to collect together that information, and ended up making a small website (http://ftyps.com/) myself since the info didn't appear to be collected anywhere else. Not to crosspost, but I described it in a bit greater detail this thread (http://forum.doom9.org/showthread.php?t=119068) in the MP4 forum.

red van man

6th December 2006, 15:50

thanks dude:readrule:

frogman

27th January 2007, 17:32

@Stegre btw thank you for a your great tool.
Question when do you expect gspot to read the new vc-1 and dd plus formats in your proggy! This would help me in the demuxing of vc-1 format or identifing .evo containors.
Ps. I am still new to this process and learning as I go.
Thanking you in advance.

stegre

30th January 2007, 04:58

I'm just got very "involved" in VC-1 in the last week or two, which is actually what has delayed the release referred to above. I'm about to add VC-1 support now - both for "advanced profile VC-1 elementary streams", or VC-1 in a WMV container. In fact I'll be adding support for anything that's inside a WMV - at least in limited form - previously, it didn't even deal with WMV at all beyond simply identifying it as a WMV file. So this is kind of a double update. It's also going to add limited handling for .mov, especially the newer ones which are almost the same as .MP4. As above, previously it only "identified" .mov. files.

I haven't even looked into .evo yet, so the current plan is to release the update with everything mentioned so far, maybe this week. Then I'll move on to the .evo and stuff, not to mention Matroska, which I'm getting a LOT of requests for.

clsid

30th January 2007, 15:06

Great news :)

HeadBangeR77

30th January 2007, 21:47

(...)
(...)

He changed the defaults of his app to make a VERY short first part (like 1 or 10MB - less than 1% of what would be "normal"), and then followed that by additional "full" length parts. He apparently did this to "fake out" Windows XP explorer, to circumvent some Windows bug. I think his goal of changing the traditional format all the AVI's in the world to fix a Windows XP bug is rather like the cart pulling the horse, though I suppose it's more effective than "asking Microsoft to fix it ;)
Finally I've G-spotted (:D) this thread.
First of all, many thanks for your application, which I've been using for long years now. :) I was hoping for some update deep in my heart, and suddenly found a new version, downloaded, and found it very functional.

Secondly, to the matter: it's even worse than described above. The so called "legacy index" (sort of a fake container's header, pointing to AVI 1.0) could be disabled now, as well as practicaly any other option concerning AVI 1.0 & AVI Open-DML. The problem is, it doesn't help at all. The header is smaller, true enough, the file stays however multi-part (or multi-segment, I'd rather say). Disabling rec-list and some other things, leaving (at least in theory) "naked" AVI 2.0 as it should be, makes no difference. The resulting file cannot be scanned by your application or any other I've used so far. I think it's not only me who would be very grateful, if you managed to overcome this problem. ;)

Btw. any chances to look deeper into mkv internals with your utility?

regards,
HDBR77

keys

1st February 2007, 15:36

I've got a question and I hope it's not a dumbass one. Is it possible to introduce the facility to compare two files and determine which has the better picture quality?

Let me explain what I mean and I hope it becomes clearer.

Let's say I have two copies of the same film - both copies with the same bitrate and roughly the same size. However one film has only been re-encoded only once whereas the other film has been re-encoded twice. To the naked eye on the computer screen there probably won't be that much difference and you'd have real trouble deciding which was the better of the two to keep.

How easy or difficult would it be to introduce some sort of comparisson facility? Or indeed does such a thing already exist elsewhere?

HeadBangeR77

1st February 2007, 15:55

How easy or difficult would it be to introduce some sort of comparisson facility? Or indeed does such a thing already exist elsewhere?
You're talking about metrics like PSNR, SSIM etc. G-Spot is an information tool however. If you want to compare e.g. two files with the original, then use MSU Video Quality Measurement Tool - the only downsize I could think of: it's very slow (no optimizations) and runs with high CPU priority thus slowing the other applications incredibly.

Btw. Ctrl+O doesn't work for me with RC-1. Anyone with the same problem?

LotharZ

2nd February 2007, 16:52

Btw. Ctrl+O doesn't work for me with RC-1. Anyone with the same problem?

Yep, I can confirm that problem.

joseph5

2nd February 2007, 21:19

Yep, I can confirm that problem.Me too.

hsoftwaremaster

11th February 2007, 10:39

I like GSpot. Thank you for developing it, free useful.

Bathrone

14th February 2007, 13:02

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

22nd February 2007, 05:50

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

22nd February 2007, 12:27

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

Bathrone

22nd February 2007, 12:50

Awesome, thanks

SeeMoreDigital

22nd February 2007, 13:04

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

22nd February 2007, 14:06

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

SeeMoreDigital

22nd February 2007, 14:43

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

22nd February 2007, 16:09

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

22nd February 2007, 16:12

- 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

23rd February 2007, 04:17

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

23rd February 2007, 12:06

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

23rd February 2007, 13:41

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

24th February 2007, 22:36

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

25th February 2007, 00:02

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

29th March 2007, 05:49

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

29th March 2007, 07:37

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

30th March 2007, 19:25

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

30th March 2007, 20:14

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

30th March 2007, 21:10

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

30th March 2007, 21:44

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

31st March 2007, 04:30

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

31st March 2007, 07:22

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

31st March 2007, 11:06

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

1st April 2007, 18:48

Thanks for GSpot :-)

zambelli

1st April 2007, 21:34

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

2nd April 2007, 04:51

...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

2nd April 2007, 05:00

GrofLuigi

2nd April 2007, 16:59

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

3rd April 2007, 03:42

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

3rd April 2007, 07:00

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

GL

Mtz

3rd April 2007, 10:01

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

3rd May 2008, 15:39

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

13th June 2008, 17:38

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)