[FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tomas Härdin]

On Mon, 2015-10-05 at 14:25 +0200, Tobias Rapp wrote:
> On 05.10.2015 09:10, tim nicholson wrote:
> > On 04/10/15 13:07, Tomas Härdin wrote:
> >> On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
> >>> [...]
> >>
> >> For me the most important thing is that anything dealing with MXF should
> >> never write invalid files.
> >
> > +1 for sure.
> 
> To overstate your point: So it would be OK to skip most input frames and 
> replace them with black frames as long as the output file is valid MXF?
> 
> I think there are different requirements for determining what makes an 
> "error" depending on the use-case. If I try to recover video frames from 
> an broken hard disk, for example, I probably won't mind some lost 
> frames. If I try to encode a video file from a presumably healthy input 
> file I likely care about lost frames.
> 
> >> I'm not sure whether the current code is
> >> broken per se, but it does look suspicious. Perhaps someone else has a
> >> better idea?
> >>
> >
> > Truncate/pad mis sized frames to allow muxing to continue, and issue a
> > warning (as at present)?
> 
> It is currently quite difficult to ensure that all frames have been 
> transcoded if there is only a warning in the log message because AFAIK 
> the only generic way to separate a info log message from a warning is to 
> parse terminal color code sequences. The other solution would be to 
> maintain a RegEx black-list of log output messages in the parent process.
> 
> Wouldn't it be helpful to introduce some flag option like "-flags 
> +xerror" on avformat level to toggle between "recover as much as 
> possible" mode and "encode all or fail" mode?

Possibly. Feels like it'd be tricky to write tests for. But I do see a
point in having a mode where lavf is not allowed to do anything strange,
as it often tends to want to do. But this really touches on some rather
nasty bits of how lavf is (not) structured, and I think it might be
easier if you just keep some local hack for your workflow rather than
try to bring some sanity to the situation..

/Tomas