On Tue, 2012-07-10 at 13:03 +0200, Luca Barbato wrote: > On 07/10/2012 11:59 AM, Diego Biurrun wrote: > > On Tue, Jul 10, 2012 at 05:16:06AM +0200, Luca Barbato wrote: > >> > >> --- a/libavformat/mxfdec.c > >> +++ b/libavformat/mxfdec.c > >> @@ -1873,6 +1873,9 @@ static int mxf_read_header(AVFormatContext *s) > >> /* next partition pack - keep going, seek to previous > >> partition or stop */ > >> if(mxf_parse_handle_partition_or_eof(mxf) <= 0) > >> break; > >> + else if (mxf->parsing_backward) > >> + continue; > >> + /* we're still parsing forward. proceed to parsing this > >> partition pack */ > >> } > > > > The comment looks misplaced after the code. > > It is correct, assumed I understand completely how this two direction > parsing works. Basically once you parse an essence you run the parser > backwards. Depending on where you are while that happens you might end > up parsing the next pack instead of going back. The added lines ensure > you keep parsing backwards instead moving to the next partition.
Correct. > I'm a bit curious about this format since this two direction parsing > seems quite original. The backward parsing is due to PartitionPack not having any offset to the *next* partition - only the previous one (PreviousPartition). Since we don't want to parse the essence and in general can't skip over it (if it's frame wrapped, like OP1a), then we need to skip to FooterPartition, parse it and its metadata, then seek to its PreviousPartition, parse it etc. until we end up where we were when we stopped parsing forward. There's *supposed* to be a Random Index Pack at the very end of the file, but not all files have it. All files I've seen set PreviousPartition and FooterPartition correctly though. Hence this solution. A hypothetical file could have a RIP and no FooterPartition values set (like if muxed to a pipe), in which case you could fill in the PreviousPartition values from the RIP and use the current parsing code as-is. However, IIRC FooterPartition *must* be set so this point may be moot. Feel free to read SMPTE 377m if you're curious about the format, and the two dozen or so related specifications (S377m is very vague about how things like essence are *actually* written). /Tomas _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
