[Cin] Test rendering whit x265

[Phyllis Smith]

On Tuesday, August 3, 2021, Andrea paz <gamberucci.andrea at gmail.com> wrote:
>>
>>> The difference between appimage and build is that the former uses
>>> ffmpeg-4.3 and the latter ffmpeg-4.4. There is a small difference
>>> between the 2 renders, see mediainfo test-1.txt (appimage) and
>>> test-2.txt (build). It seems that ffmpeg-4.3 is more accurate. The
>>> real video source has 7500 frame (5min 0sec at 25 fps)!
>>
>>
>>
>> yeah, it seems last or 1 or 2 sec of stream is lost (
>>
>> bad...
>>
>> i'll look into ffmpeg's mail list and other projects to see if there
>> anything easy enough to fix.
>>
>
>
> I tried to slightly alter condition in FFStream::encode_frame
>
*The Bad News*:  In testing the attached patch, I could not find a
difference in the video before and after or even with 4.3 versus 4.4.  I
think *Andrea* needs to test this because he has a definitive case that
shows the problem. I tested 3 cases but they are all little files -- I
think I did some the drop of the last frames a couple of days ago, but I
was concentrating on testing something else at the time and had to keep
focus on what I was doing.
*The Good News:* Just a guess but if the root cause is found, it could
conceivably be the problem with the bluray patch2 which was dropping the
last few frames.

now it does not display flush errors at the end of encoding... if encode
> was much faster than timeline fps (still with 4.4)
>
> problem is, for me encoded avi/mov actually have correct number of frames,
> i checked with mediainfo and internal cingg info window.. but i am on
> 32-bit arm machine...
>
>>
>> for now it seems upgrade to 4.4 still not good idea...
>>
> More testing needed -- I was really hoping to get 4.4 in the July 31
upgrade but was waiting to hear back from the freelancer on a bluray patch
2 fix  -- probably a good thing we held off.

>
>>> PS: I think most users don't look at the messages on the terminal:
>>> appimage you have to specify it if you want to run from shell. If you
>>> compile from terminal, having multiple messages should not be a
>>> problem. In my opinion we can leave the messages without hiding them.
>>>
>> The messages do come in handy so I suppose it is better to leave them.
It is just now with AppImage, a lot of the users might just be typing in
the executable from a terminal window instead of just clicking on an icon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20210803/927aa486/attachment.htm>