[FFmpeg-devel] [PATCH] Only using st->parser->pos when doing repacking in the parser.

[Michael Niedermayer]

On Mon, May 09, 2011 at 12:05:09AM +0200, Reimar Döffinger wrote:
> On Sun, May 08, 2011 at 11:41:48PM +0200, Michael Niedermayer wrote:
> > On Sun, May 08, 2011 at 07:12:36AM +0200, Reimar Döffinger wrote:
> > > That is why this approach, please don't take it as offence, feels like hacking around to try to avoid fixing parser output to have some sensible values.
> > 
> > Iam not offended by that but i think our disagreement comes from this:
> > I feel that frame_offset is a parser internal variable and its already
> > a hack to use it like is done. And now modifying this parser internal
> > variable to make this use work feels risky to me. Maybe it would work
> > out but maybe it would break some parser in some corner case.
> 
> I do understand that, which is why I came up with my latest patch,
> and I am not convinced which is really better.
> The idea there was to actually _not_ use that offset from the parser,
> but just use the packet positions.

Do you refer to this patch ?
 @@ -115,7 +115,8 @@ int av_parser_parse2(AVCodecParserContext *s,
     int index, i;
     uint8_t dummy_buf[FF_INPUT_BUFFER_PADDING_SIZE];

-    if(!(s->flags & PARSER_FLAG_FETCHED_OFFSET)) {
+    if(!(s->flags & PARSER_FLAG_FETCHED_OFFSET) ||
+       s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
         s->next_frame_offset =
         s->cur_offset        = pos;
         s->flags |= PARSER_FLAG_FETCHED_OFFSET;
-----------
This seems to modify parser internal variables on every frame.



> The only intentional difference to your approach is to pass it through
> the buffering so it will compensate for any delay caused by the parser.

I think we seem to fail to understand each other.
pkt->pos is passed through the parser exactly like the timestamps.
I asked if the timstamps are wrong to find out if theres a problem
with the pos reordering or not. If timestamps are correct so should
pos be IMHO

Or for example consider 2 complete codec frames in a demuxer packet
frame_offset will be wrong (pointing in the middle of a demuxer packet
unsuitable for seeking to by file IO)
pkt->pos will be correct when the parser input are correct demuxer
packet positions

If you think your solution works and is better, i think it would be
best if you publish this solution in your private git tree. And users
test this and if no problems are found we could integrate it in main
ffmpeg.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110509/bafe4b78/attachment.asc>