>> If your input stream is H.264 video only (i.e., with no audio), then
>> another solution would be to write your own "MediaSink" subclass
>> (perhaps similar to the existing "H264VideoFileSink" class) that
>> writes a sequence of raw (i.e., elementary stream) H.264 video files.
>> You should be a
I suppose that embedding my stream in an avi/wmv container should fix
this ?
It does ! And it is actually an easy job with the tool named avc2avi :)
Thank you so much for your help Ross, much appreciated !
Julien
___
live-devel mailing list
live-deve
If your input stream is H.264 video only (i.e., with no audio), then
another solution would be to write your own "MediaSink" subclass
(perhaps similar to the existing "H264VideoFileSink" class) that
writes a sequence of raw (i.e., elementary stream) H.264 video files.
You should be able to easily
>> Your best solution then is probably just to record a single file for
>> the entire stream, and then later - using some separate tool that's
>> intended specifically for editing '.mov'/'.mp4' files - break it apart
>> into separate files of whatever length you want.
>
> Fair enough, but unfortun
I didn't suggest "closing and reopening the RTSP stream". My
suggestion was to keep the RTSP stream open, but close just the
"QuickTimeFileSink" object, then create a new one and call
"startPlaying()" on it - from the existing source. This doesn't
involve any RTSP commands at all.
My bad, I wa
> But closing and re-opening the RTSP stream will create a gap between the
> files.
I didn't suggest "closing and reopening the RTSP stream". My suggestion was to
keep the RTSP stream open, but close just the "QuickTimeFileSink" object, then
create a new one and call "startPlaying()" on it - f
But closing and re-opening the RTSP stream will create a gap between
the files.
Anyhow, I just tested your suggestion and unfortunately it doesn't
solve my
problem of having the start of file not being aligned on a KeyFrame.
In other words the video remains still until it finds a full frame to
Rather than modifying the supplied library code - which is unlikely to get you
any support on this mailing list - why not instead keep the code 'as is', but
instead use a separate "QuickTimeFileSink" object for each segment of the
stream.
I.e., every 30 seconds do:
Medium::close(mySinkObject);
I need to split an RTSP feed into multiple files of 30 seconds. I have
done
what has been suggested in the thread by sub-classing "QuickTimeFileSink"
and in the "QuickTimeFileSink::afterGettingFrame" ( after sync point )
re-open a new file without stopping the RTSP session.
I indeed get the da
Sorry for the misunderstood , I'll subclass "QuickTimeFileSink" as soon
is possible...
But I have another question..
Finally, I divide the video streming in 60 second mp4 video file...
but now I have another problem:
excpet the first one , the files have about 1 sec of "gray" before
starting
Hi I did a quick change on the QuickTimeFileSink class , for runtime
output file name changing.
Ideally, you should *not* be changing the supplied library code.
Instead, you should subclass "QuickTimeFileSink", and added your new
method - for changing the output file name - to your subclass.
Hi I did a quick change on the QuickTimeFileSink class , for runtime
output file name changing.
You can see below the code:
void QuickTimeFileSink::ChangeOutputFile(UsageEnvironment& env, char *
outputFileName)
{
printf("ChangeOutputFile\n");
completeOutputFile();
CloseOutputFile(fOutFid);
But often the program exits in "Segmentation Fault", and I don't know why...
The reason is that you are closing (and deleting) your 'data sink'
object - "qtOut" - but you are still 'playing' that object. I.e.,
the code thinks that it should still be receiving incoming network
data into the o
13 matches
Mail list logo
