AVCHD analysing tools
- Thread starter Vitaliy Kiselev
- Start date
Here is version H of GH13StreamParser. The main addition is an embedded video player. Other small additions were made as well.
I used Microsoft's media player control to do this. It has some limitations. The player always starts at frame 1 (not 0). Also, it can't play the entire clip in the mode I am using it (where I sync it with the rest of the windows); it will play up to the last couple of seconds or so. The stepping can only go forward, not in reverse. I can't automatically determine if a PAL 1080/25p clip is native or not, so when you start the Stream Player it will ask; other modes I was able to detect. I put quite a lot of effort into making it frame accurate - I hope it holds up.
I'm not sure which codecs this expects you to have installed so your results may vary. I tested this on Windows 7.
I've added a couple of pictures here so you can see what it does.
Enjoy!
Chris
I used Microsoft's media player control to do this. It has some limitations. The player always starts at frame 1 (not 0). Also, it can't play the entire clip in the mode I am using it (where I sync it with the rest of the windows); it will play up to the last couple of seconds or so. The stepping can only go forward, not in reverse. I can't automatically determine if a PAL 1080/25p clip is native or not, so when you start the Stream Player it will ask; other modes I was able to detect. I put quite a lot of effort into making it frame accurate - I hope it holds up.
I'm not sure which codecs this expects you to have installed so your results may vary. I tested this on Windows 7.
I've added a couple of pictures here so you can see what it does.
Enjoy!
Chris
Attachments
Nice work, Chris. Playback works fine on Win XP with DivX codec installed. Although this computer is a bit slow for real-time PB, but that's another matter
Vitaliy Kiselev
Carbonite Member
May be try ffmpeg library?
Btw, any news on native code version?
P.S. Please keep up good work and improving your utility!
Vitaliy Kiselev
Carbonite Member
If I were planning to make this a commercial program I might do that. I just wrote this to help with testing, I never intended to turn it into a product. By using C# I was able to put it together very quickly. I think I just can't devote that much time to this (I do have a day job) ;-)
I tried other free 264 codecs and they all exhibit pretty much the same limitations as Microsoft's when it comes to stepping etc...
At this point I don't have plans to add much more. I might add a feature where corrupted files can be fixed (i.e. the corrupted stuff removed) so that they don't make editors crash. Otherwise I'm going to go back to testing AVCHD parameters for now.
Chris
I tried other free 264 codecs and they all exhibit pretty much the same limitations as Microsoft's when it comes to stepping etc...
At this point I don't have plans to add much more. I might add a feature where corrupted files can be fixed (i.e. the corrupted stuff removed) so that they don't make editors crash. Otherwise I'm going to go back to testing AVCHD parameters for now.
Chris
Last edited:
Here's version J of StreamParser. All I did was add an option to create a cleaned copy of a corrupted file when you run the Tools > Check Stream File function and it has detected that the file is corrupted. It determines where the last valid complete frame ends and discards the rest of the file. I checked it with a few test files I have and the cleaned versions seemed well behaved.
Chris
Chris
Chris, I see that you added frame rate calculations which worked for all 3 typical formats (24P, 24P/60i, 60p) I tested. Would it be possible to display more precise result? I don't know which method you are using, but this is a manual one I found useful.
Vitaliy Kiselev
Carbonite Member
I am going to open up IDA database part concerning AVCHD soon.
I hope it'll be interesting for you.
Progress can be much better.
We have many tables concerning compression and bitrate and I hope soon we'll have same control as in MJPEG part.
Unfortunately I can't get the actual tick values - that's buried in the AVC codec and I haven't drilled down that far. I looked at the spec and getting that kind of information would be a monumental undertaking - basically, I would have to write a codec.
I'm using standard time values (23.97642318 fps, etc...) for my time calculations, so I guess in Native mode I might be a tiny bit off. I'm not sure if I should change it or not because I'm not sure how editors do it. Do they just abandon the HH:MM:SS:FF notation or do they skew actual timing to make it fit?
Chris
I'm using standard time values (23.97642318 fps, etc...) for my time calculations, so I guess in Native mode I might be a tiny bit off. I'm not sure if I should change it or not because I'm not sure how editors do it. Do they just abandon the HH:MM:SS:FF notation or do they skew actual timing to make it fit?
Chris
Vitaliy,
Sure, I'll play! I would really like to get a look at their buffering schemes. I noticed that the Native p files that I have that didn't come out right all look like they have buffer overrun problems (i.e. completely invalid packets). They arent even rolled over video, audio, or any other kind of valid packet - they are just unrecognizable junk with no hint of correct signatures anywhere in them - that is, they don't contain valid signatures even in the wrong locations.
Chris
Sure, I'll play! I would really like to get a look at their buffering schemes. I noticed that the Native p files that I have that didn't come out right all look like they have buffer overrun problems (i.e. completely invalid packets). They arent even rolled over video, audio, or any other kind of valid packet - they are just unrecognizable junk with no hint of correct signatures anywhere in them - that is, they don't contain valid signatures even in the wrong locations.
Chris
Vitaliy,
Here are a couple of corrupted files. The one with the bad GOP passes all tests but has the wrong GOP length in one case. Whatever happened probably happened before the stream was packetized. The other is just plain corrupt and it probably happened when the stream was being packetized or being unloaded to flash. If you look at it with the Stream Parser's Check Stream File function and look at the addresses it shows as corrupt with a hex editor you'll see what I mean by junk packets.
Both files were produced with Native 24p checked and with overall bitrate set too low.
Chris
OOPS they are too big - If you want I'll send them to you some other way - just let me know how.
Here are a couple of corrupted files. The one with the bad GOP passes all tests but has the wrong GOP length in one case. Whatever happened probably happened before the stream was packetized. The other is just plain corrupt and it probably happened when the stream was being packetized or being unloaded to flash. If you look at it with the Stream Parser's Check Stream File function and look at the addresses it shows as corrupt with a hex editor you'll see what I mean by junk packets.
Both files were produced with Native 24p checked and with overall bitrate set too low.
Chris
OOPS they are too big - If you want I'll send them to you some other way - just let me know how.
Last edited:
Stream Parser bug fixes
Stream Parser bug fixes
Attached is GH13 Stream Parser version 1.0K. A few bugs were fixed:
In some cases the frame indicated could be off by one frame - fixed.
With some codecs audio noise was produced - fixed.
In some cases when the Stream Player was re-docked after having been detached the window size was wrong - fixed.
Chris
Stream Parser bug fixes
Attached is GH13 Stream Parser version 1.0K. A few bugs were fixed:
In some cases the frame indicated could be off by one frame - fixed.
With some codecs audio noise was produced - fixed.
In some cases when the Stream Player was re-docked after having been detached the window size was wrong - fixed.
Chris
Cbrandin
I'm not sure I completely understand what you mean by 'editors' so excuse me if I'm off base, but normally timecode discrepancies are handled through drop-frame timecode. So every few minutes, the editor will 'drop' a timecode value, it does not affect playback, and no actual frames are dropped. HTH
I'm not sure I completely understand what you mean by 'editors' so excuse me if I'm off base, but normally timecode discrepancies are handled through drop-frame timecode. So every few minutes, the editor will 'drop' a timecode value, it does not affect playback, and no actual frames are dropped. HTH
New version of StreamParser available here: http://www.dvxuser.com/V6/showpost.php?p=2113515&postcount=1.
Chris
Chris