[FFmpeg-devel] [PATCH] Pass on position from ffmpeg to filters

[Michael Niedermayer]

On Sun, Jul 11, 2010 at 10:57:37AM +0200, V?ctor Paesa wrote:
> Hi,
> 
> 2010/7/11 V?ctor Paesa
> > Hi,
> >
> > On Sun, Jul 11, 2010 at 00:35, Michael Niedermayer wrote:
> >> On Sun, Jul 11, 2010 at 12:21:48AM +0200, V?ctor Paesa wrote:
> >>> Hi,
> >>>
> >>> On Sat, Jul 10, 2010 at 23:45, Michael Niedermayer wrote:
> >>> > On Sat, Jul 10, 2010 at 11:10:30PM +0200, V?ctor Paesa wrote:
> >>> >> Hi,
> >>> >> ffplay already passes on the file position to filters, but ffmpeg does not.
> >>> >>
> >>> >> I run the patched ffmpeg on the files generated by 'make test':
> >>> >> for i in tests/data/lavf/lavf.*
> >>> >> do
> >>> >> ? echo pos_$i
> >>> >> ? ./ffmpeg -debug 1 -vframes 25 -i $i -vf null -y a.avi 2>&1 </dev/null
> >>> >> done | grep pos
> >>> >>
> >>> >> For ASF, DV, FLV, GXF, MXF, SWF, y4m, the content of ist->st->cur_pkt.pos
> >>> >> does not look a reliable position.
> >>> >>
> >>> >> Thanks in advance for your review,
> >>> >> V?ctor
> >>> >
> >>> >> ?ffmpeg.c ? ? ? ? ? ? ? ? ?| ? ?5 ++++-
> >>> >> ?libavfilter/vsrc_buffer.c | ? ?5 ++++-
> >>> >> ?libavfilter/vsrc_buffer.h | ? ?2 +-
> >>> >> ?3 files changed, 9 insertions(+), 3 deletions(-)
> >>> >> ae2a17e652143de4ce4317537bcff1cbd4d3a040 ?ffmpeg.pos.1.diff
> >>> >> Index: ffmpeg.c
> >>> >> ===================================================================
> >>> >> --- ffmpeg.c ?(revision 24162)
> >>> >> +++ ffmpeg.c ?(working copy)
> >>> >> @@ -1648,7 +1648,10 @@
> >>> >> ? ? ? ? ? ? ?// add it to be filtered
> >>> >> ? ? ? ? ? ? ?av_vsrc_buffer_add_frame(ist->input_video_filter, &picture,
> >>> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ist->pts,
> >>> >> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ist->st->codec->sample_aspect_ratio);
> >>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ist->st->codec->sample_aspect_ratio,
> >>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ist->st->cur_pkt.pos);
> >>> >
> >>> > this looks wrong, pos from the AVPacket you get from the demuxer/parser
> >>> > should be used not some lavf internal one
> >>>
> >>> Pity. Would the next patch be OK to document that this is lavf internal?
> >>>
> >>> Index: libavformat/avformat.h
> >>> ===================================================================
> >>> --- libavformat/avformat.h ? ? ?(revision 24162)
> >>> +++ libavformat/avformat.h ? ? ?(working copy)
> >>> @@ -498,7 +498,7 @@
> >>>
> >>> ? ? ?AVMetadata *metadata;
> >>>
> >>> - ? ?/* av_read_frame() support */
> >>> + ? ?/* Only for av_read_frame() support. NOT PART OF PUBLIC API. */
> >>
> >> id say
> >> not supposed to be used by external applications, try to use something else
> >> if possible
> >>
> >> there may be situations where applications that do uncommon things need to
> >> peek into these, i think ive seen a case where cur_dts was the only way to
> >> get a hint of where one was exactly after a seek without demuxing packets
> >
> > Hmm, we may need a native English to confer the proper degree of ambiguity :-)
> >
> > What about this?
> >
> > $ svn diff libavformat/avformat.h
> > Index: libavformat/avformat.h
> > ===================================================================
> > --- libavformat/avformat.h ? ? ?(revision 24162)
> > +++ libavformat/avformat.h ? ? ?(working copy)
> > @@ -498,7 +498,8 @@
> >
> > ? ? AVMetadata *metadata;
> >
> > - ? ?/* av_read_frame() support */
> > + ? ?/* Intended mostly for av_read_frame() support. Not supposed to
> > be used by */
> > + ? ?/* external applications; try to use something else if at all
> > possible. ? ?*/
> > ? ? const uint8_t *cur_ptr;
> > ? ? int cur_len;
> > ? ? AVPacket cur_pkt;
> 
> Dammed Gmail's 78 chars per line limit. Here is the unmangled patch attached.
> 
> Regards,
> V?ctor

>  avformat.h |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> e2ae4f983b36d9c6360570e9907b5740ec360ced  avformat.cur_pkt.2.diff

ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100711/e0e02bfd/attachment.pgp>