FireFly Media Server

04/12/2007 at 9:15 PM #14953

Anonymous

Inactive

Converting an AVI to MOV manually like so:

ffmpeg -i /share/Movies/tmp/Filename.avi -acodec libmp3lame -f mov /tmp/Filename.mov

and then opening this in iTunes (through SMB) works great. Both video and sound.

But if I use the exact same commandline from mt-daapd-ssc.pl (which I’ve been modifying) and setting has_video=1 in the db for this file, I get a write failure (Broken pipe). I’m modifying the mplayer_proc() so ffmpeg is writing to a temp file, fills 2Mb (2*1024*1024) and then this temp file is sent to the client (after 69×4096 bytes I get the Broken pipe).

Checking with ps, the command line is correct:

 4226 pts/2    Sl+    0:00  |           _ mt-daapd -m -d16384 -f

4241 pts/2    R+     0:01  |           |   _ mt-daapd-ssc.pl

4242 pts/2    R+     0:01  |           |       _ ffmpeg -i /share/Movies/tmp/Filename.avi -f mov -acodec libmp3lame /tmp/t-4241

But saving the temporary file that is created, and trying to play that in iTunes does not work which is extreamly weird! After some renames to make it easier to remember which file is which, I get this:

celia:~# ll /tmp/filename-*

-rw

1 mt-daapd nogroup 2120638 2007-12-04 22:19 /tmp/filename-auto.mov

-rw-r--r-- 1 turbo    turbo   2502393 2007-12-04 22:17 /tmp/filename-manual.mov

celia:~# file /tmp/filename-*

/tmp/filename-auto.mov:   ISO Media, Apple QuickTime movie

/tmp/filename-manual.mov: ISO Media, Apple QuickTime movie

The file filename-manual.mov plays just fine, the filename-auto.mov does not! Any ideas why?!

Doing an hexdump on the manual and the auto files, taking into account the first two hundred lines, a diff of the result is like so:

@@ -1,5 +1,5 @@

0000000 0000 1400 7466 7079 7471 2020 0000 0002

-0000010 7471 2020 0000 0800 6977 6564 2500 b9c9

+0000010 7471 2020 0000 0800 6977 6564 0000 0000

0000020 646d 7461 fbff 6454 0f00 00f0 6900 0000

0000030 0800 0000 200d 0000 0001 0100 00a4 0000

0000040 0020 3400 0080 0400 5c46 791f 7d70 47ff

Don’t know which byte this is, but it’s on the second line (manual) :

0000000 0000 1400 7466 7079 7471 2020 0000 0002

0000010 7471 2020 0000 0800 6977 6564 2500 b9c9

and (auto):

0000000 0000 1400 7466 7079 7471 2020 0000 0002

0000010 7471 2020 0000 0800 6977 6564 0000 0000

respectivly.
And even if I take into account the whole file of the smaller one , auto which is 2120638 (2502393 for the manuall one – didn’t Ctrl-C in time :), there is 132541 lines in the hex dump, I don’t get much difference:

@@ -1,5 +1,5 @@

0000000 0000 1400 7466 7079 7471 2020 0000 0002

-0000010 7471 2020 0000 0800 6977 6564 2500 b9c9

+0000010 7471 2020 0000 0800 6977 6564 0000 0000

0000020 646d 7461 fbff 6454 0f00 00f0 6900 0000

0000030 0800 0000 200d 0000 0001 0100 00a4 0000

0000040 0020 3400 0080 0400 5c46 791f 7d70 47ff

@@ -132537,5 +132537,5 @@

0205b80 37d9 5ff7 7a7b 79ff 6fb9 f2be f77d 5cdd

0205b90 febf fbeb f7ff bfdc 27ee ffff 18fe bccc

0205ba0 bec9 7fe5 a4fb 0ce5 1b67 d864 3a63 26f3

-0205bb0 3686 f8db 3863 26db 3686 ffdb efff fbff

-0205bc0 6454 061d e500 d50c c300 3019 8133 5abc

+0205bb0 3686 f8db 3863 26db 3686 ffdb efff

+0205bbe

But since this second part of the diff is the last two lines in the hex dump (which the client never receives), it doesn’t matter (not regarding the problem I’m having with iTunes at this moment – might mess things up later though, but first things first :).
Running the script manually gives the exact same result as if run from mt-daapd…

Skipping the encode and instead symlink() the working file to the tempfile (which is then sent over the network to the client) and removing the rsp.so and ssc-ffmpeg.so plugins (leaving only the out-daap.so and ssc-script.so), I get this gdb backtrace:

#0  0xb7f04402 in __kernel_vsyscall ()

#1  0xb7ed087b in __write_nocancel () from /lib/tls/i686/cmov/libpthread.so.0

#2  0x08053035 in r_write (fd=10, buf=0xb68766ac, size=1024) at restart.c:134

#3  0x08065b64 in _plugin_ssc_copy (pwsc=0x808c3f0, pfn=0xb70e41c0, vp=0x8088e88, offset=0) at plugin.c:602

#4  0x080662a2 in _plugin_ssc_transcode (pwsc=0x808c3f0, pmp3=0x80893c8, offset=0, headers=1) at plugin.c:670

#5  0x08066b0f in pi_stream (pwsc=0x808c3f0, id=0x808c6bb "1498.wav") at plugin.c:941

#6  0xb7ef9b4d in out_daap_stream (pwsc=0x808c3f0, ppi=0x808a0e8) at out-daap.c:750

#7  0xb7efd0f1 in plugin_handler (pwsc=0x808c3f0) at out-daap.c:387

#8  0x0804fdb7 in ws_dispatcher (arg=0x808c3f0) at webserver.c:986

#9  0xb7ecb267 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0

#10 0xb777f65e in clone () from /lib/tls/i686/cmov/libc.so.6

To tired to try to figure out why (if none have given me any hints tomorrow, I’ll do it first thing when I wake up).

Just in case there’s something wrong with my glases, check http://www.bayour.com/misc/mt-daapd-ssc.pl.txt. If there’s anything wrong here, it must be in the stream_loop() function, but I can’t see it!