Page 11 of 22 FirstFirst ... 78910111213141521 ... LastLast
Results 101 to 110 of 220
  1. Collapse Details
    Default
    Ok, so if I understand you correctly there are no rogue frames in stream, but there are anomalies nevertheless? Could you please explain the nature of these anomalies?


     

  2. Collapse Details
    Default
    Started looking into the MTS a bit deeper with http://www.bitstreamtools.com and have come to the conclusion, the rogues do not exist. I'm unsure if the fact that PAT/PMT tables show up in the middle of slice data as DaLiv suggests is the reason StreamEyes can't handle it... but unfortunately this is a bug imho. Frame counts are incorrect in StreamEye when there are "rogue" frames, meanwhile nearly any application that can playback MTS will give you a correct count. Rogues are StreamEyes combining frames for a GOP into a single P/I frame. It could be as simple a DaLiV suggests. If you look at my MTS file, you'll see the GOP # change with each rogue I Frame. If you multiply the number of rogues by 12 (size of the GOP for 24P), you will account for the number missing frames. Beyond that, the actual data in the MTS files are valid, and the link for TSPacket Editor above demonstrates that I frames and P frames are properly layed out according to GOP.

    (I hope I made sense.. lol, need sleep)


     

  3. Collapse Details
    Default
    This is main reason why I wanted to use something beside StreamEye, as it is generally very buggy thing.


     

  4. Collapse Details
    Senior Member
    Join Date
    Jun 2010
    Location
    Latvia
    Posts
    168
    Default
    Vitaliy Kiselev : take a look to product near streameye ...
    http://www.elecard.com/products/prod...ream-analyzer/
    seems that tool more adequate then streameye (screen show packet analyzing inclusive of internal structures of each frame of transport stream) .


    have tested on previous files = H.264 supported, structure shown correctly (each packet structure, address in stream and size may be easyly got, not more need manual searches )
    Last edited by DaLiV; 07-20-2010 at 06:44 AM. Reason: tool tested = ok


     

  5. Collapse Details
    Default
    That's too bad ... I was just beginning to like StreamEye; it's nice to see a graphical representation of the stream. Stream Info panel is generally spot on as well (well max bitrate is incorrect as we know now).

    FWIW, their StreamEye Pro product is afflicted with the same bug (see attached screenshot). Perhaps someone with sufficient knowledge of the problem can report it to them. Who knows, maybe they'll be willing to beta test their development stuff with this project ;)
    Attached Images Attached Images


     

  6. Collapse Details
    Default
    Can we move back to writing our own small analyser?


     

  7. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    I've been working on a utility that parses streams. All I've done so far is look at the TS headers, which can be used to identify frames. The streams are broken up into 192 byte packets with a 8 byte header where the first 4 bytes are a sequence counter, the next 3.5 bytes identify packet type, and the remaining nibble is simply a counter. For example, you might see an 8 byte value at the beginning that is 07 F5 54 20 47 10 11 1A. The first 4 bytes (07F55420) are simply a counter that increments by 2F0 with each frame (in this example). The second 4 bytes (4710111x ) appear to indicate packet type, except that the "x" simply cycles with each packet. Frame starts have a value of 47 50 11 1x This is where StreamEye starts each frame (offset). The length they report is simply the distance to the next starting packet, which is the next packet that has 47 50 11 1x in bytes 4-7 of the header.

    This means a couple of things: The frames are not just video, they can also contain audio. If there is some kind of other data in these packets Streameye is not differentiating it, it just considers everything a video frame. The rogue frames could be anything.

    There are several kinds of packets I've seen with different values in bytes 4-7 of the headers, but I haven't figured them all out yet.

    The empty frames I've found seem to appear in the "black" tests, but not otherwise. When they do appear they have a code of 47 10 11 1x, which is also the most common type of packet for legitimate video data.

    In order to differentiate frame type a deeper drill-down is necessary. I'm working on this. Pretty soon we should have a little utility that does what the StreamEye chart does, except that it will differentiate audio, video, empty frames, etc... I don't plan to do any of the fancy video stuff, though - that would take too long. Hopefully, I'll have a rough version available in a couple of days.

    Chris
    Last edited by cbrandin; 07-20-2010 at 10:18 AM.


     

  8. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    I'm also putting a feature in that dumps analysis metadata and other stuff into a CSV file for use with a spreadsheet.

    Chris


     

  9. Collapse Details
    Default
    We don't want any video stuff, in fact.
    All we want is understand that this is in low level.
    You can look at any available TS demuxer sources.

    P.S. I suggest you to look for Hex viewer components for C#, They must be easy to integrate.
    Something like simple grid and HexView upon click on the row.


     

  10. Collapse Details
    Senior Member
    Join Date
    Aug 2006
    Location
    Colorado Springs
    Posts
    473
    Default
    Yeah, I'm looking for widgets now. The hex stuff is easy, I've already done that. Now I'm looking for a simple, free, barchart widget. I want one that can do stacked bars so I can show headers, video, audio, other, and empty packets in a bar that represents one frame.

    Using the simple parsing method I described above I've already gotten the results shown in the first attachment below. Obviously, I haven't put the other data in yet. The offsets and frame sizes are exactly the same as what StreamEye reports (see second attachment). Note the big frame at frame 24 - it is a rogue as it contains null data packets (this was a 24pN black test).

    Chris
    Attached Images Attached Images


     

Page 11 of 22 FirstFirst ... 78910111213141521 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •