[FFmpeg-user] HEVC decoding from multicast
Andrey Utkin
andrey.krieger.utkin at gmail.com
Wed Feb 5 18:52:26 CET 2014
2014-02-05 Carl Eugen Hoyos <cehoyos at ag.or.at>:
> I don't know but since you may not know it:
> H264 frames after an I-frame are allowed to reference older
> frames from before that I-frame.
> (So the usefulness of AV_PKT_FLAG_KEY is extremely limited
> for H.264, as said, the decoder by default takes care about
> this and starts decoding from a recovery point unless told
> otherwise.)
> I absolutely don't know if this is also true for hevc but
> I wouldn't be surprised.
I thought a keyframe _is_ a recovery point for decoding. According to
your explanation, it is not so. Could you please briefly satisfy my
curiosity - how does ffmpeg find recovery points?
>> >> As a hint you could check AVPacket.flags for
>> >> AV_PKT_FLAG_CORRUPT
>> >
>> > Does this flag really have any relevance?
>> > (I don't mean for hevc streams but in the general case:
>> > When is it useful?)
>>
>> mpegts demuxer sets this when PES packet is not percepted
>> totally correctly. AVFormatContext can be configured to
>> discard them silently, but by default they are returned
>> from av_read_frame() amongst others.
>
> Ok, understood.
> My question is now: In which situation would you like to
> discard those frames? Error concealment historically was
> a strength of FFmpeg (there was a paper comparing it to
> commercial decoders), completely dropping a frame instead
> of decoding as much as possible must have catastrophic
> visual effects on any real-life content or do I miss
> something?
Well, i see the problem of topic starter is bad quality of shots done
by brief stream sniffing. My suggestion was to catch a
correctly-transmitted keyframe and dump that, if it fails to decode
(in enabled error detection mode), then catch another such keyframe
and try to decode.
--
Andrey Utkin
More information about the ffmpeg-user
mailing list