[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B

[Michael Niedermayer]

Hi

On Tue, Aug 08, 2006 at 08:16:04PM +0200, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > [...]
> > 
> > no it depends on the container, mpeg in avi, nut, mov, ... will not
> > be parsed
> > 
> >> Also assuming b frame regarding pts/dts difference is not exact, 
> > 
> > elaborate / bugreport
> > and i prefer to fix a bug instead of changing the AVPacket or AVParser
> > API to workaround it
> > 
> 
> Im sending a sample, Atm test is wrong for containers that does not have
> pts (avi), and anyway genpts does not generate correct pts for streams
> with B frames in avi. Parser detects correctly that frame is a B one.
> 
> Let's see:
> ffmpeg -i <file.mpg> -vcodec h264 -bf 2 test.avi

knowledge of frame types of h.264 is not enough to calculate pts/ctts
so your B_TYPE flag wont help, for example:

     IPBBB
dts: 01234
pts: 15234

or maybe

     IPBBB
dts: 01234
pts: 26435

or ... 

[...]

> >> and
> >> has_b_frames is not set when stream copying.
> > 
> > the parser should set it, if it does not thats a bug which you can fix if
> > you like, alternatively you can assume it to be always 1
> > 
> 
> Parser depends on container, no ? 

well it does ...


> Should demuxer set has_b_frame ?

if it has enough knowledge about the video then why not


> What about always invoking parser when stream copying ?

no


> 
> Well assuming oftenly lead me to problems when reviewing, and when
> interpreting, so I would better stop assuming anything.
> 
> IMHO If has_b_frames is 0 then stream does not contain b frames.

yes if has_b_frames has been set by parser/demuxer/decoder


> 
> >> [...]
> >>
> >> Players (broadcast servers) does not behave correctly if B and P values
> >> are 0, random will be just wrong.
> > 
> > elaborate, which broadcast server does what? the spec clearly says
> > "These values are provided for information purposes only."
> 
> Grass Valley M Series. During import it will simply reject files with B
> and P > 0 since M Series cannot decode them for example. Unfortunately
> broadcast servers are not as robust as our beloved ffmpeg/mplayer and
> almost always rely on formats flags/infos/metadatas whatever.
> 
> If you fake the number, it will be ingested and will crash the server
> when trying to play. Same goes for Closed gop flag btw. That's the next
> thing I need to figure out and detect.

well, then iam ok with trying to set the p/b count values to something
approximately correct ...


[...]

> 
> >>> and the media field number should be set to dts and time line field
> >>> number to pts, not a random +=2 every frame variable
> >> That is right. media field number is actually dts, 
> > 
> > good so we agree
> > 
> > 
> >> computed correctly
> >> internally 
> > 
> > no your calculation is wrong, try a telecined mpeg 
> 
> Humm you mean MPEG 1/2 field stored right ? If so then yes it is wrong.

no i mean mpeg with some frame durations of 1.5 (that would require you
to add 3 instead of 2, strictly its interlaced so the even rules in the
spec wont apply

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is