[FFmpeg-devel] [PATCH v2 4/8] ffmpeg: remove sub-frame warning

[Michael Niedermayer]

On Wed, Mar 23, 2016 at 08:44:41PM +0100, wm4 wrote:
> On Wed, 23 Mar 2016 18:37:25 +0100
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > On Wed, Mar 23, 2016 at 06:06:37PM +0100, wm4 wrote:
> > > On Wed, 23 Mar 2016 17:51:11 +0100
> > > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > >   
> > > > On Wed, Mar 23, 2016 at 02:02:11PM +0100, wm4 wrote:  
> > > > > It's not practical to keep this with the new decode API.
> > > > > ---
> > > > >  ffmpeg.c | 7 -------
> > > > >  ffmpeg.h | 1 -
> > > > >  2 files changed, 8 deletions(-)    
> > > > 
> > > > its not practical in ffmpeg.c but libavcodec should be able to easily
> > > > check that a decoder which doesnt declare AV_CODEC_CAP_SUBFRAMES
> > > > doesnt decode "subframes"
> > > > Can you move this check into libavcodec ?
> > > > i think otherwise nothing would be checking for missing
> > > > AV_CODEC_CAP_SUBFRAMES anymore
> > > >   
> > > 
> > > What's the point of this check?  
> > 
> > to keep track of / detect the cases that put multiple decodable frames
> > in a packet.
> > 
> > Whats the point of that?
> > there where several IIRC
> > one is that when too many frames are put in a packet 
> > latency increases, another is that seeking granularity is worse
> > (if its not even one packet for the whole file ...)
> 
> It's true that too many frames in a packet isn't ideal, but that's not
> what the code checks.
> 
> It checks if an audio decoder not marked with AV_CODEC_CAP_SUBFRAMES
> consumes partial packets.

yes, but a check that checks "if a decoder not marked with
AV_CODEC_CAP_SUBFRAMES consumes partial packets". Is a simple and
zero overhead way of detecting some (not all) cases where there are
multiple frames in a packet. One cant look at a sequence of bytes
that could be any arbitrary format/codec and say
"thats more than 1 frame" it requires codec specific code,
the decoders already do what is needed for some cases, for the others
there is (please correct me if iam wrong which might be) no easy
way except maybe running the parser if one exists over it but that
would not be zero overhead


> That might be useful as debug check in
> libavcodec or so, or by properly reviewing patches for new decoders.

Iam not sure if i understand what you mean exactly but this somehow
sounds like an implication that people would not review patches
properly.
Thats a serious accusation if thats what was meant. Either there is
a problem then it should be pointed to very specifically so it can be
solved or such implications shouldnt be made at all.


also replacing automated tests by manual tests is not a good idea
cpu time is a lot more available than man hours, and even where
a human checks things, having the computer double check it even if
only partial is a overal win, humans make mistakes and can miss/forget
things even if they try their best with the resources available to
them.

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160323/953fd56e/attachment.sig>