Thread: [Mlt-devel] Non-destructive rendering
Brought to you by:
ddennedy,
lilo_booter
From: Jean-Michel <jm...@fr...> - 2006-10-26 06:41:10
|
Hello, We are using MLT and Kdenlive to create a video documentary, sharing resources over the internet. Using Kdenlive, the normal way to proceed is to use DV source files. But this means that we need 20 Gb disk space for an hour of source files. This makes it impossible to share source files over the internet. On the converse, I would like to be able to convert source files ***once for all*** to high quality Mpeg4. This would allow sharing source files over the Internet. The final film would be rendered, without major recoding, except transitions. I guess this feature is called non-destructive rendering. It basically is the following command: ffmpeg -acodec copy -vcodec copy ... Does MLT support non-destructive rendering? Are there plans for MLT to support non-destructive rendering in the future? MLT is designed for broadcast. I hope that my email can contribute to explain the needs of individuals, working in communities, over the internet, trying to produce high quality movies/documentaries. I think that we really need non-destructive rendering. Kind regards, Jean-Michel |
From: Dan D. <da...@de...> - 2006-10-27 01:37:10
|
On Wednesday 25 October 2006 11:41 pm, Jean-Michel Pour=E9 wrote: > We are using MLT and Kdenlive to create a video documentary, sharing > resources over the internet. > > Using Kdenlive, the normal way to proceed is to use DV source files. But > this means that we need 20 Gb disk space for an hour of source files. > This makes it impossible to share source files over the internet. > > On the converse, I would like to be able to convert source files ***once > for all*** to high quality Mpeg4. This would allow sharing source files > over the Internet. The final film would be rendered, without major > recoding, except transitions. > > I guess this feature is called non-destructive rendering. It basically > is the following command: ffmpeg -acodec copy -vcodec copy ... MLT does not currently support automatic non-destructive rendering. However= ,=20 for the special case of DV, I think this could be easily supported because= =20 MLT already passes the DV data; it's just the end component, what we call=20 the "consumer" that does not know what to do with it. Also, we would need t= o=20 add something to the framework to indicate if a frame's audio or video=20 is "tainted" (audio editing is only accurate to the video frame). > Does MLT support non-destructive rendering? > Are there plans for MLT to support non-destructive rendering in the > future? Nothing is planned. Well, Charlie does a little work in support of Jahshaka= =2E=20 Jean-Baptiste in support of kdenlive. I am busy trying to put final touches= =20 on Kino for its end-of-year 1.0 release, and then I plan to begin working o= n=20 MLT more in support of the kdenlive project, mainly. So, I think it is=20 reasonable to expect it, just not real soon. > MLT is designed for broadcast. I hope that my email can contribute to > explain the needs of individuals, working in communities, over the > internet, trying to produce high quality movies/documentaries. I think > that we really need non-destructive rendering. I believe you need automated "offline" capability more so=20 than "non-destructive rendering." Non-destructive editing *only* makes sens= e=20 if the input and outputs are the same coding and not temporally-compressed= =20 like MPEG-4 is. If you have an edit point in the middle of an MPEG-4 GOP,=20 then you will need to recode the parts in the GOP, and this is even more=20 complicated if it using B-frames. Perhaps you want to transcode all DV clip= s=20 to MPEG-4, do the distributed, collaborative editing, then change the final= =20 project file to refer back to the DV clips for the best quality for anythin= g=20 needing rendering. Finally, the non-destructive rendering only works when t= he=20 rendered output is DV, which is increasingly rare. P.S. MLT was designed for broadcast, but this discussion is about=20 post-production. :-) =2D-=20 +-DRD-+ |
From: Jean-Michel <jm...@fr...> - 2006-10-27 15:03:08
|
Le jeudi 26 octobre 2006 =C3=A0 18:36 -0700, Dan Dennedy a =C3=A9crit : >=20 > I believe you need automated "offline" capability more so=20 > than "non-destructive rendering." Non-destructive editing *only* makes > sense=20 > if the input and outputs are the same coding and not > temporally-compressed=20 > like MPEG-4 is. If you have an edit point in the middle of an MPEG-4 > GOP,=20 > then you will need to recode the parts in the GOP, and this is even > more=20 > complicated if it using B-frames. Perhaps you want to transcode all DV > clips=20 > to MPEG-4, do the distributed, collaborative editing, then change the > final=20 > project file to refer back to the DV clips for the best quality for > anything=20 > needing rendering. Finally, the non-destructive rendering only works > when the=20 > rendered output is DV, which is increasingly rare.=20 Dear Dan, Why not record the whole GOP, in case of a transition.=20 Usually, it is only 1 or 2 seconds. In Kdenlive, this is like a clip would be cut in three pieces: - First GOP : recoded - Main video : ffmpeg -acodec copy -vcodec copy - Last GOP : recoded Kind regards, Jean-Michel |
From: Dan D. <da...@de...> - 2006-10-31 05:09:42
|
On Friday 27 October 2006 08:02, Jean-Michel Pour=C3=A9 wrote: > Le jeudi 26 octobre 2006 =C3=A0 18:36 -0700, Dan Dennedy a =C3=A9crit : > Why not record the whole GOP, in case of a transition. > Usually, it is only 1 or 2 seconds. > > In Kdenlive, this is like a clip would be cut in three pieces: > - First GOP : recoded > - Main video : ffmpeg -acodec copy -vcodec copy > - Last GOP : recoded It is not always that simple because GOPs are not necessarily closed. IOW, = a B=20 frame at the end of a GOP could reference a frame into the next GOP. In=20 MPEG-4 AVC (H.264), the frame references are potentially even more extended= =2E=20 It is possible to impose restrictions and make a special "offline draft" mo= de=20 that sets everything up correctly (closed GOP or no B frames, max 1 frame=20 reference in AVC, etc), but then that encoding would often not be the=20 desirable encoding for the final distribution. Furthermore, the framework i= s=20 not currently aware of any of these rules. Therefore, I find this to be=20 potentially a lot of work for something that is perhaps fundamentally flawe= d.=20 I certainly do not discourage any developer that wants to try it, but my=20 energy is quite limited. I merely hope to get back into a maintenance mode = on=20 MLT sometime soon. I think there are more fundamental and interesting thing= s=20 to address in MLT. Certainly, something more achievable in the near term is a system to transc= ode=20 all of the DVs to MP4s, keeping the base filename, and edit against the MP4= s.=20 Then, when ready for publishing, change the project file to refer to the DV= =20 files and let the holder of the original DV files render a final MP4. (MP4 = is=20 just example, could be AVI or other as well). All of that could be done=20 outside of MLT (and would have to be since Kdenlive has its own project fil= e=20 format). |