- OEP should close(and then re-open) the rm-tmp-file every now and then, every tenth second or something similar.
That is, after downloading live rtsp-files for lots of hours and hours OEP still crashes and the (raw) tmp file has "disappeared" (depending on the OS)
- when doing "pause-but-keep-recording" on these (live) tmp-rm-files, the original realplayer does not really work while mplayer would, if
-- I could specify mplayer for opening those OEP tmp-files
-- the file-length would be updated (increased) while OEP records and mplayer reads some 10-20 seconds later.
Well, one more, when "it all" crashes, but there is still an OEP tmp-file "there", it would be nice to have OEP to "finalize it", build the indexes,etc.
Note, I use OEP to download, capture huge (alive, streaming) rtsp-rm-files..
Well,well, one more-more, when keeping OEP capturing a really long, alive stream, if one stops the capturing process (to avoid losing everything, that temp-file) it takes a couple of seconds to convert the tmp file to the final rm-file.
That is no problem, but the problem is that OEP does not provide a "new name" for a new (immediatly) started capturing of the same rtsp-source (link).
That is, in this case, huge captured file, still in the middle of finalizing, restarting the same project, capturing the same rtsp-sourse, OEP gets mixed up in trying to "update" the same "file".
That is, that is, I have to wait until the temp->primary->final convertion has been done, change the name of the finalized file and only after that can I start capturing from the same rtsp-source again.
With huge files, 300-3,000 Gbyte "live streams" this can take minutes.
It would be easy if OEP would add some kind of auto-incremented number to the new tmp-file, without checking for the primary, final rm-files which are still in the process of being produced.
For example, one could start OEP capturing some "perpetual stream" and tell it to quickly stop-finalize-continue, for example, every two hours, or when clicks "finalize-restart",or something similar (the problem is that OEP then, on restarting the capturing process, from the same rtsp-source, seems to start checking for "an old version of the same stream")
Obviously, has nothing to do with downloading anything else but live streams.
Gunnar
That is, after downloading live rtsp-files for lots of hours and hours OEP still crashes and the (raw) tmp file has "disappeared" (depending on the OS)
- when doing "pause-but-keep-recording" on these (live) tmp-rm-files, the original realplayer does not really work while mplayer would, if
-- I could specify mplayer for opening those OEP tmp-files
-- the file-length would be updated (increased) while OEP records and mplayer reads some 10-20 seconds later.
Well, one more, when "it all" crashes, but there is still an OEP tmp-file "there", it would be nice to have OEP to "finalize it", build the indexes,etc.
Note, I use OEP to download, capture huge (alive, streaming) rtsp-rm-files..
Well,well, one more-more, when keeping OEP capturing a really long, alive stream, if one stops the capturing process (to avoid losing everything, that temp-file) it takes a couple of seconds to convert the tmp file to the final rm-file.
That is no problem, but the problem is that OEP does not provide a "new name" for a new (immediatly) started capturing of the same rtsp-source (link).
That is, in this case, huge captured file, still in the middle of finalizing, restarting the same project, capturing the same rtsp-sourse, OEP gets mixed up in trying to "update" the same "file".
That is, that is, I have to wait until the temp->primary->final convertion has been done, change the name of the finalized file and only after that can I start capturing from the same rtsp-source again.
With huge files, 300-3,000 Gbyte "live streams" this can take minutes.
It would be easy if OEP would add some kind of auto-incremented number to the new tmp-file, without checking for the primary, final rm-files which are still in the process of being produced.
For example, one could start OEP capturing some "perpetual stream" and tell it to quickly stop-finalize-continue, for example, every two hours, or when clicks "finalize-restart",or something similar (the problem is that OEP then, on restarting the capturing process, from the same rtsp-source, seems to start checking for "an old version of the same stream")
Obviously, has nothing to do with downloading anything else but live streams.
Gunnar
OEP-tmp and finalized rm-files, mplayer and realplayer, I did not explain very well...
It looks like the tmp-files contain the "raw stream" but realplayer does not
agree to play them, maybe because the index-information points to something realplayer "does not like"., kind of like telling realplayer that "there is no index table" compared to telling it "the indextable is somewhere, but that 'somewhere' is nowhere" (0x000 or 0xFFFF)
Some realplayers also seem to test that the extention of the "raw file" is *.rm, they do not agree to even open *.tmp files, although the header-stuff is correct (mplayer tries to figure out any file, based on the header,etc, does not care about the extention, .tmp or .rm??)
Even when one changes the extention of the tmp-file to a rm-file, realplayer seems to have some problems with the missing index-table-pointer (the tmp-file does not yet have a "finalized" index table?) plus problems with "the length" of that tmp-file (when simulteanously OEP-capturing and "playing" with the realplayer, the length, both in bytes and timestamps obviously increase all the time)
mplayer does not seem to test that, or at least does not demand an *.rm file (looks for the content, not just the extention) but has some problems playing "dynamically growing" OEP-tmp-files which have "problems", too long or short packets here and there,etc.. (realplayer can "recover" from them, but if the cannot be "dynamically opened" that does not help)
That is, "it" is almost "there", but not quite yet.. That is, to do both
- capturing of a live rtsp-stream
as well as
- watching it, using either realplayer or mplayer
That is, typical usage for me:
- start watching _AND_ capturing a live rtsp-stream
- press "pause" for the real- or mplayer, while the OEP-capturing continues
- later on, continue watching (while the "capturing process" continues from whereever the stream has "reached" at that point in time)
Compare to the "live-buffering" feature of realplayer, although the realplayer uses encryption for its "buffer file", max 12 hours, cannot be saved, etc.. (but handles adaptiove changes in streaming speed)
and additionally
- every now and then, here and there, "finalize" the already captured "raw stream" (tmp-file??) to
a "finalized rm-file", additionally with "a new" name, while "capturing" (to the raw tmp-file) continues without "semalessly".
Nobody promised it would be easy to even explain this...
Gunnar
It looks like the tmp-files contain the "raw stream" but realplayer does not
agree to play them, maybe because the index-information points to something realplayer "does not like"., kind of like telling realplayer that "there is no index table" compared to telling it "the indextable is somewhere, but that 'somewhere' is nowhere" (0x000 or 0xFFFF)
Some realplayers also seem to test that the extention of the "raw file" is *.rm, they do not agree to even open *.tmp files, although the header-stuff is correct (mplayer tries to figure out any file, based on the header,etc, does not care about the extention, .tmp or .rm??)
Even when one changes the extention of the tmp-file to a rm-file, realplayer seems to have some problems with the missing index-table-pointer (the tmp-file does not yet have a "finalized" index table?) plus problems with "the length" of that tmp-file (when simulteanously OEP-capturing and "playing" with the realplayer, the length, both in bytes and timestamps obviously increase all the time)
mplayer does not seem to test that, or at least does not demand an *.rm file (looks for the content, not just the extention) but has some problems playing "dynamically growing" OEP-tmp-files which have "problems", too long or short packets here and there,etc.. (realplayer can "recover" from them, but if the cannot be "dynamically opened" that does not help)
That is, "it" is almost "there", but not quite yet.. That is, to do both
- capturing of a live rtsp-stream
as well as
- watching it, using either realplayer or mplayer
That is, typical usage for me:
- start watching _AND_ capturing a live rtsp-stream
- press "pause" for the real- or mplayer, while the OEP-capturing continues
- later on, continue watching (while the "capturing process" continues from whereever the stream has "reached" at that point in time)
Compare to the "live-buffering" feature of realplayer, although the realplayer uses encryption for its "buffer file", max 12 hours, cannot be saved, etc.. (but handles adaptiove changes in streaming speed)
and additionally
- every now and then, here and there, "finalize" the already captured "raw stream" (tmp-file??) to
a "finalized rm-file", additionally with "a new" name, while "capturing" (to the raw tmp-file) continues without "semalessly".
Nobody promised it would be easy to even explain this...
Gunnar
Yes the file is raw and it should be finalized before playing it. You can try to use right-click on a file that is being downloaded now and choose Play.
Best regards,
Oleg Chernavin
MP Staff
Best regards,
Oleg Chernavin
MP Staff