<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Live-devel] key frames (I-frames) in the recorded AVI</TITLE>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1">
<META content="MSHTML 6.00.6000.17092" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hello Ron,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Me too was thinking abount the use of
temporary swap file. :-) But as mentioned below, there is no sense of doing
this in AVIFileSink as long as we use AVI 1.0 index and user checks
output file size from parent code.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>From another hand, the proper implementation of
OpenDML AVI index will not require the use of temporary files either.
There are multiple index sections (index chunks) can be created
within the single OpenDML AVI file and one small superindex section
(index of indexes) is needed in the very beginning of file. The
RIFF section in the new format is still limited to 1 Gb, but it's now legal
to have more than one RIFF section. Therefore, the best strategy would be: 1)
writting bulk of index data to a separate section (and filling appropriate
superindex entry to point to this index section) every ~1 Gb or less of video
data, 2) finalizing the current RIFF section, 3) starting the new RIFF
section and calculating the new bulk of index data. And so
on...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Current AVIFileSink implementation creates a
starnge empty JUNK section in the beginning of AVI files. I think that
was an attempt by the previous author to consider OpenDML superindex
implementation in the furher releases.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Kind regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>Dmitriy Petrenko</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=rmcouat@smartt.com href="mailto:rmcouat@smartt.com">Ron McOuat</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=live-devel@ns.live555.com
href="mailto:live-devel@ns.live555.com">LIVE555 Streaming Media - development
& use</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, December 15, 2010 12:18
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Live-devel] key frames
(I-frames) in the recorded AVI file</DIV>
<DIV><BR></DIV>The bulk of the index could be written to a temp file as the
video portion of the file is filled and then attached to the end of the AVI /
QT file along with any of the other index information that may be required to
wrap the raw index. I know, more to manage and potential problems with partial
completion but I think the memory problem is solved by this
strategy.<BR><BR>On 10-12-14 8:13 PM, Ross Finlayson wrote:
<BLOCKQUOTE cite=mid:f06240800c92df096f65d@%5B66.80.62.44%5D type="cite">
<STYLE type=text/css>BLOCKQUOTE {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>
<BLOCKQUOTE cite="" type="cite"><FONT face=Arial size=-1>One thing that
should be taken into account. The memory allocated by
AVIFileIndex for index grows as video is being received and recorded,
because index section should be added to the very end of AVI file,
just before closure. Although size of index data is very small
comparing to video data, it still could potentionally exhaust all
available memory after the very long recording (many
hours).</FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Yes, it turns out that we have the same issue for
"QuickTimeFileSink". Unfortunately there isn'e anything we can do
about this; these file formats are not well-designed for the purpose of
recording incoming streams.</DIV><X-SIGSEP><PRE>--
</PRE></X-SIGSEP>
<DIV><BR>Ross Finlayson<BR>Live Networks, Inc.<BR><A
class=moz-txt-link-freetext
href="http://www.live555.com/">http://www.live555.com/</A></DIV><PRE wrap=""><FIELDSET class=mimeAttachmentHeader></FIELDSET>
_______________________________________________
live-devel mailing list
<A class=moz-txt-link-abbreviated href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</A>
<A class=moz-txt-link-freetext href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</A>
</PRE></BLOCKQUOTE>
<P>
<HR>
<P></P>_______________________________________________<BR>live-devel mailing
list<BR>live-devel@lists.live555.com<BR>http://lists.live555.com/mailman/listinfo/live-devel<BR></BLOCKQUOTE></BODY></HTML>