[FFmpeg-devel] RTP mark bit not passed to parse_packet

Michael Niedermayer michaelni
Fri Jan 16 14:33:13 CET 2009


On Fri, Jan 16, 2009 at 10:26:56AM +0100, Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
> Michael Niedermayer wrote:
> > On Thu, Jan 15, 2009 at 06:53:45PM +0100, Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
> >> Michael Niedermayer wrote:
> >>>>>> However, I'm still struggling to understand why the command:
> >>>>>> doesn't even create "out.263" nor prints any of the hex dumps...
> >>>>> a few printf()/av_log() should tell you where it gets stuck an why
> >>>> See my answer to Luca: we never get past av_find_stream_info, never 
> >>>> calling my code. Please answer there.
> >>> the thing is ffplay/ffmpeg file.h263 has to get past it if it plays the file,
> >>> what is different?
> >>> A few printf/av_log in av_find_stream_info() should show what is different ...
> >> Indeed, thanks !
> >>
> >> Further investigation (printing the incremented counter of frames in 
> >> av_find_stream_info()) shows that it takes a fairly large number of 
> >> frames to decide, unless an EOF occurs I guess. But in RTP/UDP there's 
> >> no EOF of course, and I was repeatedly streaming the same short 
> >> sequence, so when the seqnum/timestamps had a discontinuity, maybe the 
> >> guessing work was reset...
> >>
> >> Anyway, streaming a longer sequence works.
> >>
> >> A few ancillary questions:
> >>
> >> 1) This means all those frames are accumulated in memory, right ?
> > 
> > yes
> > 
> > 
> >> 2) What extra info could I have provided (eithr in the SDP or in 
> >> command-line options) so that this guessing work be avoided ?
> > 
> >         for(i=0;i<ic->nb_streams;i++) {
> >             st = ic->streams[i];
> >             if (!has_codec_parameters(st->codec))
> >                 break;
> >             /* variable fps and no guess at the real fps */
> >             if(   tb_unreliable(st->codec)
> >                && duration_count[i]<20 && st->codec->codec_type == CODEC_TYPE_VIDEO)
> >                 break;
> >             if(st->parser && st->parser->parser->split && !st->codec->extradata)
> >                 break;
> >             if(st->first_dts == AV_NOPTS_VALUE)
> >                 break;
> >         }
> >         if (i == ic->nb_streams) {
> >             /* NOTE: if the format has no header, then we need to read
> >                some packets to get most of the streams, so we cannot
> >                stop here */
> >             if (!(ic->ctx_flags & AVFMTCTX_NOHEADER)) {
> >                 /* if we found the info for all the codecs, we can stop */
> >                 ret = count;
> >                 break;      <------------------------------------
> >             }
> >         }
> > 
> > it should leave av_find_stream_info() at the marked point
> > add a few printf/av_log() to find out why this is not reached
> 
> Thanks. What happens here is that has_codec_parameters() returns FALSE 
> for the video codec (H263). Stepping into it shows that:
> 
>      case CODEC_TYPE_VIDEO:
>          val = enc->width && enc->pix_fmt != PIX_FMT_NONE;
> 
> here *both* conditions in the && are false :)
> 
> So I guess I have my answer: I should provide externally (1) a nonzero 
> width and (2) a non-NONE pix_fmt. (what's the easiest way of providing 
> them ? command-line options or SDP ?)

you must extract all parameters out of the global headers from SDP and
set them.


> 
> May I ask *why*, out of the zillions of parameters, just these two are 
> needed, and justify swallowing 91 frames (not just 1) ?

Because them being set implicates all others also are set.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/20090116/552fa0eb/attachment.pgp>



More information about the ffmpeg-devel mailing list