Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Enhance the Grid View #72

Open
lars18th opened this issue Jul 31, 2024 · 4 comments
Open

Suggestion: Enhance the Grid View #72

lars18th opened this issue Jul 31, 2024 · 4 comments

Comments

@lars18th
Copy link

Hi @EricBerendsen ,

I have some suggestions for the Grid View:

  • First idea is to grey some pids. Or make them as the background colour. What I want is to see only in colours specific pids (mainly the audio and video pids of one service).
  • The second idea is a method to print the timestamp marks in relation with the packets. For example, you print at the left the timestamp of the first PUSI packet of the LINE, and the line continues with a fixed size, based on some time slace (5,10,20,35,40ms, etc.)

The objective is to use this "view" to check more visualy if the muxing is done correctly.

I hope you want to consider this.
Thank you for this very good project.

@EricBerendsen
Copy link
Owner

Maybe I do not understand your first point, but is this what you want?

image

For this use the View -> Filter option. The selected PIDs and time range of this filter affect the Bitrate, Bar, Grid and PCR/PTS views.

The second point would make it a completely different view. Now the width is flexible, and adapts to the window size. Then the width would be fixed, need to introduce scroll bars, etc.

Also I do not understand why use "the timestamp of the first PUSI packet of the LINE"? What if there are no packets on that line where payload starts? Why not just the timestamp of the first packet of that line?

@lars18th
Copy link
Author

lars18th commented Aug 2, 2024

Hi @EricBerendsen ,

Maybe I do not understand your first point, but is this what you want?

Just that! 👍

For this use the View -> Filter option. The selected PIDs and time range of this filter affect the Bitrate, Bar, Grid and PCR/PTS views.

I don't know about this! Nice! However, some comments about the "Filter option window":

  • We can select multiple pids, but the buttons only move one of the selecteds. This is annoying.
  • When we move a pid, the list number is not reordered. This is annoying too.
  • The option to select all pids of a service will be a must-have. Do you think so?

The second point would make it a completely different view. Now the width is flexible, and adapts to the window size. Then the width would be fixed, need to introduce scroll bars, etc.
Also I do not understand why use "the timestamp of the first PUSI packet of the LINE"? What if there are no packets on that line where payload starts? Why not just the timestamp of the first packet of that line?

After thinking more on it: Yes the idea is to create a new "fixed width table" based on a time scale for each line. And regarding the timestamp, you're right, the best is to print only the calculated PCR based time for the first packet on that line.

Please, think about this idea. Perhaps quite complex to implement it, but it's a good idea... or not?

@lars18th
Copy link
Author

lars18th commented Aug 2, 2024

Hi @EricBerendsen ,

Another different trouble: The "Show Adaptation Filed", "Show Payload Start" and "Show Error Indicator" visualization is not quite visible. I suggest to add another button to "reduce the colour of non-selected packets". The idea is: when you enable Show Payload Start, then all packets of the same pid without the PUSI flag will be painted with a lower colour. The objective is to increase the visibility of the selected packets.

Do you agree with that?

@EricBerendsen
Copy link
Owner

  • We can select multiple pids, but the buttons only move one of the selecteds. This is annoying.
    Thank you, this was a bug in the right panel, left was OK. Fixed in 1.19
  • When we move a pid, the list number is not reordered. This is annoying too.
    Not sure what you mean, if you mean that when you add a PID again it will be inserted at the end; that is on purpose. The list can be re-ordered so the graphs show PIDs in a custom order. The is no natural place to insert a PID.
  • The option to select all pids of a service will be a must-have. Do you think so?

Considered it, but would have all kinds of edge cases when PIDs are share between services (like teletext, PCR). When services share a PID, removing the service would also remove the PCR for other services.

The second point would make it a completely different view. Now the width is flexible, and adapts to the window size. Then the width would be fixed, need to introduce scroll bars, etc.
Also I do not understand why use "the timestamp of the first PUSI packet of the LINE"? What if there are no packets on that line where payload starts? Why not just the timestamp of the first packet of that line?

After thinking more on it: Yes the idea is to create a new "fixed width table" based on a time scale for each line. And regarding the timestamp, you're right, the best is to print only the calculated PCR based time for the first packet on that line.

Just realized, this view is not for a single service, but for the whole stream. So using PCR values does not make sense. Could calculate a time from the start of the stream.

I'll think about this one a bit more

Another different trouble: The "Show Adaptation Filed", "Show Payload Start" and "Show Error Indicator" visualization is not quite visible. I suggest to add another button to "reduce the colour of non-selected packets". The idea is: when you enable Show Payload Start, then all packets of the same pid without the PUSI flag will be painted with a lower colour. The objective is to increase the visibility of the selected packets.

Then packets with the same PID would have different colours, depending on adaptation field and/or Payload start. Bit confusing I think. If the markers are difficult to see select a different zoom level, so the boxes are larger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants