Re: [Cin] Single-frame step fwd/bak in viewer delayed?
Building the new git, flv_h264 and ffv1.avi work well. They are both quite slow, but ffv1 is even slower. The quality results are very good, especially for ffv1. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
В сообщении от Wednesday 23 September 2020 06:24:06 Pierre autourduglobe via Cin написал(а): > @Andrea paz > > The option to encode in ffv1 is not yet included in the list of codecs > offered with the avi container. > > So I haven't tested it yet. You can put those files into /usr/share/cin/ffmpeg/video/ and they should appear in Cin's encoder choices ... (after restart?) > > Pierre > > > Le 20-09-22 à 14 h 42, Andrea paz via Cin a écrit : > > @Andrew > > I can't test your new ffv1.avi and flv_h264.flv; it gives me "error > > codec not found" and rendering doesn't start. Pierre, have you tried? > > Do they work for you? > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
В сообщении от Tuesday 22 September 2020 21:42:39 Andrea paz via Cin написал(а): > @Andrew > I can't test your new ffv1.avi and flv_h264.flv; it gives me "error > codec not found" and rendering doesn't start. Pierre, have you tried? > Do they work for you? Strange, while I usually build with ffmpeg.git, those codecs must be in bundled 4.3 too ... -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
@Andrew I can't test your new ffv1.avi and flv_h264.flv; it gives me "error codec not found" and rendering doesn't start. Pierre, have you tried? Do they work for you? -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
Andrea, we will update and add. I tried to add simple ffv1.avi file (use with avi_pcm_s16 sound) > > It doesn't play smooth in CinGG for me (for 1080p/30 fps), but plays in > Mplayer (but frame forward/backward seems to work in Cin, just slowly) > I had no problem playing with 1920x1080/29.7fps but not sure why. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
В сообщении от Sunday 20 September 2020 17:05:37 Andrea paz via Cin написал(а): > > Interesting... It would be enough to add in Cinelerra-GG the possibility > > to use the ffv1 video codec to the list offered with the AVI container > > for rendering and to make sure that these files (ffv1.avi) are then > > readable and usable for editing in Cinelerra-GG. > > > > Pierre > > +1 > I would like to ffv1 also inside .mov that doesn't have the > limitations of .avi, but just for this could be more problematic. I tried to add simple ffv1.avi file (use with avi_pcm_s16 sound) It doesn't play smooth in CinGG for me (for 1080p/30 fps), but plays in Mplayer (but frame forward/backward seems to work in Cin, just slowly) I also added cin_quality=23 to flv_h264.flv (now it gives 32 Mb / min for 1080p/30 fps video - hopefully this quality is good for you too) ffv1.avi Description: Binary data flv_h264.flv Description: Binary data -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
> Interesting... It would be enough to add in Cinelerra-GG the possibility > to use the ffv1 video codec to the list offered with the AVI container > for rendering and to make sure that these files (ffv1.avi) are then > readable and usable for editing in Cinelerra-GG. > > Pierre +1 I would like to ffv1 also inside .mov that doesn't have the limitations of .avi, but just for this could be more problematic. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
Interesting... It would be enough to add in Cinelerra-GG the possibility to use the ffv1 video codec to the list offered with the AVI container for rendering and to make sure that these files (ffv1.avi) are then readable and usable for editing in Cinelerra-GG. Pierre Le 20-09-20 à 02 h 30, Andrew Randrianasulu via Cin a écrit : Maybe avi will work (with usual avi limitations)? https://natron.readthedocs.io/en/rb-2.3/plugins/fr.inria.openfx.WriteFFmpeg.html -- Output format/container. guess from filename (default) AVI (Audio Video Interleaved) [avi] (avi): Compatible with ayuv, cinepak, ffv1, ffvhuff, flv, h263p, huffyuv, jpeg2000, jpegls, ljpeg, mjpeg, mpeg2video, mpeg4, msmpeg4v2, msmpeg4, png, svq1, targa, v308, v408, v410, vc2, libopenjpeg, libtheora, libvpx, libvpx-vp9, libx264, libx264rgb, libxvid, libopenh264. --- -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
В сообщении от Wednesday 16 September 2020 11:21:32 Andrea paz via Cin написал(а): > I gave up using mkv because it always gave me seek problems (see BT > #137). I tried to use Transcode and got new mkv, but it doesn't solve > the problem. I tried to use mkvtoolnix (which was created just for > these problems) but I didn't solve the problem. In the latter case, > however, it could be my fault that I don't know how to use the program > well. > Sorry to leave this container because it is the only one using ffv1, > which is a (better) alternative to ProRes and DNxHD. But it is really > too problematic. In my ignorance I ask: can you bring ffv1 (and opus, > flac, etc) under mov or other container Maybe avi will work (with usual avi limitations)? https://natron.readthedocs.io/en/rb-2.3/plugins/fr.inria.openfx.WriteFFmpeg.html -- Output format/container. guess from filename (default) AVI (Audio Video Interleaved) [avi] (avi): Compatible with ayuv, cinepak, ffv1, ffvhuff, flv, h263p, huffyuv, jpeg2000, jpegls, ljpeg, mjpeg, mpeg2video, mpeg4, msmpeg4v2, msmpeg4, png, svq1, targa, v308, v408, v410, vc2, libopenjpeg, libtheora, libvpx, libvpx-vp9, libx264, libx264rgb, libxvid, libopenh264. --- also recommended here: http://download.das-werkstatt.com/pb/mthk/info/video/FAQ-digital_video_archiving.html Q: What are the pros and cons regarding these video formats for archiving? container video-codec audio-codec 1. MXF JPEG2000 PCM (uncompressed) 2. MXF Uncompressed PCM (uncompressed) 3. MOV ProRes PCM (uncompressed) 4. MKV FFV1 PCM (uncompressed) 5. AVI FFV1 PCM (uncompressed) This answer is so long, that we've put a detailed comparison of the "usual suspects" on its own page: Comparing video codecs and containers for archives Q: Which audio/video codecs does the Mediathek use? For captured material, we use FFV1 for video and uncompressed PCM for audio. Audio resolution depends on the source material, but analogue sources are captured using 48kHz 24bit, as this is the SDI standard. "Born digital" material, coming in as a file already, is a whole different story. Please read up on born digital details, below. Q: Which container does the Mediathek use? We use AVI (Audio Video Interleaved). Almost every application that has to do with video can handle AVI files. Ranging from Free Software (Open Source) to proprietary tools, professional and consumer alike. It has a quite limited set of features, but this is also a main feature for long-term preservation: simple = robust. Also: more features = more possible points of failure. Some archives argue the case for containers with complex features, but do not acknowledge the dangers accompanying this decision: the more features a container has, the more possible points of failure are added to your archive copy. Keeping this in mind, we made our decision for a simple container. In practice, we've had almost no interoperability issues with using AVI across different tools from different vendors. Even across different operating system platforms. We currently do not yet know of any other container that is so widely and stably supported. ===end of quotation -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
I gave up using mkv because it always gave me seek problems (see BT #137). I tried to use Transcode and got new mkv, but it doesn't solve the problem. I tried to use mkvtoolnix (which was created just for these problems) but I didn't solve the problem. In the latter case, however, it could be my fault that I don't know how to use the program well. Sorry to leave this container because it is the only one using ffv1, which is a (better) alternative to ProRes and DNxHD. But it is really too problematic. In my ignorance I ask: can you bring ffv1 (and opus, flac, etc) under mov or other container -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
Andrew,
OK, GG says "mkv does not seek well" and that is a known problem with mkv
with no solution. If you use Settings->Transcode to transcode to mp4 then
the video works just fine. I tested that.
On Tue, Sep 15, 2020 at 4:38 PM Phyllis Smith
wrote:
> Andrew,
>
> I discovered that at least on highly-compressed mkv file ("Swimming with
>> orca in New Zealand-JQ3mDXF3bcE.mkv") setting position cursor (in viewer
>> window) at random place with mouse and then trying to use frame
>> forward/frame backward buttons doesn't work: I need to click many times
>> until it finally (after hitting codec keyframe?) started to advance. I
>> tried to set cache to 1 Mb - from 250 or 768Mb - bug was still around.
>>
> I do not know if this is a bug -- I think it is really in the video. If
> you put your cursor randomly in the video anywhere around 02:10:00 to
> 02:11:xx where it is easy to see the swimmer, and then use frame reverse
> or forward, you can see the frame move easily.
>
>>
>> Problem is - this is not just visual bug - rendered file also has this
>> pause (I was surprized)
>>
>> Cinelerra Infinity - built: Sep 14 2020 05:20:48 - hopefully latest git.
>>
>> Anyone can confirm/deny?
>>
> So I can confirm what you see in other parts of the video though so I will
> have to ask GG for an explanation.
>
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Single-frame step fwd/bak in viewer delayed?
Andrew,
I discovered that at least on highly-compressed mkv file ("Swimming with
> orca in New Zealand-JQ3mDXF3bcE.mkv") setting position cursor (in viewer
> window) at random place with mouse and then trying to use frame
> forward/frame backward buttons doesn't work: I need to click many times
> until it finally (after hitting codec keyframe?) started to advance. I
> tried to set cache to 1 Mb - from 250 or 768Mb - bug was still around.
>
I do not know if this is a bug -- I think it is really in the video. If
you put your cursor randomly in the video anywhere around 02:10:00 to
02:11:xx where it is easy to see the swimmer, and then use frame reverse or
forward, you can see the frame move easily.
>
> Problem is - this is not just visual bug - rendered file also has this
> pause (I was surprized)
>
> Cinelerra Infinity - built: Sep 14 2020 05:20:48 - hopefully latest git.
>
> Anyone can confirm/deny?
>
So I can confirm what you see in other parts of the video though so I will
have to ask GG for an explanation.
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] Single-frame step fwd/bak in viewer delayed?
I tried to re-create this lesson where you put in and out points in viewer, and
then create clips and from them make your timeline.
I discovered that at least on highly-compressed mkv file ("Swimming with orca
in New Zealand-JQ3mDXF3bcE.mkv") setting position cursor (in viewer window) at
random place with mouse and then trying to use frame forward/frame backward
buttons doesn't work: I need to click many times until it finally (after
hitting codec keyframe?) started to advance. I tried to set cache to 1 Mb -
from 250 or 768Mb - bug was still around.
Problem is - this is not just visual bug - rendered file also has this pause (I
was surprized)
Cinelerra Infinity - built: Sep 14 2020 05:20:48 - hopefully latest git.
Anyone can confirm/deny?
--
Cin mailing list
Cin@lists.cinelerra-gg.org
https://lists.cinelerra-gg.org/mailman/listinfo/cin
