Windows AVI 24bit unkomprimiert einlesen?

[7.e.Q]

Hi Leute,

ich will ein Video im Format Windows AVI 24bit unkomprimiert, Auflösung 352x288, 25fps einlesen, um es als Bytebuffer Bild für Bild an eine Funktion übergeben zu können. Da gibt es doch mit Sicherheit schon irgendwelche Sourcen für, irgendwo. Kann mir jemand sagen, was man da am besten für nimmt?

Danke

Gruß,
Hendrik

[7.e.Q]

Anders gefragt: hat schonmal jemand mit ffmpeg gearbeitet hier? libavformat, libavcodec?

[quinte17]

weder noch, aber ein avi ist ja nur ein RIFF container, diese sind auf msdn recht gut dokumentiert..
habe mit kumpel an so einem tool schon ein wenig rumgewurschtelt...
bluebox-effect
lichtschwert
überblenden
farbmanipulation
uvm...

source kann ich dir leider nicht geben

greetz

[7.e.Q]

Also um das mal zu erklären... es geht darum, ein AVI File Bild für Bild in einen H.263 codierten RTP Stream zu encodieren. Dieser RTP Stream soll dann Paket für Paket statt auf das Netzwerk erstmal in einer sogenannten IRF Datei abgelegt werden. Darin enthalten sind im Prinzip nur aneinandergereiht die Payloads der generierten RTP-Pakete; ach ja, und umgekehrt - also aus einer IRF Datei ein AVI zu machen.

Soviel zur Theorie. Das ganze muss jetzt in die Praxis umgesetzt werden. Die ganzen Funktionen zum Encodieren der Bilder existieren schon. Es geht jetzt nur noch darum, den Funktionen einzeln die Bilder als Byte-Buffer samt Größe zu übergeben. Ich muss also nur wissen, wie man mit libavformat und libavcodec (hier in der Version 0.4.6) ein Windows AVI 24bit Video bildweise einliest.

[7.e.Q]

Harr, da hab ich euch wieder ein Thema aufgedrückt, was?! Schon Scheiße, wenn man sich mit solch... seltenen Themen rumärgern muss, bei denen einem fast keiner helfen kann.

[Joghurt]

Kannst du dir nicht einfach anschauen, wie das ffmpeg (das ist doch libavcodec, oder) Eingabeplugin von transcode die Bilder einliest?

transcode macht ja im Grunde genommen das, was du auch machen musst; AVIs umkomprimieren.

[7.e.Q]

Shit is das kompliziert... Vorher überhaupt mal 'ne Frage: woher weiß ich denn, daß das, was bei mir jetzt am Ende heraus kommt (ja, einlesen klappt wohl, umkodieren auch... jedenfalls theoretisch), tatsächlich RTP-Payloads mit H.263 encodierten AVI Frames sind, und nicht irgendein undefinierbarer Byte-Salat? Gibt es Tools, mit denen man sich sowas anschauen kann?

[7.e.Q]

Also okay... Encodierung scheint zu funktionieren. MPlayer kann den daraus resultierenden H.263 RTP-Stream abspielen. Jetzt muss ich diesen Raw-RTP Stream wieder in ein unkomprimiertes 24bit AVI Format verwandeln.

[7.e.Q]

Sind jetzt runtergegangen auf QCIF (176x144). Vorher hatten wir CIF (352x288). Jetzt tritt aber irgendwie ein Problem auf, wo ich nicht ganz weiß, wie ich da ansetzen soll. Wenn ich das resultierende RTP File abspiele, fehlt am Ende ein ganzes Stück des Videos gegenüber dem Original. Mein Programm sagt mir aber, es habe alle Frames encodiert. Wie kann sowas zustande kommen?

[Joghurt]

Vielleicht fehlt tatsächlich nichts, nur die Datei selbst hat an der Stelle ein falsches Format und der Player bricht dann ab?

[7.e.Q]

Der MPlayer sagt mir an der Stelle dann "End of File reached (EOF)". Die komplette Ausgabe des MPlayers bei Wiedergabe des im Anhang befindlichen (als zip gepackten) Files:

MPlayer dev-CVS-050928-16:38-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Intel  (Family: 8, Stepping: 3)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled with runtime CPU detection - WARNING - this is not optimal!
To get best performance, recompile MPlayer with --disable-runtime-cpudetection.

CommandLine: 'src10.rtp' '-v'
init_freetype
font: can't open file: c:/windows/fonts/arial.ttf
Cannot load font: c:/windows/fonts/arial.ttf
Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay
Using Windows native timing
get_path('input.conf') -> 'D:/My/ISTS/H263/MPlayer/mplayer/mplayer/input.conf'
Parsing input config file D:/My/ISTS/H263/MPlayer/mplayer/mplayer/input.conf
Input config file D:/My/ISTS/H263/MPlayer/mplayer/mplayer/input.conf parsed: 53
binds
get_path('src10.rtp.conf') -> 'D:/My/ISTS/H263/MPlayer/mplayer/mplayer/src10.rtp
.conf'
Playing src10.rtp.
WINSOCK2 init: 0
[file] File size is 91645 bytes
STREAM: [file] src10.rtp
STREAM: Description: File
STREAM: Author: Albeu
STREAM: Comment: based on the code from ??? (probably Arpi)
Checking for YUV4MPEG2
ASF_check: not ASF guid!
Checking for NuppelVideo
Checking for REAL
Checking for SMJPEG
Searching demuxer type for filename src10.rtp ext: .rtp
Checking for Nullsoft Streaming Video
Checking for MOV
Checking for VIVO
header block 1 size: 0
AVS: avs_check_file - attempting to open file src10.rtp
AVS: File is too big, aborting...
Checking for PVA
Checking for MPEG-TS...
TRIED UP TO POSITION 68718, FOUND 0, packet_size= 71, SEEMS A TS? 0
Checking for LMLM4 Stream Format
Invalid packet in LMLM4 stream: ch=0 size=481067768
LMLM4 Stream Format not found
MPEG Stream reached EOF
ds_fill_buffer: EOF reached (stream: video)
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0
 sps: 0 pps: 0 PES: 0  MP3: 64, synced: 0
Not MPEG System Stream format... (maybe Transport Stream?)
MPEG Stream reached EOF
ds_fill_buffer: EOF reached (stream: video)
MPEG packet stats: p100: 0  p101: 0 p1B6: 0 p12x: 0 sli: 0 a: 0 b: 0 c: 0 idr: 0
 sps: 0 pps: 0 PES: 0  MP3: 64, synced: 3
Not MPEG System Stream format... (maybe Transport Stream?)
ds_fill_buffer: EOF reached (stream: video)
LAVF_check: raw h263
libavformat file format detected.
==> Found video stream: 0
======= VIDEO Format ======
  biSize 40
  biWidth 176
  biHeight 144
  biPlanes 0
  biBitCount 0
  biCompression 859189832='H263'
  biSizeImage 0
===========================
LAVF: 0 audio and 1 video streams found
LAVF: build 3211520
VIDEO:  [H263]  176x144  0bpp  25.000 fps    0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:35  fourcc:0x33363248  size:176x144  fps:25.00  ftime:=0.0400
get_path('sub/') -> 'D:/My/ISTS/H263/MPlayer/mplayer/mplayer/sub/'
get_path('default.sub') -> 'D:/My/ISTS/H263/MPlayer/mplayer/mplayer/default.sub'

<vo_directx><INFO>checking primary surface
<vo_directx><FORMAT PRIMARY>14 BGR32 supported
<vo_directx><INFO>testing supported overlay pixelformats
<vo_directx><FORMAT OVERLAY>0 YV12  supported
<vo_directx><FORMAT OVERLAY>1 I420  supported
<vo_directx><FORMAT OVERLAY>2 IYUV  supported
<vo_directx><FORMAT OVERLAY>3 YVU9  supported
<vo_directx><FORMAT OVERLAY>4 YUY2  supported
<vo_directx><FORMAT OVERLAY>5 UYVY  supported
<vo_directx><FORMAT OVERLAY>6 BGR8  not supported
<vo_directx><FORMAT OVERLAY>7 RGB15 not supported
<vo_directx><FORMAT OVERLAY>8 BGR15 not supported
<vo_directx><FORMAT OVERLAY>9 RGB16 not supported
<vo_directx><FORMAT OVERLAY>10 BGR16 not supported
<vo_directx><FORMAT OVERLAY>11 RGB24 not supported
<vo_directx><FORMAT OVERLAY>12 BGR24 not supported
<vo_directx><FORMAT OVERLAY>13 RGB32 not supported
<vo_directx><FORMAT OVERLAY>14 BGR32 not supported
<vo_directx><INFO>Your card supports 6 of 15 overlayformats
<vo_directx><INFO>can mirror left right
<vo_directx><INFO>can mirror up down
<vo_directx><INFO>hardware supports overlay
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
INFO: libavcodec init OK!
Selected video codec: [ffh263] vfm:ffmpeg (FFmpeg H.263+ decoder)
==========================================================================
Audio: no sound
Freeing 0 unused audio chunks.
Starting playback...
[ffmpeg] aspect_ratio: 1.333333
VDec: vo config request - 176 x 144 (preferred csp: Planar YV12)
Trying filter chain: vo
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
VO Config (176x144->192x144,flags=0,'MPlayer',0x32315659)
VO: [directx] 176x144 => 192x144 Planar YV12
VO: Description: Directx DDraw YUV/RGB/BGR renderer
VO: Author: Sascha Sommer <saschasommer@freenet.de>
<vo_directx><INFO>overlay with format YV12  created
*** [vo] Allocating (slices) mp_image_t, 176x144x12bpp YUV planar, 38016 bytes
get_path('subfont.ttf') -> 'D:/My/ISTS/H263/MPlayer/mplayer/mplayer/subfont.ttf'

New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
*** [vo] Allocating (slices) mp_image_t, 176x144x12bpp YUV planar, 38016 bytes
ds_fill_buffer: EOF reached (stream: video)
EOF code: 1

uninit video: ffmpeg
WINSOCK2 uninit

Exiting... (End of file)

Ich weiß, meine Fragen sind momentan alle noch etwas schwammig formuliert, aber mein Wissen über diese Thematik ist eben leider noch sehr lückenhaft.

Edit: ich würde das Original auch gern hier hochladen. Es ist allerdings dank fehlender Komprimierung knapp 17 MB groß...

Edit2: wenn du dir die Sourcen meines Programms mal anschauen willst, dann zieh sie dir dort:
http://7eq.ath.cx/repos/H263TEST/

[7.e.Q]

Ich hab das ganze jetzt mal unter Windows zu kompilieren versucht. FFMPeg 0.4.9 lässt sich im MinGW nach start der vcvars32.bat sauber übersetzen. Configure:

./configure --enable-shared --enable-memalign-hack

Danach make klappt wunderbar. Er legt mir die notwendigen .lib und .dll Dateien an. Alles fein.

Mein Programm übersetzt auch sauber, linkt auch, startet auch. Aber... der Funktionsaufruf

	AVCodec *pCodec;
	pCodec = avcodec_find_decoder(pCodecCtx->codec_id);

liefert unter Windoof pCodec = NULL; zurück. Unter Linux funktioniert das einwandfrei. Was kann da falsch gelaufen sein?

EDIT: aha, avcodec_register_all() nirgendwo vorher aufgerufen *kopf->tisch*

[7.e.Q]

Hmm... jetzt bekomme ich seit neuestem den Fehler AVERROR_IO von av_open_input_file zurück (immer noch unter Windows)... Die Datei existiert aber, ist auch nicht von irgendeinem anderen Programm geöffnet. Sehr eigenartig. Jemand 'ne Idee?

edit: hmm, das Problem hat sich auch erledigt... man sollte auch av_register_all() vorher aufrufen. Nicht nur avcodec_register_all().

Wie dem auch sei... Irgendwie hab ich immer noch das Problem, daß das Video nach der Encodierung absolut scheiße aussieht. Also man erkennt gar nix mehr, alles ist verzerrt, die Farben sind falsch, nix geht mehr...

Also irgendwas muss da beim Übersetzen der FFMPEG Libs schiefgehen. Jedenfalls hab ich das jetzt alles runtergebrochen auf ein Level, wo Windows und Linux exakt das selbe tun. Unter Linux sind die RTP Payloads bei jedem Aufruf mit einer Beispielsequenz gleich groß. Beispielsweise ist Frame #140 immer 1204 Bytes lang. Der Logik nach zu urteilen ist das auch korrekt. Die Eingabe-Daten ändern sich ja auch nicht.
So... unter Windows sind trotz der selben Eingabe-Sequenz die RTP Payloads bei jedem Aufruf unterschiedlich groß! Beispielsweise ist Payload #140 beim 1. Aufruf 2156 Bytes (!) lang, beim nächsten Aufruf mit der selben Datei nur noch 2128 Bytes. Beim 3. Aufruf dann 2153 Bytes... also immer unterschiedlich. Was läuft da schief???

Zur Info

Windows:
ffmpeg Version: ffmpeg-0.4.9
Übersetzungsumgebung u. Windows: MinGW
Compiler-Version: gcc-3.4.2
Configure-Aufruf v. ffmpeg: ./configure --enable-shared --enable-gpl --disable-mmx

Linux:
ffmpeg Version: ffmpeg-0.4.9
Compiler-Version: 3.3.3
Configure-Aufruf v. ffmpeg: ./configure --enable-shared --prefix=/ffmpeg-0.4.9



Edit:

Habe mir mal die ersten 10 Bytes jedes einzelnen von avcodec_encode_video zurückgelieferten Frames angeschaut (Buffer output).

Linux:
First 10 Bytes of Payload #140: 0x0 0x0 0x82 0x2e 0x1c 0xac 0x83 0x4 0x92 0x0
First 10 Bytes of Payload #141: 0x0 0x0 0x82 0x32 0x1c 0xac 0x83 0x0 0x12 0x0
First 10 Bytes of Payload #142: 0x0 0x0 0x82 0x36 0x1c 0xac 0x83 0x4 0x92 0x0
First 10 Bytes of Payload #143: 0x0 0x0 0x82 0x3a 0x1c 0xac 0x83 0x4 0x12 0x0
First 10 Bytes of Payload #144: 0x0 0x0 0x82 0x3e 0x1c 0xac 0x83 0x4 0x92 0x0
First 10 Bytes of Payload #145: 0x0 0x0 0x82 0x42 0x1c 0xac 0x83 0x4 0x12 0x0
First 10 Bytes of Payload #146: 0x0 0x0 0x82 0x46 0x1c 0xac 0x83 0x4 0x92 0x0
First 10 Bytes of Payload #147: 0x0 0x0 0x82 0x4a 0x1c 0xac 0x83 0x4 0x12 0x0
First 10 Bytes of Payload #148: 0x0 0x0 0x82 0x4e 0x1c 0xac 0x83 0x4 0x92 0x0
First 10 Bytes of Payload #149: 0x0 0x0 0x82 0x52 0x1c 0xac 0x83 0x4 0x12 0x0

Windows:
First 10 Bytes of Payload #140: 0x0 0x0 0x82 0x2e 0x1c 0xac 0x83 0x4 0x93 0x0
First 10 Bytes of Payload #141: 0x0 0x0 0x82 0x32 0x1c 0xac 0x83 0x0 0x13 0x0
First 10 Bytes of Payload #142: 0x0 0x0 0x82 0x36 0x1c 0xac 0x83 0x4 0x93 0x0
First 10 Bytes of Payload #143: 0x0 0x0 0x82 0x3a 0x1c 0xac 0x83 0x4 0x13 0x0
First 10 Bytes of Payload #144: 0x0 0x0 0x82 0x3e 0x1c 0xac 0x83 0x4 0x93 0x0
First 10 Bytes of Payload #145: 0x0 0x0 0x82 0x42 0x1c 0xac 0x83 0x4 0x13 0x0
First 10 Bytes of Payload #146: 0x0 0x0 0x82 0x46 0x1c 0xac 0x83 0x4 0x93 0x0
First 10 Bytes of Payload #147: 0x0 0x0 0x82 0x4a 0x1c 0xac 0x83 0x4 0x13 0x0
First 10 Bytes of Payload #148: 0x0 0x0 0x82 0x4e 0x1c 0xac 0x83 0x4 0x93 0x0
First 10 Bytes of Payload #149: 0x0 0x0 0x82 0x52 0x1c 0xac 0x83 0x4 0x13 0x0

Kann mir mal jemand erklären, wieso bei identischem Code, identischen Versionsnummern der Software (inzwischen auch unter Linux getestet mit GCC 3.4.1 mit dem selben Effekt) etc. das 9. Byte unter Linux jeweils 1 niedriger ist, als unter Windows??? Es sind die selben Quell-Video-Sequenzen, die selben Code-Dateien... FFMPEG liegt auf beiden Systemen in der Version 0.4.9 vor. Einzig die Compiler-Umgebung und das Betriebssystem unterscheiden sich.

Ich versteh das nicht! Kann mir das einer erklären???

[7.e.Q]

Hab Änderungen an meinem letzten Posting vorgenommen...

[Joghurt]

Kann es einfach sein, dass das Komprimierungsverfahren nicht nur lossy, sondern auch nicht-deterministisch ist? Das also verschiedene Durchläufe andere Ergebnisse liefern, da andere Zufallszahlen genommen werden?

Ich denke übrigens, das man dir in der ffmpeg-user Mailingliste besser helfen können wird.