[MPlayer-dev-eng] [PATCH] Do not call to th_decode_ycbcr_out() for packets representing a dropped (0-byte) frame.

[Giorgio Vazzana]

2012/1/14 Carl Eugen Hoyos <cehoyos at ag.or.at>:
> Giorgio Vazzana <mywing81 <at> gmail.com> writes:
>
>> this is the last patch I wanted to submit. The subject pretty much
>> says it all: in case of 0-byte packets we don't need to call
>> th_decode_ycbcr_out() to decode the frame because we have a duplicated
>> frame, and so we can use the last frame.
>
> Is this related in any way to the problem mentioned here?
> http://thread.gmane.org/gmane.comp.video.mplayer.devel/59554/focus=59565

That problem is about 0-bytes packets not being handled correctly at
the demuxer level resulting in wrong pts (I've talked about it in one
of my previous mail:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-December/069665.html
), while this patch is for correctly dealing with those packets at the
decoder level.
I agree that this function is not used yet (because of that "if (!data
|| !len)" I talked about), but think of it as a way to future-proof
and complete the decoder so that no other work will be required.

>> Note: currently we are returning NULL in decode() if (!data || !len)
>> so basically we are discarding duplicated frames. When/if the
>> demuxer(s) will get fixed, we can delete that 'if' and things will
>> work properly at the decoder end.
>>
>> After this patch, the file needs a reindent, I don't know if there is
>> an automated program/script that can do it. If not let me know and
>> I'll do it by hand, after all it's a small file. Regards,
>
> Don't worry, whoever applies can do that, or ask for a patch later.

Ok,

ps: Not related to this patch, but I've just found two other streams
that only seem to work with -demuxer ogg (although ffplay can play
them):

http://modulix.org:8000/libre.ogg
http://modulix.org:8000/savoir.ogg