GSpot v2.60 b00

[stegre]

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

[feedback]

Thanks for the update! I look forward to when it is only in the Beta phase...without the pre. pre.:D

Regards,

P.S. Where have you been...on a world cruise or something.:)

[unskinnyboy]

Awesome! Didn't think I would see another version in my lifetime! Also read about your illness in the development notes - glad to know that you are OK now.

The new version looks cool! I must say you have managed to scan the input stream faster than MPEG4 Modifier/MPEG4Toolkit to report the frame types. I compared reports between GSpot and MPEG4Modifier and confirmed the correctness of the report, even though you are rounding off the percentages. VGS is very eye-catchy too.

My only gripe is how you wait till the whole stream is scanned before you report the final values for 'Len' and 'Frms'. Can I ask why, considering the previous GSpot was reporting those values correctly and instantaneously?

Good job and a much awaited update, thanks!

[stegre]

Thanks guys. Yeah, for the next long delay, I think I'm gonna go with world cruise idea ;)

I'm glad about the speed; I didn't do any comparisons myself but did spend a bit of effort to optimize the speed of the scan, so looks like maybe it paid off a bit. The question about the instantaneous vs. "post-scan" results on frame count and time actually brings up some very interesting topics (involving "stream frame count" vs "container frame count") - I'll post more about later tonight if I get a chance (I'm at work now). But that's a good point, for most filetypes I probably can and will go back to displaying those values immediately, as you're suggesting.

[SeeMoreDigital]

Many thanks indeed for the new version Steve... The new functionality looks great ;)

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

[clsid]

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]

WOW, This is great, many thanks.

[masken]

indeed nice work steve!

[lolent]

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

[stegre]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Lovely :)

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

[SeeMoreDigital]

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]

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]

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]

Will GSpot ever handle DVD's?

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

[SeeMoreDigital]

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]

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]

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]

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]

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]

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]

@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]

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

[masken]

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]

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]

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]

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]

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]

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]

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!

[squid_80]

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]

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]

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]

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

[Wilbert]

@bond,

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

[SeeMoreDigital]

@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]

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]

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]

@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]

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]

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]

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