[vlc-devel] [PATCH 1/1] udp: support packets dump in access_out module

[Tzu-Jung Lee]

Hi Rémi,

On Fri, Jul 12, 2013 at 12:27 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le jeudi 11 juillet 2013 15:32:08, Tzu-Jung Lee a écrit :
>> Currently the final display looks very blocky, and sometimes even broken.
>> Our video folks insist that VLC did something to the clip so the
>> device can't transcode it correctly.
>> And I also did a experiment on PC:
>>
>>    e) cvlc feed.ts --sout #std{access=udp,dst=127.0.0.1}' &
>>    f)  udp:// --sout #std{access=file,dst=saved.ts}' &
>>
>> It turns out the saved.ts already has obvious artifices.
>> I notice that muxer/demuxer/udp all discard data if it think it have
>> some problems such as strange time-stamps.
>
> The demuxer should not drop anything. The muxer is likely at fault. The UDP
> output will drop data write buffer fills up in kernel side; but your patch
> cannot detect this.
>
> To be honest, I don't really fancy reinventing the file output inside the UDP
> output... I would rather suggest, either of:
> - adding multiple output to the existing stream_out_standard plugin,
> or
> - creating a "duplicate" access output plugin teeing to multiple outputs.
>
> First though, you could simply try to duplicate the muxer, e.g.:
> '#duplicate{dst=std{mux=ts,access=file,file=output.ts},dst=std{mux=ts,access=udp,dst=192.168.1.1}}'

The duplicate output.ts is not necessarily exactly the same as what
UDP access_out sent.
For example, the UDP access_out discard packets when it think they are
too late to be sent.

I'm interested in your suggestion above, could you help elaborate how
to do it, or
where I can start with?

>
> Granted, the muxer state machine will be duplicated, but this does not require
> any new code, and will probably still exhibit most of the problems you are
> trying to analyze.
>
>> So I'm going to add the dumps at several point in the following
>> pipeline to find out at which stages the clips is still okay for our
>> device.
>>
>>     file_access ->demux -> mux-> udp_out
>>     /  udp_access -> demux -> mux -> v4l2_out -> device -> v4l2_access
>>     -> demux -> mux -> udp_out
>
> So your device converts TS to TS? Interesting that this gets exposed via
> V4L2...
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/

Thanks.

Roy