Official StreamParser topic

cbrandin

Thanks for the bug report! I'll fix it with the next StreamParser version.

cbrandin

StreamParser 2.7 is now available. There were some bug fixes. The main new thing is that the way time stamps are calculated and reported has been significantly upgraded. Panasonic uses a "trick" mode where TS time stamps are changed around. Although not perfect, the way StreamParser calculates has been improved and should be correct in all but the most extreme cases.

driftwood

Thanks Chris. Excellent as ever and very 'timely'. :-)

vladnik

Thanks Chris...

bkmcwd

Thanks always Chris! :-)

tulpapictures

Man, I wish I could could get this onto a Mac somehow, without creating a Windows partition...

towi

@tulpapictures

I run Windows XP Pro through "vmware fusion" on Mac. Works pretty good. No need to create a Windows partitition...

http://www.vmware.com/products/fusion/overview.html

mozes

i am playing with the quantizer tables, and have strange image with it in StreamParser.
i have done it willful underexposed, so i can clearly see what is going on in the picture itself.
But what does that white blocks exactly mean?

cbrandin

I think the white blocks are an artifact of your display. I suspect that if you expand the graph to include fewer frames they will go away.

mozes

Oké thx.... i dont have the files anymore to check, but it never happens before, because i did use very wrong quantizer tables to see what happens, i was thinking it was related.
it only showed up where the bitrate in the clip was on its lowest, and exactly there, i had a lot of macro-blocks/smearing in the dark gray parts of the video.

_gl

@cbrandin, Chris did you see my ealier comment (March 5)?:

One thing, can you avoid writing the .YUV file when decoding via JM, or make it optional (disabled by default)? This contains uncompressed frames and takes a lot of disk space & time to write, especially for longer frame counts. It's not actually used in the analysis right?

2.7 still writes the .YUV file (and onto my SSD system partition which is strapped for space). Should be easy to avoid, just comment out the line in the JM code that actually commits the YUV data to disk (I guess either WriteFile() or fwrite()).

_gl

... also just noticed that SP doesn't clean up the temporary files for JM analysis (elementary streams and .YUV file) when it exits. Would be nice if it could.

cbrandin

I just tested it and version 2.7 does not write YUV files. It does write 264 and AC3 files when you create elementary streams, and log files. I chose not to erase them because they are useful for editing (they're faster) and analysis with other programs (analyzers, such as StreamEye run much better against elementary streams).

Chris

_gl

It does write the .YUV file, but in a different place, here it's:

"(system drive):\Users(user)\AppData\Local\Apps\2.0\DBQZB6RC.XCT\09LG6O3R.JBR\gh13..tion_0000000000000000_0002.000b_cc62a4c6cec700dd\test_dec.yuv"

(same folder that holds the ldecod*.exe files)

re. auto-erasing files, it would be nice to have that as an option as I don't use other analyzers - but it's no big deal.

_gl

... actually there's an easier solution to avoid the YUV file - in that directory, decoder.cfg -> change OutputFile to "".

cbrandin

Wow, that's strange. I get none of that on my system. I think something may have gone wrong with the installation. Try uninstalling and then re-installing.

_gl

Already did as you have to uninstall to upgrade, but just tried again, removing all leftover files & directories manually afterwards. Exactly the same.

The included decoder.cfg still specifies the test_dec.yuv file, so it's still generated in that folder. You've got to be seeing the same thing?

_gl

To be clear, there are two folders which hold ldecod files, but only one seems to be used when analysing:

used (more files): C:\Users(user)\AppData\Local\Apps\2.0\DBQZB6RC.XCT\09LG6O3R.JBR\gh13..tion_0000000000000000_0002.000b_126fa5fd42e0eb1d

not used (fewer files): C:\Users(user)\AppData\Local\Apps\2.0\DBQZB6RC.XCT\09LG6O3R.JBR\gh13...exe_0000000000000000_0002.000b_none_b11aa7a544a41d01

cbrandin

I tested this on a couple of different systems. You're right - on one system it did what you described - on the other it didn't. Strange...

The command line processor is supposed to override the config settings, but sometimes it doesn't. If you remove the file names (make them ""), it fixes this.

Thanks so much for the information. I'll update the program. In the meantime, just set the file names in the config file as "".

Again, thanks for drilling this down.

Chris

_gl

No problem, thanks for such an excellent tool Chris.

bkmcwd

@cbrandin

Hi Chris, It appears in StreamParser that I am worrisome these days. Although it is what did not occur at all in the previous version, in the latest version, the value of "Average Video Bitrate" often exceeds "Average Overall Bitrate." Would you teach this cause, since it is not considered by me for my latest settings to be the factor?

cbrandin

It's because the clip is very short. The video bitrate is calculated using the number of frames. The overall bitrate is calculated using the bits sent over the total time. When the clip is short the little bit of overhead at the beginning skews the numbers - this is normal.

Chris

Vitaliy_Kiselev

@cbrandin

May be it is good idea to add warning icon with short notice in this case?

cbrandin

I guess I need to clarify. The Overall bitrate is based on TS Duration (5.691 in your example) and the video bitrate is based on Clip Duration (5.547). There isn't anything to warn about - this is correct.

bkmcwd

@cbrandin

Thanks for the info, Chris. I have adjusted so that 2 kinds of Duration times may become as the same as possible, but with too short the clip, surely, the relative difference becomes large. I got it! :-)

Howdy, Stranger!

Categories

Tags in Topic

Top Posters