[vlc-devel] Follow-Up, problem recording UDP streams.
mfmbusiness at earthlink.net
Wed Oct 27 04:12:01 CEST 2004
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel