Personal View site logo
Official StreamParser topic
  • 95 Replies sorted by
  • @duartix

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

  • 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.
  • Thanks Chris. Excellent as ever and very 'timely'. :-)

  • Thanks Chris...

  • Thanks always Chris! :-)

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

  • @tulpapictures

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

  • 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?

    746 x 412 - 112K
    746 x 412 - 119K
    746 x 412 - 130K
  • 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.

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

  • @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()).

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

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


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

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

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

  • 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?

  • 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

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


  • No problem, thanks for such an excellent tool Chris.

  • @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?

    1296 x 634 - 195K
  • 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.


  • @cbrandin

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

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

  • @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! :-)