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

[Rémi Denis-Courmont]

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}}'

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/