{"action":"created","issue":{"url":"https://api.github.com/repos/tsduck/tsduck/issues/187","repository_url":"https://api.github.com/repos/tsduck/tsduck","labels_url":"https://api.github.com/repos/tsduck/tsduck/issues/187/labels{/name}","comments_url":"https://api.github.com/repos/tsduck/tsduck/issues/187/comments","events_url":"https://api.github.com/repos/tsduck/tsduck/issues/187/events","html_url":"https://github.com/tsduck/tsduck/issues/187","id":394980576,"node_id":"MDU6SXNzdWUzOTQ5ODA1NzY=","number":187,"title":"Idea: New plugin \"mpts-optimizer\"","user":{"login":"lars18th","id":9989964,"node_id":"MDQ6VXNlcjk5ODk5NjQ=","avatar_url":"https://avatars1.githubusercontent.com/u/9989964?v=4","gravatar_id":"","url":"https://api.github.com/users/lars18th","html_url":"https://github.com/lars18th","followers_url":"https://api.github.com/users/lars18th/followers","following_url":"https://api.github.com/users/lars18th/following{/other_user}","gists_url":"https://api.github.com/users/lars18th/gists{/gist_id}","starred_url":"https://api.github.com/users/lars18th/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars18th/subscriptions","organizations_url":"https://api.github.com/users/lars18th/orgs","repos_url":"https://api.github.com/users/lars18th/repos","events_url":"https://api.github.com/users/lars18th/events{/privacy}","received_events_url":"https://api.github.com/users/lars18th/received_events","type":"User","site_admin":false},"labels":[{"id":631116034,"node_id":"MDU6TGFiZWw2MzExMTYwMzQ=","url":"https://api.github.com/repos/tsduck/tsduck/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-12-31T13:27:18Z","updated_at":"2019-01-04T17:57:12Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Hi,\r\n\r\nI have a new idea/suggestion to improve the muxing capabilities of the TSDuck.\r\n\r\nI understand that TSDuck isn’t a professional muxer. However, at time, it’s the most complete software tool in the opensource area to create MPTS streams. And for this reason I feel that any enhancement will be a significant improvement for us. So, only for this reason I write here my ideas about it. I hope you don’t think they’re stupid and/or crazy.\r\n \r\nRegarding the current implementation of the `merge` plugin, it does the work as expected. But two issues are still present regarding the “muxing” output:\r\n\r\n- PCR restamping: Only PCRs from the merged stream can be restamped. So, the resulting MPTS can have incorrect PCR marks in some cases.\r\n- PID distribution: The current algorithm writes adjacent consecutive packets. The result is then a MPTS without sufficient dispersion of the different services. To understand what I mean, look at these two examples:\r\n\r\nThis first image is the “Grid View” from DVB Inspector of a regular DVB MPTS broadcasted over a terrestrial network:\r\n\r\n![mpts-dvb](https://user-images.githubusercontent.com/9989964/50561113-97885980-0cff-11e9-8ab3-91aa2b8fe9b8.png)\r\n\r\nAnd this is the same view from a similar MPTS created using TSDuck:\r\n\r\n![mpts-tsduck](https://user-images.githubusercontent.com/9989964/50561116-a111c180-0cff-11e9-8bd8-7e0c59a9ddec.png)\r\n\r\nI’m sure you can see the difference!\r\n\r\nSo, here my suggestion about a new `mpts-optimizer` plugin:\r\n\r\n- This plugin will process DVB MPTS streams with a CBR.\r\n- The first task can be to restamp all PCR based on the different services present in the MPTS.\r\n- Another task could be to dispersate (aka obfuscate) packets from different pids. One simple strategy can be: for packets of the same pid between two PCR marks, not move any packet with a PCR mark, but for the reset try to relocate to another position. With the restriction of maximize the distance between consecutive packets. And this will be done for all pids.\r\n- Furthermore, a final task can be to check the conformance of the MPTS, and especially for the bitrate of the resulting stream.\r\n\r\nWhat you think about this idea?\r\n"},"comment":{"url":"https://api.github.com/repos/tsduck/tsduck/issues/comments/451519114","html_url":"https://github.com/tsduck/tsduck/issues/187#issuecomment-451519114","issue_url":"https://api.github.com/repos/tsduck/tsduck/issues/187","id":451519114,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTUxOTExNA==","user":{"login":"lars18th","id":9989964,"node_id":"MDQ6VXNlcjk5ODk5NjQ=","avatar_url":"https://avatars1.githubusercontent.com/u/9989964?v=4","gravatar_id":"","url":"https://api.github.com/users/lars18th","html_url":"https://github.com/lars18th","followers_url":"https://api.github.com/users/lars18th/followers","following_url":"https://api.github.com/users/lars18th/following{/other_user}","gists_url":"https://api.github.com/users/lars18th/gists{/gist_id}","starred_url":"https://api.github.com/users/lars18th/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars18th/subscriptions","organizations_url":"https://api.github.com/users/lars18th/orgs","repos_url":"https://api.github.com/users/lars18th/repos","events_url":"https://api.github.com/users/lars18th/events{/privacy}","received_events_url":"https://api.github.com/users/lars18th/received_events","type":"User","site_admin":false},"created_at":"2019-01-04T17:57:12Z","updated_at":"2019-01-04T17:57:12Z","author_association":"CONTRIBUTOR","body":"> A plugin does not have a global view of the packet buffer and consequently cannot reorder packets. \r\n\r\nHi @lelegard ,\r\n\r\nPerhaps some FIFO strategy can solve the problem for a very particular case (not as regular behaviour, as it has severy overhead penalties):\r\n\r\n- To reorder packets, the plugin can use an internal FIFO. At start it copies new incoming packets to the FIFO, and for each packet it frees the packet to a NULL. Then when the FIFO is full, it can start to processes in this way: for each incoming packet, copy it to the FIFO and replace it with the top in the FIFO. With this solution you can do _any_ processing in the internal FIFO in each loop.\r\n- The drawbacks are relevant: non copy-on-write, more memory required, and added delay because the internal buffer.\r\n\r\nI'm not sure if you accept to include such type of plugins, as I feel you prefer to maintain TSDuck completely away from multiple buffer copies.\r\n\r\nThese are just my five cents!"}}
{"actor":{"display_login":"lars18th"}}