[FFmpeg-devel] nut-np (was: Re: [PATCH] Only output necessary NAL units in H.264 extradata in SDP)

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
> the idea pretty much was to send nut packets, because there is significant
> overlap between a container format for files and a network protocol
> handling the same data. (timestamps, metadata, error recovery, seperating
> packets, seperating streams, ...)
Sorry for the delayed reply. No, I did not forget about this... I just
wanted to think about it for some time before writing, because I realise
that I am too much RTP-biased, so I did not want to write my immediate
reactions.

Anyway, I agree about the overlap, and I agree that using the format header
as a part of the protocol header is a good idea.

> The differences pretty much are AFAICS down to
> * telling the server to seek somewhere
So, you propose to mix the "media transport" functionalities with the
"control" functionalities (instead of separating them in two different
protocols like RTP and RTSP)... Initially, I was not sure this is a good
idea. But double thinking about it maybe it is ok.


> * acknowledge & retransmitt if the underlaying protocol does not gurantee
>   delivery (UDP)
As above, I initially did not like this. But now I think this is ok; my only
concern is that this mechanism should not be mandatory (it should be possible
to somehow disable it)... Think about multicast, or "unidirectional" networks.


> * numbering the packets so one can refer to them in the protcol
Do nut packet headers contain some kind of continuity counter? If yes, then
we just need to number the fragments of nut packets, not all the network
packets.

[...]
> i was hoping when i started that thread that people would read&review
> and make suggestions for improvments.
Well, unless I am wrong it seems that the thread died almost immediately
(and most of the comments were about unrelated stuff :).

Anyway, two important requirements for me are:
1) the ability to send different related streams to different ports or
    even different multicast groups (for example, video to one multicast
    group and audio to a different one)
2) the ability to return some feedback (about network statistics, and so
    on) from the client to the server... Something like the RTCP RR packets.
3) the possibility to go over a generic transport protocol (UDP and TCP as
    a minimum - but maybe we can define our own transport protocol...).

After reading your proposal, I think 1) is already supported (the only
important thing is to ensure that the two different NUT streams have consistent
timestamps)... Right?
We need to think a little bit about 2), but I think adding a new message type
would be the way to go... Right? Then, we need to define the format of the
feedback information.

> For example it surely is too
> vague about a few things like which port to connect to.
Regarding the port, I do not think it should be fixed. I think the best
solution is to use an SDP description (yes, I can see why many people do
not like RTP, but I see no problems with SDP and I think we should use
it). I see that people often like "nut://<IP ADDR>:<port>" URL.
Of course, then we might need some kind of client-server protocol for
requesting a stream...


				Luca