Wie wärs einfach mit "Auto" wenn amn sich drauf verlässt, und 4:3 oder 16:9 wenn mans vorgeben will?
[CALL FOR HELP] Burn-Autor braucht Infos zu Euren Aufnahmen!
- LordJaxom
- Geschlossen
-
-
Ne Vorschau, einmal in 4:3 dann in 16:9, anschliessend manuelle Auswahl.
-
Also der Scanner springt selbst schon in die Aufnahme (deshalb sind die Ergebnisse ja auch sehr präzise, zumindest die bisher ausgewerteten). Man nimmt natürlich an, dass der Benutzer eine sinnvoll markierte (!) Aufnahme zum Brennen auswählt, das heisst:
- Aufnahme wurde geschnitten und hat "Restmarken"
- Aufnahme wurde geschnitten und hat keine MarkenIn diesen Fällen wird 10 Sekunden vom Beginn in den Film gesprungen
- Aufnahme wurde nicht geschnitten, soll also während des Brennens geschnitten werden
Hier wird 10 Sekunden hinter der ersten Marke gescannt
Wenn der Benutzer freiwillig eine unmarkierte Aufnahme mitsamt Werbeblöcken brennen will, greift die Automatik natürlich nicht, aber wer will das schon?! Zur Not muss dieser User halt selbst den Film anschauen und die Auswahl im Spurenmenü ändern.
EDIT:
Oh, übersehen:ZitatOriginal von FireFly
Ich hatte aber die Tage das Problem, daß ich einen Vorspann von 30 sec in 4:3 hatte und der Film war dann in 16:9, es wurde aber alles (von dvdauthor) als 4:3 markiert und ich war froh, daß ichs erst auf ner RW Probe geguckt hatte...Argh, das ist gemein... Okay, ich denke mir also doch noch was aus
-
- Aufnahme wurde geschnitten und hat keine Marken
Heisst für mich ich kann irgendwo im Video ne Schnittmarke setzen nachdem
ich den Film geschnitten hab. Dies würde das Prob was FireFly hatte doch umgehen, oder? -
Hi,
Bekomme leider das beim make:
ude -I../../../../Imlib2 -I. -o scan-test.o scan-test.c
g++ -fPIC -g -O2 -Wall -Woverloaded-virtual scan-test.o burn.o chain-vdr.o chain-dvd.o jobs.o logger-vdr.o skins.o chain-archive.o manager.o i18n.o menuburn.o menubase.o etsi-const.o tracks.o scanner.o menuitems.o setup.o common.o config.o render.o genindex/pes.o -o scan-test \
proctools/libproctools.a -lImlib2 -ljpeg -lpthread -ldl -lcap \
../../../audio.o ../../../channels.o ../../../ci.o ../../../config.o ../../../cutter.o ../../../device.o ../../../diseqc.o ../../../dvbdevice.o ../../../dvbosd.o ../../../dvbplayer.o ../../../dvbspu.o ../../../eit.o ../../../eitscan.o ../../../epg.o ../../../filter.o ../../../font.o ../../../i18n.o ../../../interface.o ../../../keys.o ../../../lirc.o ../../../menuitems.o ../../../menu.o ../../../nit.o ../../../osdbase.o ../../../osd.o ../../../pat.o ../../../player.o ../../../plugin.o ../../../rcu.o ../../../receiver.o ../../../recorder.o ../../../recording.o ../../../remote.o ../../../remux.o ../../../ringbuffer.o ../../../sdt.o ../../../sections.o ../../../skinclassic.o ../../../skins.o ../../../skinsttng.o ../../../sources.o ../../../spu.o ../../../status.o ../../../submenu.o ../../../svdrp.o ../../../themes.o ../../../thread.o ../../../timers.o ../../../tools.o ../../../transfer.o ../../../videodir.o ../../../libsi/libsi.a
../../../eit.o: In function `cTDT':/usr/local/src/VDR/eit.c:462: undefined reference to `SetTime'
:/usr/local/src/VDR/eit.c:462: undefined reference to `SetTime'
collect2: ld returned 1 exit status
make[1]: *** [scan-test] Fehler 1
make[1]: Leaving directory `/usr/local/src/vdr-1.4.0/PLUGINS/src/burn'Liegt vermutlich am settime-after-BP.diff, den ich verwende.
Gruss Bert
-
-
Hi, armageddon
Gute Idee > Danke.
Werd ich dann Morgen mal so machen.EDIT:
Hat geklappt.
EDIT ENDE:Gruss , Bert
-
Hi,
So, spät aber doch, hier auch von mir ein paar Scans.
Gruss Bert
-
Selbst übersetzen hat bei mir nicht funktioniert. Mit gcc-4.1 spuckt der Linker, mit gcc-3.3.5 (Debian Sarge) knallt es bei jedem Start mit Speicherzugriffsfehler. Der Backtrace ist etwas widersprüchlich, muss nochmal mit richtigen Debug-Builds testen. Der Fehler scheint mit get_recording_datetime zusammen zu hängen, zumal dieser auf cRecording::Title zurückgreift, und da bei mir ein Patch für eine etwas andere Ausgabe sorgt.
<edit>
Nachtrag: Es ist definitiv einer meiner Patches, der in cRecording::Title() etwas mehr VDR braucht, als scan-test bieten kann. Ohne Patch ist die Ausgabe wie unten.
</edit>Ersatzweise hab ich mit der fertig übersetzten Version weiter gemacht. Ein Problem kann ich dann beobachten:
Code
Alles anzeigen>dir %Flucht_aus_L.A#2E/2006-06-16.22.19.50.50.rec/ insgesamt 3396169 drwxr-sr-x 2 vdr vdr 240 2006-06-17 00:43 . drwxr-sr-x 3 vdr vdr 96 2006-06-17 00:37 .. -rw-r--r-- 1 vdr vdr 1308690867 2006-06-17 00:39 001.vdr -rw-r--r-- 1 vdr vdr 1038627960 2006-06-17 00:40 002.vdr -rw-r--r-- 1 vdr vdr 1125768251 2006-06-17 00:42 003.vdr -rw-r--r-- 1 vdr vdr 1179072 2006-06-17 00:42 index.vdr -rw-r--r-- 1 vdr vdr 555 2006-06-17 00:37 info.vdr -rw-r--r-- 1 vdr vdr 66 2006-06-17 00:42 marks.vdr -rw-r--r-- 1 vdr vdr 4 2006-06-17 00:43 resume.vdr >~/scan-test %Flucht_aus_L.A#2E/2006-06-16.22.19.50.50.rec/ [ info ] movie size: 18446744072887653632 [ info ] movie size (cut): 18446744072886867070 [ debug ] marks available, skipping 10 seconds from first mark [ info ] found ac3 stream bd [ info ] bitrate = 448 [ info ] mode = 3/2 [ info ] found audio stream c0 [ info ] streamtype = mpeg1 [ info ] layer = 2 [ info ] bitrate = 192 [ info ] mode = stereo [ info ] found video stream e0 [ info ] aspect = 4:3 [ info ] framerate = 25/s [ info ] bitrate = 15000000
Beachte die 'movie size'. Die angegebene Zahl ist in hex 0xFFFFFFFFCF02D500, die drei Dateien zusammen haben 0xCF031A66 Bytes. Irgendwo dürfte da noch ein Konflikt 32-Bit / 64-Bit int liegen.Gruß,
Udo
-
Hi Lord,
ist das noch aktuell? Oder hast du schon genug Info?
(ich komme allerdings nicht vor Sonntag an meinen VDR da ich gerade 6000KM entfernt bin).
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!