You are here: Home » Topic » iTunes internals

iTunes internals

This topic contains 22 replies, has 5 voices, and was last updated by  rpedde 9 years, 9 months ago.

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • #1998

    Anonymous

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

    #14951

    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,

    #14952

    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..

    #14953

    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!

    #14954

    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?

    #14955

    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?!?

    #14956

    rpedde
    Participant

    @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

    #14957

    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.

    #14958

    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)…

    #14959

    sonichouse
    Participant

    @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 🙂

    #14960

    Anonymous

    @sonichouse wrote:

    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 🙂

    It didn’t, but thanx…

    #14961

    Anonymous

    @turbo wrote:

    @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.

    Could we please revisit this – it doesn’t compute…

    I’ve converted my AVI to MP4, ran it through MP4Box (http://castfortwo.blogspot.com/2007/10/make-mp4-files-faststart-with-mp4box.html) to make it faststart… Streaming that file still makes iTunes to hangup…

    [celia.pts/6]$ ll -h tempfile.mp4
    -rw-r--r-- 1 turbo turbo 198M 2007-12-11 09:45 tempfile.mp4
    [celia.pts/6]$ MP4Box -info tempfile.avi
    Import probing results for tempfile.avi:
    File has 2 tracks
    Track 1 type: Video (XVID)
    Track 2 type: Audio (....)

    [celia.pts/6]$ MP4Box -inter 500 tempfile.mp4
    Saving tempfile.mp4: 0.500 secs Interleaving
    [celia.pts/6]$ MP4Box -info tempfile.mp4
    * Movie Info *
    Timescale 1000 - Duration 01:43:19.480
    Fragmented File no - 2 track(s)
    File Brand isom - version 512
    Created: GMT Fri Jan 2 00:00:00 1970

    File has no MPEG4 IOD/OD

    Track # 1 Info - TrackID 1 - TimeScale 25 - Duration 01:43:19.480
    Media Info: Language "Undetermined" - Type "vide:mp4v" - 154987 samples
    MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x20
    MPEG-4 Visual Size 640 x 240 - Simple Profile @ Level 1
    Pixel Aspect Ratio 1:1 - Indicated track size 640 x 240
    Self-synchronized

    Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 01:43:19.424
    Media Info: Language "Undetermined" - Type "soun:mp4a" - 290598 samples
    MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
    MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
    Synchronized on stream 1

    And the -hint option didn’t help either…
    I read somewhere that the version of iTunes matters – mine is 7.5 (19)

    #14962

    Anonymous

    According to http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-December/012802.html the Fast Start thingie isn’t needed any more…

    > Search the net for NicMP4Box.ese and take the ffmpeg h264 file and run
    > it through the program. It adjusts the stream by adding a iTunes
    > required uuid atom.

    the atom is nolonger needed in itunes versions since 7.4.2. tested with both ipod and ipod touch, and iphone very soon 🙂

    #14963

    jtbse
    Participant

    @turbo wrote:

    According to http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-December/012802.html the Fast Start thingie isn’t needed any more…

    the atom is nolonger needed in itunes versions since 7.4.2. tested with both ipod and ipod touch, and iphone very soon 🙂

    Hmm, might be true for iTunes, but what about Firefly?

    I’m guessing this has to do with the specific DAAP implementation in question…I guess Ron would have to comment on that, but I would be surprised if he’s made any major changes to DAAP in Firefly in awhile.

    Also not sure what DAPs (i.e. ipod, ipod touch, and iphone) really have to do with this since as I have always understood it, the fast-start streaming issue with mp4 metadata has to do with streaming/sharing…not strictly decoding/playing.

    #14964

    rpedde
    Participant

    @jtbse wrote:

    @turbo wrote:

    According to http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-December/012802.html the Fast Start thingie isn’t needed any more…

    the atom is nolonger needed in itunes versions since 7.4.2. tested with both ipod and ipod touch, and iphone very soon 🙂

    Hmm, might be true for iTunes, but what about Firefly?

    I’m guessing this has to do with the specific DAAP implementation in question…I guess Ron would have to comment on that, but I would be surprised if he’s made any major changes to DAAP in Firefly in awhile.

    Also not sure what DAPs (i.e. ipod, ipod touch, and iphone) really have to do with this since as I have always understood it, the fast-start streaming issue with mp4 metadata has to do with streaming/sharing…not strictly decoding/playing.

    Right. First, fast start is completely unrelated to the uuid atom. As mentioned previously, playing from a local file system is completely different from streaming. Playing from a seekable file system, iTunes doesn’t care about metadata arrangement. But for streaming, the metadata has to be front-loaded, or itunes simply won’t stream it.

    As far as why your fast start streaming file wont’ play, have you verified the metadata is front loaded? Use something that will show you the real tag order (like atomicparsley) so you can actually verify that the metadata is right.

    If the metadata is right, and it plays from a seekable file system, but not streamed, then I don’t really have a good answer. Something about the headers that iTunes still doesn’t like? Not sure.

    But it’s isn’t a firefly thing, I’d wager. I’d guess it wouldn’t stream itunes to itunes either.

    — Ron

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic.