[vlc-devel] Follow-Up, problem recording UDP streams.

[Mark Moriarty]

I can stream a transcoded Dshow video input, no audio, using mmsh, then use
a VLC client to pick up the stream and restream it to a file, no problem.

I can stream using UDP, IF the original source is a file with audio, then
the client can restream it to a file output, no problem.

What I cannot do is have a dshow video source, no audio (dshow-adev="none"),
stream it via UDP, then have the client stream the incoming UDP to a file.
(demuxdump does work, what I cannot do is do a regular stream-to-file, where
I specify MPEG PS, ASF, or whatever encapsulation).

If I do the final thing, doing a UDP transcoded transmission of a Dshow
video with no audio, I get a constant stream of         msg_Warn( p_sout,
"trying to send non-dated packet to stream output!");

This means that the incoming UDP packets, containing dshow source video,
have i_dts <= 0 (line 255 of stream_output.c is the test to generate the
warning)

Looking at access_output/udp.c, line 372, i_dts is a "pass-through"
parameter -- the outgoing UDP packet uses whatever the source had set for
its i_dts value.

When I look at transcode.c, I see adjustement of i_dts for audio, but
nothing relative to video.

When I look at dshow.cpp, I see i_dts being set to i_pts, at line 1354.

At this point I hit a wall -- somehow, with only a video dshow input, it
looks like i_dts, being set to i_pts, must be negative or 0. The best I can
see, it must be happenning in dshow.(unless there's another point in the
processing chain where i_dts gets set/modified).

Line 1357 of dshow.cpp is a call to es_out_Control, which includes    i_pts
> 0 ? i_pts : 0   as a parameter.  Does this mean that i_pts (and therefore
i_dts) may actually be getting set to a negative number in dshow, which
would then trigger the fault when I try to re-stream the incoming UDP?

Thanks.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20041026/efd3ff85/attachment.html>