Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: AW: Wish list for VDR 1.0



Manfred Schmidt-Voigt wrote:
> 
> Dear all + Klaus,
> 
> the VDR project went on into the right direction and I am really surprised
> how much time Klaus has invested to develop this product. And also all the
> others, which provided parts of it, must be thanked for this. But, as
> everywhere in life, the list of whishes never ends.
> 
> So I have another (small?) wish:
> 
> Sometime ago I got a patch from Klaus for the cutting process of the
> recorded videos. This patch enabled me to set the cutmarks and when I
> pressed the "2" button the new files contained excactly the lenght between
> the cutmarks. Thats very usefull for archiving the videos further on to CDs
> in any other compressed format (I like SVCD and the ablility to watch them
> on a standalone DVD set)). The CDs than end up between two scenes and not in
> between the "hottest action". This patch works very well for me but its a
> little bit uncomfortable to include it again and again to the new releases.
> And what happened if the great developers decide to change just that part of
> code?
> 
> So my wish (hurra, bald ist Weihnachten), please include it in the regular
> distribution. Button "2" for the wellknown cut into near equal parts and
> maybe button "3" for files up to the cutmarks.
> 
> Cheers
> Manfred

Using '3' for this would be a bad choice, since I am reserving keys '1' and
'3' for positioning on individual frames (including B- and P-frames) in case
this will ever become possible.

But what could be done is to make the editing process look at the marks
and calculate whether the next chunk of data will still fit into the current
file (limited by Setup.MaxVideoFileSize) and start a new file if it doesn't.
This, however, could result in cases where one file would be pretty small
if there is, e.g., a sequence of 500MB, 200MB, 500MB, and the MaxVideoFileSize
is set to 650MB. While with the current solution this scenario would result
in two files (650MB+550MB), the above method would result in three files
(500MB+200MB+500MB). But if you want to split at your marked positions, this
is what you get. Of course there would also have to be a Setup parameter to
enable/disable this cutting method. I would assume that somebody who wants this
alternate cutting method would _always_ want it, so wasting a valuable key
would not be worth it.

Klaus

> for completenes I will include the patch here again in case somebody
> (Klaus?) has dropped it.
> 
> >>>>
> > If you want to have separate files for each part, you could try adding the
> > following lines in dvbapi.c, cCuttingBuffer::Action():
> >
> >            // Check editing marks:
> >
> >            if (Mark && Index >= Mark->position) {
> >               Mark = fromMarks.Next(Mark);
> >               if (Mark) {
> >                  Index = Mark->position;
> >                  Mark = fromMarks.Next(Mark);
> >                  CurrentFileNumber = 0; // triggers SetOffset before
> reading next frame
> >                  toMarks.Add(LastIFrame);
> >                  toMarks.Add(toIndex->Last() + 1);
> >                  toMarks.Save();
> > +                toFile = toFileName->NextFile();
> > +                if (toFile < 0)
> > +                   break;
> > +                FileSize = 0;
> >                  }
> >               else
> >                  break; // final end mark reached
> >               }
> >            }
> >
> > Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________



Home | Main Index | Thread Index