Hi,
Stas Oskin wrote:
[...]
> Nope, I'm receiving a video from another video source using their own
> SDK (it's mpeg4 but protocol seems to be a proprietary one). Then I'm
> re-encoding the video and re-streaming it.
[...]
> It goes about this fashion:
>
> *source* --- |ADSL| --- *sdk* --- *ffmpeg* --- *DSS* --- |LAN| --- VLC
>
> And the issue exist without DSS as well:
> *source* --- |ADSL| --- *sdk* --- *ffmpeg* --- |LOCALHOST| --- VLC
[...]
>> You can use some tools like wireshark, tcpstats, and similar to
>> check what's happening in the network... Also, many players allow
>> to monitor the number of lost packets, the buffers' levels, etc...
>> Maybe you can use these statistics to understand where the problem
>> is.
>
> Just to understand, the number of sent frames should be equal to
> number of received frames on the player end? Or packets?
I do not think you can compare the number of frames with the number of
packets... But using wireshark you can check the RTP header of all the
packets in the network, to see if any packet is lost (there is a counter
field in the RTP header, which you can inspect with wireshark).
[...]
>> The "ffmpeg" program provides a way to address this problem (-vsync
>> and -async). If you are usign your own program, you might need to
>> implement something similar.
>
> Any idea if it still can help in this case (as I don't use any card)?
No, I don't think so. According to your new description, this does not
seem to be the problem.
[...]
> FFMPEG is used as encoding/RTP streaming library only, it's not a
> client. Any idea what this option to send RTP in TCP/RTSP might be?
In this case, you must use RTP over UDP for feeding the DSS, and then
the client can ask DSS for RTP over TCP (there should be an appropriate
option in the player that you use as a client).
>> > 2) Could it be that the timing formula (with av_rescale_q) is somehow
>> > causing this?
>>
>> In theory, no... But the network can introduce some jitter, causing
>> problems. You can correct the timing formula to send a small amount
>> of packets "in advance" to compensate for some possible network jitter.
>> You can also modify it to "smooth" the output bitrate, so that your
>> stream can be more "ADSL friendly".
>>
>
> Any idea if it still applies to case where video coming clearly, but
> not re-streamed clearly?
When I wrote the previous email, I did not know that you receive the
video through some special SDK before streaming it via RTP. Now, I
suspect that the SDK is giving you the video with a timing that
generates some interference with the "timing formula". If the SDK is
providing the video with a correct timing, you can just rely on it for
the synchronization, and forget about the timing formula and usleep().
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
