Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    shashi bhushan
    @shashi12533
    hello mentor
    i want to implement this idea
    plzz provide all details regarding this
    is anyone here
    Cristóbal Medina López
    @cristobalmedinalopez
    Hi @shashi12533! I'm here.
    Currently the splitter divides the stream in several chunks with a fixed size. We think that a good idea is to split the stream matching it with the native block of the video (for example, in H.264 exist NAL units, in Theora there are pages, etc)
    Jakub Golinowski
    @Jakub-Golinowski

    Good afternoon,

    I am Computer Science student at ETH Zürich in the 2nd semester of my Master of Science Programme. I already have programming experience from working in industry and on many academic projects throughout my studies. However, I have never engaged in the development of the open source software. Therefore, GSoC is the unparalleled opportunity for me to fully emerge in the open source community and gain knowledge necessary to continue open source contributions after the end of the programme.

    Both my experience gained at university and in the industry (1 year of C++ embedded development) are mostly focused on using C++ to solve different problems. I would like to further improve in using this language while working on the MediaAware-Splitter project. The end-result of the project seems pretty clear on the high level – use native video chunks in order to decrease overall video chunk loss rate (when a constant p2psp chunk loss is assumed). Another words make sure that only as many video chunks are lost as p2psp chunks. However, I am aware that introducing a simple functionalities often require considerable amount of work.

    While working on my proposal I noticed that the link in the project description (https://github.com/P2PSP/p2psp) is inactive. However, I believe that the core of the splitter is described in this header file: https://github.com/P2PSP/core/blob/68fcab5df9c83ec63e828211a5a3f0d19c333a73/src/core/splitter_core.h

    After going through the protocol description I understood that there are different policies for splitter to distribute chunks to peers depending on the situation (IMP, DBS, ...). However, this project is about adding the functionality of using the adaptive chunk size, therefore I assume that the changes need to be introduced only to the core spiller class and all the derived class will automatically use the right chunk size.

    Also I have a question about the following feature of the protocol: “P2PSP is not aware of the broadcasted content, the bit-rate, the format, etc. Any type of stream can be transmitted without having to modify the protocol at all.” - so I assume that adjusting the size of the p2psp chunk to the video format chunk is only a form of optimization, as opposed to a change of core assumptions of the protocol? Moreover above mentioned feature of p2psp suggests that the type of video format is not generally known to the splitter. So the follow-up question is how should splitter obtain this information?

    Sincerely,

    Jakub Golinowski

    Jakub Golinowski
    @Jakub-Golinowski
    Also I would like to ask what is meant by this sentence: "The incorporation of such functionality should be provided as a "pluging"."
    Cristóbal Medina López
    @cristobalmedinalopez
    Hi @Jakub-Golinowski Welcome to the P2PSP project! In the current implementation of the protocol it is not aware of the broadcasted content. However, We would like to experiment what happen if it does is. Maybe the reference to "provided as a plugin" means that since it will depend on the specific format of the transmission, woulde be useful to add this feature as a extra feature instead of as a modification of the core code. But probably @vicente-gonzalez-ruiz knows more about this topic.
    Jakub Golinowski
    @Jakub-Golinowski
    @cristobalmedinalopez thank you for your answer. I hope to hear from @vicente-gonzalez-ruiz today or tomorrow morning :smile:
    I am working on my proposal for this project and I was wondering if you have a data base of video formats or something in this direction?
    Jakub Golinowski
    @Jakub-Golinowski
    Also I have shared the final draft of my proposal through official GSOC page
    Cristóbal Medina López
    @cristobalmedinalopez
    Ok, Thanks!
    Jakub Golinowski
    @Jakub-Golinowski
    @cristobalmedinalopez @vicente-gonzalez-ruiz if you have any comments regarding my proposal please do not hesitate to share them with me.
    Cristóbal Medina López
    @cristobalmedinalopez
    @Jakub-Golinowski Maybe it could be a good idea to think about a non-fixed chunk size. I mean, What happen if the size of the chunks is changing during the transmission? What would it depend on?
    On the other hand, regarding video formats, what about MPEG TS? https://en.wikipedia.org/wiki/MPEG_transport_stream
    Jakub Golinowski
    @Jakub-Golinowski
    you mean changing the chunk size send by the splitter? So of course if the type of the video format changes then we should change the size of the block. In case of streaming the same video format, the size of the block might depend on the type of the network in which we distribute packets and the policy in which splitter is currently operating.
    @cristobalmedinalopez Also I have a question: is it possible to change the quality of the stream? If so then I beliebe the size of the chunk should change respectively?
    Cristóbal Medina López
    @cristobalmedinalopez
    All these questions come up new if we taking into account what is transmitted. Interesting! :)
    Jakub Golinowski
    @Jakub-Golinowski
    @cristobalmedinalopez with MPEG TS we wrap many different streams into one stream - so by asking what about MPEG TS you are asking what should be the proper logic for computing out splitter chunks size when we are dealing with a stream that is encapsulating substreams?
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Hi all (and apologizes by my delayed interaction ...). @Jakub-Golinowski, welcome. Yes, a media aware splitter basically should encapsulate a video packet in a different chunk and if the video is VBR (not CBR), the chunks can have different lenghts. This is something that only affects to the splitter, as the peers can keep the current logic simply taking into consideration this improvement.
    @Jakub-Golinowski, the most important design aspect when dealing with streams (or substreams) is that if a chunk is lost, this should not affect to those data that could have been received successfully.
    Jakub Golinowski
    @Jakub-Golinowski
    @vicente-gonzalez-ruiz thank you for your answer and confiriming that variable bit rate of the video implies variable size of the chunk created by splitter.
    And thank you for stating what is the most important in the whole project, namely isolation between successfully received data and unsuccessfully received data. This must be then the main design goal while designing the logic of choosing appropriate splitte's chunk size.
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    :+1: