iTunes internals

[Anonymous]

What’s with the ‘always transcode to WAV’ in Firefly?

[Anonymous]

Could you be a little more specific? Where you are seeing this message? Is it causing a problem for you? What are you trying to accommplish?

Here’s some information from the wiki on transcoding in Firefly. http://wiki.fireflymediaserver.org/Transcoding_HOWTO

Hope this helps,

[Anonymous]

@Jim DeLaHunt wrote:

Could you be a little more specific? Where you are seeing this message?

In the config file and in the code.

# List of codectypes for files that the

# daap server should perform internal format conversion and present

# to clients as WAV files.

All files are transcoded to WAV in the mt-daapd-ssc.pl script, so…@Jim DeLaHunt wrote:

Is it causing a problem for you? What are you trying to accommplish?

Oh, yes! I’m trying to send an AVI movie as a MOV, but iTunes drops the connection. If I send it a WAV, it works (kinda – sound but no video).
If I convert my AVI to a MOV manually and send that as a WAV it works (both video and sound) but not if I transcode it as a WAV directly… Very weird..

[Anonymous]

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!

[Anonymous]

Testing with a simple Net::Telnet perl script (http://www.bayour.com/misc/iTunes-Test.pl.txt) shows strange results.

Basically the whole file differs, only the first few bytes are the same (probably the file ‘tag’). So is Firefly do something with the data the script sends it?

[Anonymous]

@turbo wrote:

Testing with a simple Net::Telnet perl script (http://www.bayour.com/misc/iTunes-Test.pl.txt) shows strange results.

Never mind. My bad. Must set ‘Telnetmode => 0’ in the get() method to not interpret telnet commands.
Script at URL updated. It now matches the manual MOV file exactly… So Firefly is sending correct data – iTunes can play the resulting file just fine…

So… iTunes is hanging up the connection for some other reason than faulty file. Any ideas?!?

[rpedde]

@turbo wrote:

@turbo wrote:

Testing with a simple Net::Telnet perl script (http://www.bayour.com/misc/iTunes-Test.pl.txt) shows strange results.

Never mind. My bad. Must set ‘Telnetmode => 0’ in the get() method to not interpret telnet commands.
Script at URL updated. It now matches the manual MOV file exactly… So Firefly is sending correct data – iTunes can play the resulting file just fine…

So… iTunes is hanging up the connection for some other reason than faulty file. Any ideas?!?

itunes has different rules for streamed versus local files… if it’s fetching from a GET, it can’t seek…. or at least, it can only seek *forward*.

So if metadata isn’t optimized for streaming (like the file metainfo is at the end of the file, not at the beginning), itunes bails, since it’s not friendly for streaming.

Look around on the net for fast-start enabled aac. That’s what you need — metadata at the head of the file, not the tail. iTunes can play that.

— Ron

[Anonymous]

@rpedde wrote:

Look around on the net for fast-start enabled aac. That’s what you need — metadata at the head of the file, not the tail. iTunes can play that.

Running the MOV file through qt-faststart and send that (i.e. without going through ffmpeg) doesn’t seem to help. iTunes still hangs up.

[Anonymous]

When sending iTunes a MP4 file created with the command:

ffmpeg -i Filename.avi -f mp4 -vcodec mpeg4 -acodec libfaac /tmp/filename-manual.m4v

directly (i.e. no transcoding in the script), iTunes will still just hangup the connection (different number of blocks every time!). And mp4creator -optimize gives errors:

mp4creator: no VOSH header found in MPEG-4 video.

This can cause problems with players other than mp4player.

mp4creator: No VO header found in mpeg-4 video.

This can cause problems with players other than mp4player

mp4creator: fatal: No VOL header found in mpeg-4 video stream

(the file will play through SMB with both sound and video though)…

[sonichouse]

@turbo wrote:

When sending iTunes a MP4 file created with the command:

ffmpeg -i Filename.avi -f mp4 -vcodec mpeg4 -acodec libfaac /tmp/filename-manual.m4v

directly (i.e. no transcoding in the script), iTunes will still just hangup the connection (different number of blocks every time!).

I found this on a posting

-async 1 -deinterlace -vcodec libx264 -b 384000 -maxrate 768k -bufsize 384 -coder 0 -level 13

-acodec libfaac -ab 128000

Not sure if it helps 🙂

[Author]

Posts